The refund
Why 'just delete the transaction' is the most expensive mistake.
By Solomon Ajayi · Free to read, no signup
Yesterday a user deposited ₦10,000 via card. Today they want a refund. Junior engineers reach for DELETE. Real ledgers add a counter-entry that reverses the original without erasing it. Your audit trail must be immutable. Watch how the books unwind without losing a single line of history.
A refund is not an undo. The original transaction really happened, the money really moved, and a regulator may ask you about it years from now. So you do not erase it. You post a new entry that moves the money back, leaving the original sitting in the ledger forever. The books end up net-zero on that transaction, but the full story, what happened and what corrected it, is preserved line by line.
The instinct to reach for DELETE comes from thinking of the database as the current state. A ledger is not current state, it is history, and you can append to history but never rewrite it. This is the same principle as a bank statement: you never watch a transaction vanish, you see a reversal posted next to it. Immutability is the whole point, not an inconvenience.
Refunds also force you to make policy explicit in the entries themselves. Is your platform fee refundable? If yes, you reverse the revenue line too; if no, you leave it and the user gets back less than they paid. The ledger puts that decision in plain sight and on the record, instead of burying it in application code.
Worked example, step by step
Yesterday's deposit (recap)
Quick recap of where we are. Yesterday's ₦10,000 deposit hit five accounts. The user's wallet shows ₦9,900 (after our 1% platform fee). The provider owes us ₦9,850 (after their 1.5% fee).
| Account | Debit | Credit |
|---|---|---|
| Provider Receivable (1100) | ₦9,850.00 | |
| Processing Fee Expense (5000) | ₦150.00 | |
| User Wallet (2000) | ₦9,900.00 | |
| Platform Fee Revenue (4000) | ₦100.00 |
This is the state you're starting from. Notice every account that moved. The refund will need to undo this in the right places.
Refund the user (platform fee non-refundable)
User wants their ₦9,900 back. Your platform fee policy is non-refundable, so they only get the wallet balance. The provider returns ₦9,900 by deducting it from your next settlement.
| Account | Debit | Credit |
|---|---|---|
| User Wallet (2000) | ₦9,900.00 | |
| Provider Receivable (1100) | ₦9,900.00 |
We are NOT deleting yesterday's entry. We are POSTING A NEW ENTRY that reverses what needs reversing. The user's wallet drops to zero. The provider receivable drops by ₦9,900. The original deposit lines are still there in the ledger forever, that's what makes the audit trail immutable.
Takeaway
Ledger entries are immutable. A refund is a NEW entry, not a deleted one. The original entry stays in the database forever, every regulator and every auditor needs it to be there. 'Just delete the row' is how fintechs end up paying seven-figure compliance fines.
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.