A row-by-row review method for explaining deductions, carry-forward balances and an unresolved bank difference.
SYNTHETIC / ILLUSTRATIVE — NOT A CUSTOMER CASE
A fictional retailer ends a reporting period with EUR 2,900.00 of completed point-of-sale tenders. Its settlement reports contain EUR 2,700.00 of gross card receipts. The processor issues EUR 2,474.00 in payouts, while the receiving-bank snapshot contains EUR 1,466.50 of credits.
Which number should the controller reconcile?
All four, but through different populations and dates. The completed tenders include cash. Some captured card payments entered the period unsettled; another capture remains unsettled at the end. Refunds, disputes, fees and a restricted deposit change the processor balance. One payout has not reached its expected arrival date. Another has a matching bank reference but is EUR 7.50 short.
The useful result is an explanation that preserves those distinctions. In this example, the processor payable balance reaches zero while the bank reconciliation remains open.
The practical takeaway
Build the expected settlement and payout amounts before looking at the bank total. Then test the observations against that expectation, keeping each unresolved item attached to its records, evidence gap and reviewer.
This is a proposed Treasury Desk public-source review method with a synthetic demonstration. It is not a description of a shipped merchant-data integration, automated reconciliation service or customer result. The method supports human review; it does not execute payments or provide an accounting, tax or legal opinion.
The reference schema is Adyen’s settlement reporting. Stripe is used only to show where a mapping cannot be carried across unchanged. This is not a provider comparison or a recommendation to connect either service.
Start with the documents, not the bank difference
Adyen’s Settlement details report distinguishes transaction journals from account-level movements and merchant payouts. Its aggregate report adds batch-level views, including batch closure and an optional payout reference. Neither document replaces the receiving bank’s records.
For this review method, use the following evidence contract.
| Document | What the reviewer establishes | What remains unproven |
|---|---|---|
| POS, order and card-tender export | The selected tender population, exclusions and merchant references | Capture, settlement or bank receipt |
| Capture and processor event records | Individual captures, event dates and links to original payments | A completed payout to the bank |
| Settlement batch and fee evidence | Booked gross, deductions, net movements and applicable fee scope | Receipt or cash availability at the receiving bank |
| Deposit statement and payout advice | Restricted movements, the instruction, amount and expected arrival basis | The corresponding bank booking |
| Receiving-bank statement | Observed booking, amount, reference and value date in its scope | Unconditional cash availability without additional evidence |
Preserve source-file and row references alongside the normalized working fields. A matching amount alone is insufficient: the currency, merchant scope, reference and event population must also agree. Keep booking date, value date and cash-availability evidence separate.
Define the card population and its clocks
SYNTHETIC / ILLUSTRATIVE — NOT A CUSTOMER CASE. The example covers 21–25 September 2026 for one fictional merchant and store, settling only in EUR. The cutoff is 25 September at 23:59:59, Europe/Paris, UTC+02:00. Research on 28 September does not extend that observation window.
Completed POS tenders of EUR 2,900.00 consist of EUR 2,600.00 of card tenders and EUR 300.00 of cash. Failed authorizations of EUR 50.00 and voided attempts of EUR 40.00 sit outside that completed population. They are not additional card receipts.
The capture bridge is:
EUR 200.00 opening captured carry + EUR 2,600.00 current captures − EUR 2,700.00 settled captures = EUR 100.00 closing captured carry.
The opening EUR 200.00 was captured before the period and settles in Batch 101. The closing EUR 100.00 was captured on 25 September but has no settlement booking by the cutoff. Gross card receipts are used here as a payment-population measure, not automatically classified as accounting revenue.
This timing structure is consistent with the distinction in Adyen’s pass-through payout documentation: payments from one sales day can enter different settlement batches. Adyen also documents partial-capture support and configuration requirements. The example assumes a supported, enabled configuration; it does not establish one for an actual merchant.
Keep the native fields and normalize their meaning
For the Adyen mapping, retain Merchant Account, Psp Reference, Merchant Reference, Modification Reference, Type, Batch Number and the gross/net currency and debit/credit fields. Preserve Dispute Reference when relevant and available. Add local event, capture, payout and bank-line IDs rather than treating a payment reference as a unique identifier for every subsequent event. The report’s field descriptions explain those references and optional columns.
Dates require the same care. In that report, Creation Date identifies original payment creation; it should not be relabeled as capture time. Use the documented booking fields and their time zone, plus a separately supported capture timestamp. The Payment accounting report provides event-oriented booking information with its own field definitions.
Normalize processor movement as net credit minus net debit. For a settled capture, its fee is already reflected in that net amount. Use either Commission (NC) or its Markup (NC), Scheme Fees (NC) and Interchange (NC) components, according to the report representation—not their combined sum. This total-versus-components distinction is documented in the settlement schema.
The annotated gross-to-net bridge
SYNTHETIC / ILLUSTRATIVE — NOT A CUSTOMER CASE. All amounts in this table are EUR. Signs describe their effect on the modeled processor payable. Opening and retained closing payable are zero for each illustrated batch; there are no balance transfers.
| Movement | Batch 101 | Batch 102 | Batch 103 | Period total |
|---|---|---|---|---|
| Settled capture gross | 1,000.00 | 800.00 | 900.00 | 2,700.00 |
| Inline capture fees | −20.00 | −16.00 | −18.00 | −54.00 |
| Refund of an earlier sale | 0.00 | −100.00 | 0.00 | −100.00 |
| Chargeback | 0.00 | −80.00 | 0.00 | −80.00 |
| Chargeback reversal | 0.00 | 0.00 | +80.00 | +80.00 |
| Restricted-deposit hold | 0.00 | −100.00 | 0.00 | −100.00 |
| Restricted-deposit release | 0.00 | 0.00 | +40.00 | +40.00 |
| Invoice amount due | 0.00 | −10.00 | 0.00 | −10.00 |
| Separate processing fee | 0.00 | 0.00 | −5.00 | −5.00 |
| Prior invoice credit | 0.00 | 0.00 | +3.00 | +3.00 |
| Net movement / expected payout | 980.00 | 494.00 | 1,000.00 | 2,474.00 |
The teaching fee is 2.00% of each settled capture’s gross, rounded half-up to EUR 0.01 per capture. Batch 101 uses total commission; Batches 102 and 103 use components totaling the same rate. The EUR 5.00 fee is a separate assumed item. Incremental refund and dispute fees, taxes and tips are zero by scope assumption; earlier capture fees are not returned in the example.
These are not provider prices or a merchant contract. Adyen’s public pricing page distinguishes processing and payment-method fees. Actual negotiated fees and assessment bases remain unknown here. A reviewer should establish them from the applicable contract and invoice, not infer a rate from a bank shortfall.
Invoice scope also matters. Adyen’s invoice documentation distinguishes amounts already deducted from settlement from the amount still due. The model deducts only the assumed EUR 10.00 amount due and adds a separately evidenced-in-the-example EUR 3.00 prior credit. It does not subtract an entire invoice again.
Follow the records through each batch
Batch 101 provides the ordinary matched case. An opening capture of EUR 200.00 and a current capture of EUR 800.00 incur EUR 4.00 and EUR 16.00 of assumed fees. The resulting EUR 980.00 payout is issued on 21 September and matches a EUR 980.00 bank credit on 22 September. Its synthetic reference and amount agree.
Batch 102 demonstrates why gross and bank credit need an intervening calculation. Partial capture SYN_CAP_S1 of EUR 300.00 and a separate EUR 500.00 capture produce EUR 800.00 gross and EUR 16.00 of inline fees. The batch also contains the EUR 100.00 refund linked to the 15 September sale SYN_PAY_OLD_REF, the chargeback, deposit hold and invoice deduction. Those rows produce an independently expected EUR 494.00 payout, issued on 22 September.
The bank snapshot contains EUR 486.50 on 23 September with the payout’s reference. That supports the link, but not a complete amount match. EUR 494.00 − EUR 486.50 = EUR 7.50 unexplained. There is no fee notice, conversion record or correction in the example that explains it.
Batch 103 separates a later capture from a new sale. The next EUR 200.00 capture, SYN_CAP_S2, belongs to the same EUR 600.00 parent payment, SYN_PAY_SPLIT, as Batch 102’s EUR 300.00 capture. The final EUR 100.00 capture, SYN_CAP_S3, remains unsettled. The parent therefore has EUR 500.00 settled across two batches and EUR 100.00 carried forward—not EUR 600.00 of new sales in each batch.
An additional EUR 700.00 capture brings Batch 103 gross to EUR 900.00. Its EUR 80.00 chargeback reversal links to the earlier EUR 80.00 chargeback through original payment SYN_PAY_OLD_CB and dispute SYN_DISPUTE_01. Keep both events, even though their combined effect is zero. The original sale is not added again. Together with the deposit release, separate fee and prior invoice credit, this batch produces EUR 1,000.00.
The payout is issued on 24 September. Its assumed advice says expected arrival is 28 September and records it as issued, not returned. No bank line exists by the 25 September cutoff. Those facts support an in-transit classification within the example, not an observed receipt or a provider delivery guarantee.
Reconcile balances as well as batches
The restricted-deposit movement has two legs. Adyen distinguishes its risk-related Deposit from the operational Reserve used for a different balance-management purpose. This example maps the restricted amount to DepositCorrection, not ReserveAdjustment. The assumed hold and release do not reproduce Adyen’s deposit-sizing calculation.
A EUR 100.00 hold reduces modeled payable and increases restricted deposit; the EUR 40.00 release does the reverse. The release is not a new sale. If a provider’s total balance already includes restricted funds, normalize that presentation before subtracting the hold again.
SYNTHETIC / ILLUSTRATIVE — NOT A CUSTOMER CASE. The period controls are:
| Control | EUR calculation | Result |
|---|---|---|
| Processor payable | 0.00 + 2,474.00 non-payout movements − 2,474.00 payouts | 0.00 |
| Restricted deposit | 200.00 opening + 100.00 held − 40.00 released | 260.00 |
| Payout clearing | 0.00 opening + 2,474.00 issued − 1,466.50 bank credits − 0.00 returns | 1,007.50 |
| Clearing classification | 1,000.00 in transit + 7.50 unexplained | 1,007.50 |
| Credits expected by cutoff | 980.00 + 494.00 − 1,466.50 observed | 7.50 unexplained |
Do not label the full EUR 1,007.50 as confirmed in transit. EUR 1,000.00 has its own instruction and expected-date evidence; EUR 7.50 remains unexplained on a different payout. The residual is calculated at the payout level before it is classified in the clearing balance. It is not a balancing plug.
The calculations use integer cents and Decimal rounding. A reproducible script checks rows, batches, populations and balances, including rejection tests for duplicated events and double-counted fee representations. Passing those checks does not resolve the missing EUR 7.50.
Give open items an owner and an evidence request
SYNTHETIC / ILLUSTRATIVE — NOT A CUSTOMER CASE. Aging is measured at the 25 September cutoff. The two-calendar-day escalation threshold is a teaching assumption, not an industry service-level commitment. Owner labels are roles, not evidence that a person has approved anything.
| Item | Amount, EUR | Aging basis | Reviewer role and closure evidence |
|---|---|---|---|
| Payout 102: expected 494.00; bank record SYN_BANK_02 shows 486.50 | 7.50 | Two days since expected arrival on 23 September | Finance operations/controller: remittance, bank movement or documented correction explaining the amount |
| Payout 103 in transit | 1,000.00 | Expected 28 September; not yet overdue | Treasury operations: matching bank credit or documented return and corresponding processor movement |
| Final partial capture | 100.00 | Captured 25 September; age zero | Payment operations: subsequent event resolving that exact capture and the carry-forward |
| Restricted deposit monitoring | 260.00 | No release due date established | Controller: balance and applicable release evidence before treating it as available |
The deposit line is a classification control, not an unexplained discrepancy. Nor does an aging threshold prove loss or fraud. Two unmatched items of equal and opposite amounts must remain open until each has evidence; an aggregate zero cannot close them.
Reviewer checklist and limits
Before closing a review, verify the population and time zone; capture and original-payment links; one-sided debit/credit signs; fee representation and invoice coverage; restricted-balance scope; independently established payout expectations; bank reference, amount and dates; and evidence for every exception closure.
Portability needs a separate mapping. Stripe’s payout reconciliation report has automatic-payout scope and expected-arrival fields; its available_on concerns Stripe balance availability, not bank receipt. Its withheld_tax is included in fee, so subtracting both would double count it. Stripe’s balance report has a different transaction-to-payout scope. Similar field names do not make the reports interchangeable.
The main example contains no tax or tip amounts and makes no jurisdictional classification. A real tax or fee-inclusion question needs the exact documents and qualified review. FX also requires a separate currency bridge with a documented rate, orientation, conversion date and rounding basis. Without that evidence, do not call an unexplained difference “FX.”
Both synthetic bank credits are booked, with value dates retained, but cash availability is not established. Neither a payout status nor a matched bank line is offered as a universal statement of legal finality.
The outcome is a reviewable explanation: EUR 2,700.00 settled gross, EUR 2,474.00 issued, EUR 1,466.50 observed at the bank, EUR 1,000.00 in transit and EUR 7.50 still requiring evidence. Keep that last line open until the records explain it.
For the broader editorial boundary, see Treasury Desk’s methodology and legal scope.