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 percentage 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 2 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, rows 3 and 6 catch it, one from each side.
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 percentage fees, refunds and chargebacks through Adyen, and Adyen's fees on those 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, less the refunds and chargebacks that went through Adyen, less Adyen's refund and chargeback fees where the clinic's own balance account was charged |
2 | 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 |
3 | 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 invoice carries no legal entity of its own, so the movements card cannot attribute it. This is where the two sides' different definitions of entity show up, seen from the entity that received the cash, and a direct measure of the invoices missing a legal entity. It reads nil unless a legal entity is selected | 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 |
4 | Paid out in the period, with no record in our ledger | Adyen paid out a payment there is no posting for. It covers Adyen's zero-value verification charges, which our ledger never records and which the Payments report shows as Verification Net, and any payment our ledger genuinely lacks. Read a large figure here as a finding | The payment is in Adyen's captures for these sweeps and appears nowhere in our payments, in any period |
5 | 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, and the accrual a reconciler needs at a period end: money Adyen still owes the clinic at the closing date | The payment is in the period's collected set, absent from these sweeps' captures, and was not swept inside the period under any entity, but has been swept at some point |
6 | Collected in the period, paid out under another legal entity | Row 3 read from the other side. Collected in the period on an invoice this entity owns, or on no invoice at all, and paid out inside the same period through a different entity's merchant account. Without this row the money would sit in row 5 and be called paid out after the period, which it was not. It reads nil unless a legal entity is selected, and it matters most on the no-entity option: every penny billed to no legal entity is paid out under some real one, so that slice shows the whole of it here | The payment is in the period's collected set, absent from these sweeps' captures, but present in the captures for all sweeps in the period computed without the legal entity filter |
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: what we recorded net of the two percentage fees against what Adyen actually settled. 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 through Adyen the ledger recorded in the period. A refund can fall inside one clock's window and outside the other's. Both sides include Adyen's fee on each refund where the clinic's own balance account bears it, because Adyen deducts it in the same payout | Adyen's payout lines of type |
10 | Chargeback timing between the two clocks | The same, for chargebacks and Adyen's chargeback fees | 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 |
Rows 3 and 6 are mirror images, and they prove each other. The same money appears in row 3 for the entity whose merchant account received it and in row 6 for the entity that billed it. Add row 3 up across every entity and you get the figure row 6 shows on the no-entity option, with the sign reversed. Both read nil with no entity selected, because then both clocks see everything and there is no attribution gap to name.
Adyen's refund and chargeback fees
Adyen charges a fixed fee on each chargeback, and on each refund of a Direct Debit payment. Until late September 2026 it charged both to wawa's platform balance account; for payments taken since then it charges them to the clinic's own balance account and deducts them in the clinic's payout, alongside the refund or chargeback they belong to.
The bridge counts these fees only where the clinic's own balance account was charged, the same rule as the movements card's fee rows. They enter on both sides: in row 1 through Net Adyen to clinic, and in Adyen's payout lines for rows 9 and 10. So a fee never appears as a timing difference on its own, and for periods before the change, when every fee fell to wawa, it does not enter the bridge at all.
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, their fees 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 all of it, and both are now identified sweep by sweep. The first is the one-off float. Adyen retains a balance on each legal entity's account so refunds and chargebacks can be paid without it going negative, and the money it held back to establish that float passed through a sweep without reaching the bank, which is exactly what this row reports. Seven sweeps between January and March 2026 carry it, 1,000.00 for each of the six entities, with The Hospital Fertility Group's arriving in two pieces of 0.13 and 999.87. They sum to 6,000.00, which is what the closing float balance reads today.
The second is a component line sitting in one month's sweep while its bank transfer landed in the next, which shows up as equal and opposite residuals in consecutive months. Four sweeps across October and November 2025 carry it: 30.34 and 35.09, each reversing exactly 8 and 10 days later. From April 2026 onwards the row is nil on every sweep.
Neither is netted off. There is no tolerance, and no row for the residual. Both are real events in the payout data rather than rounding differences, and a tripwire that quietly absorbed them would stop being able to tell you about the next thing that does not balance. A non-zero Unexplained on one of those periods is a statement about the payout data for that period, not about the report.
One thing this does not mean. The float is a balance rather than a flow, so it never enters the waterfall and no float column feeds this calculation. That is not the same as the float never appearing here: it appeared once per entity, in that entity's funding month, and not since.
Two rows are as at now, not as at the period end
Row 7, and to a lesser extent rows 5 and 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.