Settlement netting
Many entries on your books, one wire on your bank statement.
By Solomon Ajayi · Free to read, no signup
Yesterday your platform processed 100 user deposits totaling ₦500,000. Your provider doesn't wire you 100 times. They net it: one wire today for ₦492,500 (after their 1.5% aggregate fee). Your ledger has 100 individual entries; your bank statement has one line. Reconciliation is the practice of joining those two views without losing data on either side.
Your ledger and your bank statement record the same money at different granularities. You track every deposit individually, because you have to credit each user their exact amount and answer for each one. Your provider batches them, because wiring you a hundred times a day would be absurd, so it nets the whole batch into a single transfer and skims an aggregate fee off the top. One side has a hundred rows; the other has one line.
The settlement entry is where the two views meet. The single wire lands in your Bank Account, the aggregate fee becomes a Provider Fee Expense, and the gross Provider Receivable that the hundred deposits built up clears in full. The fee is the gap between what you were owed and what arrived. You never expand the wire back into a hundred pieces; you collapse your hundred entries up to the wire and check that the math reconciles.
Holding both views without throwing either away is the entire job. You keep the per-user detail for your obligations and your audits, and you keep the netted wire as the cash reality, linked by the receivable that bridges them. The discipline is matching the sum, not the line count, because the provider's one wire will never line up one-to-one with your individual entries.
Worked example, step by step
Yesterday's 100 deposits (consolidated for this lesson)
100 user deposits of ₦5,000 each hit your platform. In reality these would be 100 separate journal entries, for this lesson we collapse them into one aggregate to focus on the netting.
| Account | Debit | Credit |
|---|---|---|
| Provider Receivable (1100) | ₦500,000.00 | |
| User Wallets (aggregate) (2000) | ₦500,000.00 |
Provider Receivable UP ₦500,000 (the provider now owes us this gross total). User Wallets UP ₦500,000 (we credited 100 users their ₦5,000 each). This is yesterday's state on your books.
Today: provider sends ONE wire of ₦492,500 (1.5% netted fee)
Bank notification fires once. ₦492,500 received from provider. The 1.5% fee applies to the aggregate (₦500,000 × 1.5% = ₦7,500), not to each individual deposit.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦492,500.00 | |
| Provider Fee Expense (5000) | ₦7,500.00 | |
| Provider Receivable (1100) | ₦500,000.00 |
Bank UP ₦492,500. Provider Fee Expense UP ₦7,500 (the aggregate fee). Provider Receivable DOWN ₦500,000 (settled in full). Your books show 100 user wallet credits + 1 bank inflow + 1 fee. Reconciliation joins them: aggregate the 100 ledger entries by date and provider, match the sum to the bank wire, and the fee is the difference.
Takeaway
Settlement netting is when many granular events get aggregated into one cash movement. Your books MUST be able to reconcile granular entries against aggregated bank movements: aggregate by date + provider, match the sum to the wire, the difference is the fee. This is where reconciliation tooling lives, and it is the single most common source of 'why doesn't our bank balance match the ledger' incidents at every growing fintech.
Practice this on a real ledger
Reading is half of it. Open this lesson in the lab to post the entries yourself against a real Postgres-backed double-entry ledger, with the validation on. Free, your sandbox is yours.