What Is Payment Reconciliation? Matching PSP Payouts to the Ledger
Why a Stripe payout never equals your invoices, how to decompose a settlement into sales, fees and refunds, and how the ledger entries actually work.
Payment reconciliation is matching what a payment service provider actually paid you against what your customers actually owed you. It is a different problem from bank reconciliation, and harder, because a PSP payout is never one payment for one invoice.
The defining symptom: you sold 10,000 €, and 9,712.40 € arrived in the bank. Both numbers are correct. Everything in between is what this reconciliation explains.
Why the payout never matches the sales
A single Stripe, Adyen or PayPal payout is a net batch. Between the customer paying and the money landing, the PSP has:
- aggregated many charges over a settlement period,
- deducted its fees per transaction,
- deducted refunds and chargebacks that occurred in the same window,
- possibly withheld a reserve,
- and paid the remainder days later, in one transfer.
So the bank statement shows one line — 9,712.40 € — while the ledger has dozens of invoices, none of which equals it. Matching the payout to invoices directly is impossible; the payout has to be decomposed first.
The decomposition
A settlement batch breaks into categories, and each category means something different to the ledger:
| Category | What it is | Ledger effect |
|---|---|---|
| Charges | Customer payments | Settles receivables |
| Refunds | Money returned to customers | Reverses a settled receivable |
| Fees | PSP's commission | An expense |
| Chargebacks | Disputed payments clawed back | Re-opens a receivable, plus a fee |
| Adjustments / reserves | Timing and risk holdbacks | A balance owed by the PSP |
The identity that must hold:
Gross charges − refunds − fees − chargebacks ± adjustments = Net payout
If it doesn't, the batch was imported incompletely — and that check is worth more than any individual match, because it proves nothing was silently dropped.
The entries
Posting a settlement batch of 10,000 € gross charges, 250 € fees, 37.60 € refunds:
| Account | Debit | Credit |
|---|---|---|
| 2710 Bank | 9,712.40 | |
| 6800 Financial expenses (PSP fees) | 250.00 | |
| 5000 Revenue / receivables reversal (refunds) | 37.60 | |
| 2410 Trade receivables | 10,000.00 |
Read it as: customers' debts of 10,000 € are cleared, the PSP kept 250 €, 37.60 € went back to customers, and 9,712.40 € reached the bank. The fee is a real expense that never appears on any customer invoice — which is exactly why gross revenue and bank deposits diverge, and why reconciling on the bank line alone silently understates both revenue and costs.
For marketplaces there is one more layer. If the payout includes money belonging to sellers, the platform's revenue is only its commission; the rest is a liability. Nordlet's posting rules cover this with dedicated keys — settlements.fees, settlements.commissionRevenue, settlements.sellerPayable and settlements.suspense — so a split payout posts commission to revenue and the seller's share to a payable rather than inflating platform revenue.
How Nordlet does it
The flow is three endpoints:
- Import.
POST /v1/bank/settlements/importreads a Stripe payout reconciliation report and creates a settlement batch — provider, payout ID, currency, gross, fees and net — with one line per underlying transaction, each carrying its category. Batches are unique per provider and payout ID, so re-importing the same report cannot double-count it. - Match.
POST /v1/bank/settlements/matchlinks charge and refund lines to the sale invoices they belong to. Lines carry a match status ofunmatched,matched(resolved automatically from the order or invoice reference in the report) ormanual(a human decided). Fee and adjustment lines are not matchable to invoices by design — attempting it is rejected rather than guessed. - Post.
POST /v1/bank/settlements/postwrites the ledger entries for the whole batch through the posting rules above and flips the batch status fromimportedtoposted. Unmatched receipts land in a suspense account rather than being forced onto an invoice — visible, and deliberately uncomfortable until resolved.
Two limitations worth stating. Settlements are handled in the company's base currency today, so foreign-currency payouts need manual treatment. And the batch is posted as a whole rather than being tied to the specific incoming bank-statement line on the real bank account — the two are reconciled by amount and date rather than linked automatically.
Doing it well
- Reconcile per payout, not per month. The payout is the natural unit; aggregating a month of payouts before reconciling destroys the identity check that makes errors findable.
- Never post the net amount as revenue. It is the single most common error in platform accounting: booking 9,712.40 € of revenue understates both sales and expenses, corrupts gross margin, and usually understates VAT — because VAT is due on the gross the customer paid, not on what the PSP forwarded.
- Watch the timing gap. A payment taken on 30 June and paid out on 3 July belongs to June's revenue and July's cash. At period end the difference sits as a receivable from the PSP — real money, in someone else's account.
- Reconcile refunds to the original sale. A refund that isn't linked back leaves a settled invoice looking paid and revenue overstated.
FAQ
What is the difference between payment reconciliation and bank reconciliation?
Bank reconciliation compares your ledger to the bank statement, line by line. Payment reconciliation sits one level earlier: it decomposes a single PSP payout into the many charges, refunds and fees behind it, so those bank lines can be explained at all.
Why doesn't my Stripe payout match my sales?
Because a payout is a net batch: gross charges minus fees, refunds, chargebacks and any reserve, settled on the PSP's schedule rather than the invoice's. Every one of those components has to be accounted for separately for the two figures to reconcile.
Should PSP fees be netted against revenue?
No. Revenue is the gross amount the customer paid; the PSP fee is an expense of collecting it. Netting them understates revenue and costs alike, distorts margins, and generally gets the VAT treatment wrong.
How are marketplace splits handled?
The platform's revenue is its commission; the seller's share is a liability until it is paid out. Posting the whole payout as revenue overstates the platform's income enormously — separate posting rules for commission revenue and seller payable exist precisely to keep them apart.
What happens to unmatched settlement lines?
They post to a suspense account rather than being forced against an invoice. That keeps the ledger balanced and the problem visible; the suspense balance is a work list, and it should be empty before the period closes.