The audit (capstone)
Three bugs. Three diagnoses. Three corrective entries.
By Solomon Ajayi · Free to read, no signup
You're reviewing a junior engineer's day of work. They posted seven journal entries today. THREE of them are wrong, each in a different way: a misclassified account type, a wrong amount, and a debit/credit reversal. Apply every entry to your ledger, then for each sandbox prompt: find the bad one in the Journal view, then post the corrective entry. This is the forensic capstone, you're learning the three bug shapes that every fintech audit eventually surfaces.
An audit is not about finding the one bug that crashed production. It is about proving the books say what reality says, line by line, and explaining anything that does not match. Every wrong entry in a ledger is wrong in one of a small number of ways, and once you can name the shape, the diagnosis and the fix become mechanical. This lesson is the whole course read backwards: instead of posting a correct entry, you stare at posted entries and ask what is off.
There are three shapes that cover almost every audit finding. Wrong type means the entry balanced but routed money to the wrong class of account, like booking a card deposit into Sales Revenue (income) when it should have credited User Wallet (a liability you owe back). Wrong amount means the shape is right but a digit slipped, a ₦500 refund posted as ₦5,000. Wrong side means debit and credit got swapped, so a service charge made the wallet go up instead of down. Each shape leaves a different fingerprint, and each needs a different corrective entry.
Notice that you never delete the bad entry. You post a new corrective entry that nets the books back to the truth, exactly as a refund did in Lesson 5. For wrong type you move the amount from the wrong account to the right one. For wrong amount you reverse only the difference. For wrong side you post double the correct entry, because you have to undo the wrong direction and apply the right one at once. The original mistake stays in the record forever, with its correction sitting beside it.
Worked example, step by step
Entry 1: ₦10,000 user deposit
Morning. A user deposited ₦10,000 via card. Engineer posted: Bank up ₦10,000, User Wallet up ₦10,000.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦10,000.00 | |
| User Wallet (2000) | ₦10,000.00 |
Apply it. Read on. Don't pre-judge any entry, just apply all seven, then start hunting.
Entry 2: ₦2,000 service charge
Mid-morning: user bought a premium feature, charged ₦2,000 from their wallet.
| Account | Debit | Credit |
|---|---|---|
| User Wallet (2000) | ₦2,000.00 | |
| Sales Revenue (4000) | ₦2,000.00 |
Apply it. Standard service-purchase shape: User Wallet down, Sales Revenue up.
Entry 3: Another ₦5,000 deposit
Noon: another ₦5,000 deposit. Engineer posted: Bank up, Sales Revenue up.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (1200) | ₦5,000.00 | |
| Sales Revenue (4000) | ₦5,000.00 |
Apply it. The entry is internally balanced (debits = credits), but is it routing the right account TYPES?
Entry 4: Software subscription ₦1,000
Early afternoon. Software subscription renewal, ₦1,000 paid from bank.
| Account | Debit | Credit |
|---|---|---|
| Operating Expense (5000) | ₦1,000.00 | |
| Bank Account (1200) | ₦1,000.00 |
Apply it. Expense entry: Operating Expense up, Bank down. Looks fine.
Entry 5: Refund ₦500 to a user
Customer service issued a ₦500 refund: take it from the user's wallet, return cash to bank, but actually a refund SHOULD be the other way (debit user wallet to clear what we owe, credit bank because cash leaves). The engineer typed the description as 'Refund ₦500' but typo'd one of the amounts.
| Account | Debit | Credit |
|---|---|---|
| User Wallet (2000) | ₦5,000.00 | |
| Bank Account (1200) | ₦5,000.00 |
Apply it. The shape is right (User Wallet debited, Bank credited). But scrutinise the amount.
Entry 6: Service charge ₦300
Mid-afternoon: another user bought a premium feature, ₦300. Engineer posted this one in a hurry.
| Account | Debit | Credit |
|---|---|---|
| User Wallet (2000) | ₦300.00 | |
| Sales Revenue (4000) | ₦300.00 |
Apply it. Same shape as Entry 2, except… compare the debit/credit sides carefully.
Entry 7: Office stationery ₦200
End of day: office stationery purchase ₦200, paid from bank.
| Account | Debit | Credit |
|---|---|---|
| Operating Expense (5000) | ₦200.00 | |
| Bank Account (1200) | ₦200.00 |
Apply it. Operating Expense up, Bank down. After all seven are posted, switch to the Journal view and start the hunt.
Takeaway
Audit bugs cluster into three shapes: WRONG TYPE (account class doesn't match reason code), WRONG AMOUNT (typo on the number), WRONG SIDE (debit/credit swapped). Each requires a different corrective entry. The fix is always a NEW corrective entry, never a delete. Tooling that surfaces anomalies automatically, reason_code vs account_type mismatches, description-amount-vs-line-amount mismatches, expected sign-by-account-type vs actual, catches these before they reach an external auditor. The diagnostic skill is more important than the fix; once you've named the bug shape, the corrective entry writes itself.
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.