1. The ledger is the only source of truth
Most software stores the answer (the user's balance is ₦1,000) and forgets the question (how did we get there?). Ledger-based systems do the opposite: they store every event that ever moved money, and compute the answer from those events on demand.
Why bother? Because the day a regulator, auditor, or angry customer asks "why does this number exist?", the only acceptable answer is an exhaustive list of every event that contributed to it. Caching the answer without the events is how fintechs end up paying seven-figure compliance fines and rewriting their core systems in year two.
The "events" are called journal entries. The book they live in is called the ledger. Everything else (the wallet balance you see in the app, the statement you download, the dashboard the CFO stares at) is computed FROM the ledger and can always be rebuilt from it.
2. Every event has two sides
When money moves, it moves from somewhere to somewhere. That's not a metaphor; it's the entire rule. A journal entry has at least two lines, and they have to balance. If you receive ₦10,000 from a customer, the same ₦10,000 has to land somewhere: probably your bank account. Two lines, same amount, opposite sides.
The two sides are called debit and credit. The names are unhelpful (they're not "in" and "out") and there's no way to make them intuitive in one sentence. Just accept them as labels for "left side of the entry" and "right side of the entry" and move on. Which side increases what depends on the account type, which is the next idea.
3. There are exactly five kinds of account
Every account on a ledger is one of five types. The type determines whether debits or credits increase the balance. You can memorise the table in 30 seconds:
| Type | Goes UP on | In plain English |
|---|---|---|
| Asset | Debit | Something you OWN or are OWED. Cash, equipment. |
| Liability | Credit | Something you OWE. A customer's wallet balance is YOUR liability. |
| Equity | Credit | What the owners would have left after liabilities are paid. |
| Income | Credit | Money you earned. Sales, fees, interest. |
| Expense | Debit | Cost of doing business. Salaries, server bills. |
That's the whole table. Lessons 1 through 4 walk you through every type with concrete entries. By the end of lesson 4 it'll be automatic.
4. The user's "wallet" is a liability on your books
This is the part that trips up most engineers from day one. When a user has ₦5,000 in your fintech app, the user thinks of that as "my money". From your accounting system's perspective, that ₦5,000 is something you owe the user. It's a liability, sitting next to "rent you haven't paid yet" on your balance sheet.
Both views are right. The user can spend it freely; you owe it to them on demand. The dual nature is the whole reason fintechs use this accounting system: it's the only model that correctly tracks "I have the money in my bank, but I owe most of it to my customers."
This is why naive systems with a wallet.balance column eventually break. They model the user's view (what the user has) without the other side (what you owe). The day you have to answer "where did this ₦5,000 come from?" or "did we double-pay anyone?", you can't.
5. The rules are boring, the consequences are not
Debits = credits. Assets = Liabilities + Equity. Entries are immutable. These three rules are the whole foundation. They feel like clerical bookkeeping until you realise they're the reason you can answer questions about your business that no other architecture can answer.
"How much did we owe customers exactly at 23:14 on March 15?" The ledger has it; the cache doesn't. "Did we ever credit this user twice for the same transaction?" The ledger proves yes or no; the cache shrugs. "Why does our bank balance disagree with our books by ₦127?" The ledger lets you trace every entry; the cache lets you cry.
The 85 lessons in this curriculum are all consequences of these five ideas plus their engineering implications. Start at lesson 1 and the entire system unfolds from a single ₦10,000 deposit.
You're ready
That's the whole mental model. If anything's still fuzzy, the glossary and the cheat sheet cover the specifics, and the why behind it all sits one level above. Otherwise, start at lesson 1 and the rest falls out naturally.