The one idea the card rests on
It is a reconciliation of a set of payments, not of a date range. Your ledger and Adyen's payout report run on different clocks: we count money on the day it was received, Adyen on the day it reached the bank. No choice of dates makes the two agree, because the minimum settlement lag is two days, so the last two or three days of any month are structurally paid out in the next one.
So the card does not compare totals. It takes every payment on each side, matches them on the PSP reference, and does a full outer join:
Our side is every Adyen-routed payment the ledger says was collected in the period, net of both fees.
Their side is every capture in the sweeps whose bank transfer has a payout date inside the period.
Every payment then falls into exactly one bucket, depending on which side it appears on, and each bucket contributes their figure minus ours. Rows 3 to 8 are those buckets. That is why the bridge closes: a payment cannot be in two buckets, and every payment on either side is in one.
Unexplained is what is left after all of it. It is a tripwire that should read zero, not a plug.
Which sweeps the card covers
Everything on the payout side is scoped to the sweeps whose bank row has a payout date inside the report period. Two consequences are worth knowing.
The legal entity filter is applied here, and it means the entity the sweep settled through, from legal_entities.adyen_integration_id, rather than the legal entity recorded on the invoices behind the payments. That is the same convention the bank payout cards use, and it is deliberately not the one the movements card uses. Where the two disagree, row 4 catches it.
Every row
# | Row | What it means | Where it comes from |
1 | Net Adyen to clinic, from Movements in the period | The opening figure: what the ledger says the Adyen-routed cash was worth once both fees, refunds and chargebacks are accounted for. It ties to the movements card's memo row of the same name | Our ledger. The sum of each payment's net, being gross less platform commission less processing fee, with refunds and chargebacks added back |
2 | add back refunds that never went through Adyen | Refunds the ledger recorded that Adyen's payout report cannot show, because Adyen never processed them. Added back so that both sides are counting the same population before the buckets start | Our ledger: refund movements carrying no PSP reference, being |
3 | Paid out in the period, collected before it | Adyen paid this out during the period, but it was collected earlier. Ordinary settlement lag, arriving from the previous month | The payment is in Adyen's captures for these sweeps and not in the period's collected set, and it was collected at some point |
4 | Paid out in the period, billed on an invoice carrying no legal entity | Adyen paid it out under this entity's sweeps, and it was collected in the period, but the ledger attributes it to a different entity, so the filter excluded it. This is where the two sides' different definitions of entity show up | The payment is in Adyen's captures and absent from the filtered collected set, but present in that same collected population computed without the legal entity filter |
5 | Paid out in the period, with no record in our ledger | Adyen paid out a payment there is no record of at all. Not a timing difference but a gap | The payment is in Adyen's captures for these sweeps and appears nowhere in our payments, in any period |
6 | Collected in the period, paid out after it | Collected during the period, and swept by Adyen in a later sweep. The other half of ordinary lag, going the other way | The payment is in the period's collected set and absent from these sweeps' captures, but has been swept at some point |
7 | Collected in the period, not yet paid out at all | Collected, and Adyen has never swept it. This row is as at now rather than as at the period end: it shrinks as sweeps happen, so on a settled month it reads zero and on the current month it does not | In the collected set, and the payment appears in no capture line ever |
8 | Fee and amount differences on payments in both | Payments both sides agree on, where the amounts still differ: a fee computed differently from what Adyen actually charged. Should read zero | The payment is on both sides, and the contribution is their net settled minus ours |
9 | Refund timing between the two clocks | Refunds Adyen debited from these sweeps, less the refunds the ledger recorded in the period. A refund can fall inside one clock's window and outside the other's | Adyen's payout lines of type |
10 | Chargeback timing between the two clocks | The same, for chargebacks | Adyen's payout lines of type |
98 | Unexplained | Everything the ten rows above do not account for. A tripwire that should read zero, and never a plug. It sits above the total it protects | The bank figure, less the sum of rows 1 to 10 |
99 | Paid to bank, from Bank payouts by legal entity | What Adyen actually transferred to the bank for these sweeps. Ties to the bank payouts card, and through that to your bank statements | Adyen's payout lines where the category is |
The columns, and why some cells are deliberately blank
The Amount column carries each row's own contribution, and Running total accumulates them down the card, so the running total on the closing row is the bridge's own computed answer.
Two cells are empty on purpose. Unexplained shows no running total, because it is measured against the total rather than being a step towards it. And the closing row shows no Amount, because it is not a movement: it is the destination.
Paid to bank (independent check) is blank on every row but the last, and that is the design rather than missing data. It is not a per-row figure. On the closing row it carries the bank total read straight from Adyen's payout report, independently of everything above it, so that two separate routes to the same number can be compared. If the running total and the independent check disagree, the bridge is wrong, and Unexplained says by how much.
What a non-zero Unexplained means, and what it does not
The card rests on a sweep being a closed unit: that for any one sweep, the captures, the refunds, the chargebacks and the bank transfer sum to zero. That holds for recent periods. It does not hold for every historical one, and on an older period Unexplained can be non-zero without anything being wrong with the report.
Two patterns account for what has been seen. A component line can sit in one month's sweep while its bank transfer landed in the next, which shows up as equal and opposite residuals in consecutive months. And the one-off float established on each balance account, when those accounts were first set up, lands in whichever month that happened.
Neither is netted off. There is no tolerance, and no row for the residual, because both explanations are inferred rather than proven, and moving money out of a tripwire on the strength of a matching sign is precisely what the tripwire exists to prevent. A non-zero Unexplained on an older period is a statement about the payout data for that period, not about the report.
Two rows are as at now, not as at the period end
Row 7, and to a lesser extent row 6, move as sweeps happen. Their sum is fixed once the period closes, but the split between them is not.
A closed and settled month is stable in practice and is the right thing to reconcile against a bank statement. The current month is not stable and should be read as a running position. This is the single most likely reason a re-run disagrees with an extract taken earlier.