The chargeback lifecycle
Provisional reserves, the resolution, and the moment money becomes a loss.
By Solomon Ajayi · Free to read, no signup
A customer disputes a ₦5,000 card payment from last month with their bank. The bank issues a chargeback. Your provider immediately deducts the disputed amount from your account, pending resolution. Weeks later the dispute resolves: you either win (the money comes back) or you lose (the deduction stands). Three ledger events across two months.
A chargeback is not a refund you chose to give; it is money pulled away from you while the question of who is right is still open. The customer's bank yanks the funds first and decides later. So your books have to hold a state that neither of the easy options captures: the cash is gone from your account, but you might get it back. That uncertainty is the whole reason this needs more than one entry.
You model the uncertainty as a provisional asset. When the provider deducts the ₦5,000, your Bank Account drops and a Chargeback Provisional asset rises to mark what you may yet recover. You do not touch the original revenue, because you do not yet know the sale was bad. Only when the dispute resolves do you commit: if you lose, the provisional asset converts into a Chargeback Loss expense; if you win, it converts back into cash.
Notice what stays untouched: the original Sales Revenue. The sale genuinely happened, and a loss from a dispute is a separate economic event that belongs in its own expense account. Keeping them apart is what lets investors see gross sales and bad-actor losses as two distinct numbers, instead of one quietly netted figure that hides how much fraud you are absorbing.
Worked example, step by step
Original sale (last month, for context)
A ₦5,000 card sale settled cleanly last month. Cash in bank, revenue recognized. Standard flow.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦5,000.00 | |
| Sales Revenue (4000) | ₦5,000.00 |
Just establishing the baseline. The customer's ₦5,000 is in your bank and recognized as revenue. This is the state BEFORE the chargeback hits.
Chargeback hits: provider yanks ₦5,000 from your bank
Today: the customer disputed. Your provider deducted ₦5,000 from your bank IMMEDIATELY, pending resolution. You do not yet know whether you will win the dispute. Treat the deduction as a provisional asset, if you win, you recover it.
| Account | Debit | Credit |
|---|---|---|
| Chargeback Provisional (1500) | ₦5,000.00 | |
| Bank Account (1200) | ₦5,000.00 |
Bank Account DOWN ₦5,000 (provider already pulled it). Chargeback Provisional (asset) UP ₦5,000, you may recover it. Revenue is NOT yet reversed; you don't know whether the dispute is valid. Critical: do NOT delete the original sale entry. Immutable audit trail, remember Lesson 5.
Three weeks later: you LOST the dispute
The bank ruled for the customer. The deduction stands. The provisional asset is now a real loss.
| Account | Debit | Credit |
|---|---|---|
| Chargeback Loss (5100) | ₦5,000.00 | |
| Chargeback Provisional (1500) | ₦5,000.00 |
Chargeback Provisional (asset) clears to zero. Chargeback Loss (expense) UP ₦5,000. Note: we do NOT reverse the original Revenue entry. The sale happened; the loss is a separate event. This is the standard accounting treatment, revenue and loss live in different ledgers so investors can see both gross sales and bad-actor losses.
Takeaway
A chargeback is a multi-stage event. Treat the initial provider deduction as a PROVISIONAL asset (you might recover it). Convert to expense only when you lose. Never reverse the original revenue, the sale happened, the loss is separate. Chargeback rate is one of the metrics that gets fintechs cut off by their payment providers; build the books to track it cleanly from day one.
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.