Balance sheet at a point in time
Assets, liabilities, equity. The 'where you stand right now' query.
By Solomon Ajayi · Free to read, no signup
The balance sheet is the SNAPSHOT view of your fintech at a single instant. Assets (what you own) = Liabilities (what you owe) + Equity (what's left for shareholders). Like the income statement, it's a SQL query, but instead of summing over a date range, you sum balances AS OF a single date. The classic fintech-engineer mistake: treating the balance sheet as 'the sum of all journal entries since the beginning of time.' That works mathematically but is computationally absurd at scale. Real systems use SNAPSHOTS at period close (lesson 41) and reconstruct point-in-time balances as 'snapshot + deltas since.' This lesson posts a couple of representative entries that contribute to each section of the balance sheet.
Where the income statement is a flow over a window, the balance sheet is a photograph at one instant: what you own, what you owe, and what is left over for the owners. It is the same accounting equation that drove your very first journal entry, just summed across every account: assets equal liabilities plus equity. Every entry in this lesson keeps that equation true, which is why you can watch it hold after the capital injection (50 equals 0 plus 50), after the deposit (80 equals 30 plus 50), and after the loans and debt (90 equals 40 plus 50).
The user-deposit entry is the one worth staring at. The fintech now controls 80 million of cash, but only 50 million of that is the shareholders' equity; the other 30 million is a liability owed back to users. Controlling money is not the same as owning it, and the balance sheet is the report that keeps those two ideas from blurring together. The deposit grows an asset and a liability in lockstep, so equity does not move at all.
Computing balances as of a date is trivial in principle (sum every line up to that timestamp) and ruinous in practice once you have billions of lines. The fix is period-close snapshots: store the balance at each close, then answer any point-in-time query as the latest snapshot before the date plus the deltas since. Categorising the chart of accounts cleanly (assets 1xxx, liabilities 2xxx, equity 3xxx) is what lets the report group itself in one parameterised query.
Worked example, step by step
Opening capital injection: ₦50M shareholder equity → bank
Day 0. Shareholders fund the business with ₦50M. The cash hits the bank; equity reflects the shareholders' claim.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (Asset) (1200) | ₦50,000,000.00 | |
| Shareholders' Equity (3000) | ₦50,000,000.00 |
Bank Account (asset) UP ₦50M (debit). Shareholders' Equity UP ₦50M (credit). The first equation A = L + E starts holding: 50 = 0 + 50.
User deposits ₦30M into wallets (creates liability)
Customers fund their wallets, growing your user-deposits liability. Cash side: bank grows. Liability side: user wallet grows. No equity change.
| Account | Debit | Credit |
|---|---|---|
| Bank Account (Asset) (1200) | ₦30,000,000.00 | |
| User Wallet Liability (2000) | ₦30,000,000.00 |
Bank Account UP ₦30M (debit). User Wallet Liability UP ₦30M (credit). Equation: A 80 = L 30 + E 50. The fintech now CONTROLS ₦80M but only ₦50M is shareholders' equity; ₦30M is owed to users.
Disburse ₦20M loans + take ₦10M long-term debt to fund treasury
Active deployment: ₦20M out the door as loans (asset reclassification), ₦10M long-term debt raised (cash in, new liability).
| Account | Debit | Credit |
|---|---|---|
| Loan Receivable (Asset) (1500) | ₦20,000,000.00 | |
| Bank Account (Asset) (1200) | ₦10,000,000.00 | |
| Long-term Debt (Liability) (2500) | ₦10,000,000.00 | |
| Bank Account (Asset) (1200) | ₦20,000,000.00 |
Loan Receivable UP ₦20M (debit, asset). Bank Account DOWN ₦20M (credit). Bank Account UP ₦10M (debit). Long-term Debt UP ₦10M (credit, liability). Net: Bank goes from ₦80M to ₦70M, Loans appear at ₦20M, Long-term Debt appears at ₦10M. Equation: A 90 = L 40 + E 50. ✓
Takeaway
The balance sheet is `A = L + E` at a point in time, derived from your journal by summing per-account balances as of a date. The DISCIPLINE that makes it fast at scale: period-close snapshots (lesson 41) so 'balance as of X' is `(latest snapshot ≤ X).balance + (deltas since that snapshot up to X)`. Categorise your CoA cleanly: Asset codes 1xxx, Liability 2xxx, Equity 3xxx (this is the standard from large-corporate accounting). Then the balance sheet is one parameterised SQL query that runs in milliseconds even on billions of entries.
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.