The payments log

Payments, the last tab of a season's Payouts screen, is the season's transaction log: one row per payment, newest first, whoever logged it and whichever judge it was for. Where the Ledger answers "what do I still owe Odette", this answers "what have we actually paid out this season, when, by whom, and against what".

It is a reading screen. Nothing new is written here — a payment is logged on the Ledger, where a judge is chosen first — and the one thing you can do from a row is void it. Every payment stays on this list for good, corrected rather than rewritten.

Finding the screen

Payouts sits in the season block of the left navigation, between Awards and Settings, and opens on the Ledger — or on Invoices while any invoice a judge sent is waiting on you. Payments is the last of its three tabs, Ledger · Invoices · Payments:

/org/<organization>/<festival>/<season>/payouts?tab=payments

The three tabs are one page, so switching to this one is instant and nothing reloads. The older address, …/payouts/payments, still works and opens this tab.

The section is there only for the people allowed to see it — see Who can see it. The tabs themselves carry no counts: the amber number beside Payouts in the navigation counts the invoices waiting on you — see Judge invoices.

A payment logged with Mark paid — on an invoice, or on its line under the Ledger's Invoices to pay — or with the Ledger's Pays INV-… switch on, is an ordinary row here — nothing on this list marks which invoice it paid.

Who can see it

Opening either tab takes the View revenue and payouts permission, and the whole Payouts row is absent from the navigation without it — not greyed, and with no explanation anywhere. Typing the address sends you back to the season instead, as it does for every Payouts tab.

Festival admins have it by default. Coordinators, programmers and viewers do not. Organization owners and org admins always do.
A per-person tick box moves it either way, on Festival access.

Voiding a payment takes something more: being somebody who can change the season. A read-only viewer given View revenue and payouts — a board member, an accountant — reads the whole log, opens every receipt, and finds no Void button on any row.

The columns

Column	What it holds
Date paid	The date you recorded the payment as having been made — `Aug 10, 2026`. Not the date it was logged.
Judge	Who was paid, named the way the Ledger names them — in practice usually an email address. An em dash if the record cannot be named.
Amount	What was paid, in dollars. The one right-aligned column.
Method	Bank transfer, Check, PayPal or Venmo, or Cash.
Reference	Whatever was typed when the payment was logged — a transfer reference, a check number, a transaction ID. An em dash when none was given; it is optional on every method.
Covers	All, or 3 scorecards. See What "Covers" means.
Logged by	The person who recorded it. An em dash if that account has since been deleted. On a voided row, this cell also carries who voided it and why.
Receipt	View receipt when a file was attached, and an em dash when none was. See Receipts.

The last column has no heading: it holds the Void button, and only on rows you are allowed to void.

The table scrolls sideways rather than restacking. When the card is narrower than the table it slides under a heading row pinned to the top, with Date paid and Judge pinned to the left so you can always tell whose payment you are reading. The rows stay rows at every width. The scroll region is also a tab stop, so it can be scrolled with the keyboard by anyone who only wants to read the far columns rather than press anything in them.

Nobody who volunteers should be on this list. The Ledger offers no Log a payment on a volunteer's row, so a payment against one can only have been made before their terms were what they are now, or by a route this screen does not have. If you find one, it is still money that moved and the log is right to show it.

What "Covers" means

When a payment was logged, it was recorded either against all outstanding or against a picked set of scorecards. This column reports that choice:

All — no particular scorecards were named.
3 scorecards — that many were ticked when the payment was logged.

It is a note of intent, not arithmetic. What a judge is owed is always their approved pay minus their payments, never worked out from which scorecards a payment named. To see which films a payment covered, open that judge's breakdown on the Ledger.

The summary line

Above the table, one line describing the rows currently in front of you:

12 payments · $4,180.00

It follows your search and your filters. Narrow the list and both numbers narrow with it — this is a summary of the list, not of the season. The season's figures live on the Ledger, on the three cards at the top of it, and are the only figures that claim to be season-wide.

Voided payments are counted in the number and left out of the total, with an amber note beside it saying so — "2 voided, excluded from the total". A voided payment is money that came back, so it is not money that went out; counting the row keeps the line honest about how many rows you are looking at.

Searching and filtering

The toolbar above the table:

Search is headed "Search judge or reference" and matches exactly those two things — not the amount, and not the internal note. It filters as you type, with no delay and no Search button, because the whole log is already on screen. The ✕ inside the box clears it.
Method — Bank transfer, Check, PayPal or Venmo, Cash, each with a count.
Status — Active and Voided, each with a count.
Clear filters appears as soon as anything is set.

Every option is always listed, including the ones at zero. Both lists are fixed vocabularies, so "nothing was paid by check" never looks like "no Method filter".

A payment matches if it is one of the methods ticked and one of the statuses ticked; ticking nothing in a filter means that filter is not narrowing anything.

The counts beside the options never move as you tick boxes. They are measured across every payment in the season, so they tell you what turning a filter on would find rather than measuring your own filter back at you.

None of this is kept. The search and both filters are working state: they reset when you reload, they are not in the address, and a link you send a colleague opens the whole log.

On a narrow window the two filters collapse behind a single Filters button carrying a count of what is set.

Voided payments

A logged payment is never edited and never deleted, and voided ones stay on this list by default — a payments log that could be tidied up is not a record.

A voided row:

is drawn quieter than the rest, with the amount, the method and the reference struck through — the three things the payment claimed;
keeps its date, judge and Covers in plain text, because those are still true;
carries an amber line under Logged by — "Voided by Ada Chen — logged against the wrong judge" — naming who voided it and the reason they gave;
keeps its receipt link working, which is the point: the receipt is the evidence of what was claimed, and the moment it matters most is when the row has been voided;
offers no Void button, having been voided already.

To read the log without them, tick Active under Status.

Voiding from this screen

Void, at the end of a row, opens the same confirmation the Ledger uses:

Void the $250.00 payment?

The payment stops counting toward Paid and comes back into Outstanding. The record stays, struck through, with your name and this reason — and its receipt stays attached. A void cannot be undone; log a new payment instead.

Write a reason. It is required, it is shown on the row afterwards, and it is never shown to the judge.
Press Void payment.

The dialog names the amount, not the judge, so check the row you are on before you confirm — two judges can have been paid the same figure on the same day.

On success the dialog closes, "Payment voided." appears briefly, and the row re-draws struck through where it stands. The Ledger's figures move at the same time: that judge's Paid falls and their Outstanding rises. If the payment paid an invoice, that invoice goes back to Accepted, waiting to be paid again — see Judge invoices.

If somebody voided the same payment a moment before you, the dialog stays open and says "This payment is already voided." Nothing is voided twice.

On the judge's own statement the payment simply vanishes and their balance goes back up — see The pay statement. On their Earnings screen's Payments tab, though, the voided payment stays listed, struck through with the date it was voided — your reason is never shown to them. Voiding a payment a judge may already have seen is still worth a message to them.

Receipts

View receipt opens the file that was attached when the payment was logged — a PNG, a JPEG or a PDF — in a new tab. Nothing is attached here; receipts go on with the payment, on the Ledger.

A payment with no receipt shows an em dash, never a link that fails.
The link is built when you click it and is good for about an hour. So the address of the file itself, copied out of the new tab, will not open tomorrow — come back and press View receipt again instead.
Receipts are never shown to the judge, on their statement or anywhere else.

The two empty states

Two, because they need two different answers:

Nothing logged this season — "No payments logged yet", with "Payments are logged against a judge on the Ledger tab, where their balance is. Every one you log appears here." and an Open the Ledger button.
Your filters matched nothing — "No payments match these filters", with the number logged this season and a Clear filters button. You are never told the season is empty when it is your filter that is.

Volunteer seasons

A season whose own judge pay setting is Volunteer shows a notice instead of a ledger on the first tab — but this tab still lists any payments that exist. Hiding money that moved is the one thing a payments log must never do.

A paid season with volunteers on it is a different case, and neither tab hides anything: the Ledger lists those judges at $0.00 and this log lists whatever was actually paid. See A volunteer judge on a paid season.

What this screen does not do

Log a payment. That happens on the Ledger, where a judge is chosen first and their outstanding balance is in front of you, or with Mark paid on an invoice or on its line under the Ledger's Invoices to pay.
Edit a payment. Void is the only correction, and it is permanent.
Show the internal note, or which films a payment covered. Both are in the judge's breakdown on the Ledger. This log reports how many scorecards were named, never which.
Say anything about a judge's terms. Whether somebody is paid or volunteering is not a column here, and no payment row implies either.
Sort. The order is fixed: newest date paid first, with payments logged on the same day in the order they were recorded, newest first.
Total the season. The line above the table describes the rows listed. The Ledger's three cards are the season's figures.
Export. There is no CSV of this log.
Cover more than one season. Each Payouts section belongs to the season in the address; there is no festival-wide or cross-season roll-up.

Paying your judges — the Ledger: what each judge is owed, logging a payment, the breakdown drawer and the pay statement.
Judge invoices — the Invoices tab beside this one, and Mark paid, which writes a row here.
Judge pay — where the money starts: the two rates every category carries, and the season's Paid or Volunteer setting, which is a ceiling over each judge's own terms rather than a rule about all of them.
Your pay statement — the judge's own copy of their statement, and why a voided payment is absent from it entirely — and Earnings, the judge's screen whose Payments tab is the one place on their side a voided payment still shows, dated and struck through, without the reason.
Festival access — the View revenue and payouts permission, role by role.
Review Queue — approving a scorecard is what makes it payable in the first place.