Bookkeeping

Bookkeeping — the recording layer that makes the numbers trustworthy

You are the bookkeeper. Your job is ledger hygiene: record what already happened, classify it into the right account on the right side, and reconcile it to reality so nothing is invented and nothing is lost. You do not interpret the numbers, forecast them, or set prices — you make them true. Every downstream skill (../finance-ops/SKILL.md reading runway, ../financial-model/SKILL.md projecting it) is only as honest as the ledger you keep here.

The whole job is one loop: Record → Classify → Reconcile. Record the raw event from a source document, classify it to an account and a side, then prove the ledger matches the bank. If you ever skip the third step, the first two are just opinions.

Route out before you start

"Where does this post and does it balance" is bookkeeping; "what do these numbers mean for the business" is not. Route out when the ask is:

• Interpreting the numbers — runway, burn, P&L review, monthly finance cadence → ../finance-ops/SKILL.md.
• Creating or sending a customer invoice, chasing payment (AR) → ../invoicing/SKILL.md.
• Setting a price or margin on a product/service → ../pricing/SKILL.md.
• Projecting future revenue, runway, hiring plans, scenarios → ../financial-model/SKILL.md.
• Tracking cloud/infra/COGS spend granularly for ops decisions → ../cost-tracking/SKILL.md.
• Reading/writing the Stripe API, syncing payouts programmatically → ../stripe/SKILL.md.
• Building the spreadsheet mechanics — formulas, pivots — themselves → ../spreadsheet-ops/SKILL.md.

Rule 1 — every entry balances: debits = credits

Double-entry means each transaction touches at least two accounts, and total debits equal total credits — always. The check behind it is the accounting equation, which must hold after every posting:

Assets = Liabilities + Equity

Why: a single-sided entry can record a number that is internally impossible. If debits ≠ credits, you have not made a mistake of judgment — you have made a mistake of arithmetic, and the ledger is provably wrong. Never post until the two sides tie.

Rule 2 — normal balances tell you which side increases

Memorize this table; it answers "which side is a debit when I pay rent" without guessing. The account's type decides which side increases it.

So paying $500 rent: Rent Expense (an expense) goes up, so debit it; Cash (an asset) goes down, so credit it. Mnemonic: assets and expenses are "debit-natured," everything else is "credit-natured."

Rule 3 — the chart of accounts is small and stable

The chart of accounts (COA) organizes the ledger into five top categories: assets, liabilities, equity, revenue, expenses — the foundation of the whole double-entry system. Number them by range so the type is obvious from the code:

Start with ~20–30 accounts, not 200. A COA you can read on one screen is one you will actually use correctly; an over-split COA pushes every classification into a coin-flip and guarantees inconsistency.

Name accounts by what they are, not by a vendor or a feeling:

Bad:  "Stuff", "Misc", "Amazon", "John's expenses"
Good: "Office Supplies", "Software Subscriptions", "Owner Draws"

Add an account only when a real reporting question needs the split (e.g., you must report "Software" separately from "Rent"). Merge two accounts the moment you find yourself flipping a coin about which one a transaction belongs in. Full numbered example COA and contra accounts: references/chart-of-accounts.md.

Rule 4 — post from a worked entry, then check the balance

Write the journal entry, total each side, confirm they tie. Two worked examples:

Paid $500 office rent from the bank:

DR  5100 Rent Expense        500
    CR  1000 Cash                    500
Debits 500 = Credits 500  ✓   (expense up, asset down)

Customer pays $1,200 up front for work not yet delivered:

DR  1000 Cash               1200
    CR  2400 Unearned Revenue       1200
Debits 1200 = Credits 1200  ✓

Note the second one: the cash arrived but you have not earned it yet, so it is a liability (you owe the work), not revenue. Recording it as revenue is the single most common classification error — it inflates income and understates what you owe.

Rule 4.5 — the classification decision procedure (run this on every confusing line)

The easy lines classify themselves. This procedure is for the ones that don't — and it is where a careless ledger goes wrong. Run it in order and stop at the first rule that fires; the order matters because later rules assume the earlier tests already failed.

1. Is it cash moving between two accounts you own? (operating → savings, owner topping up the business, paying down the company credit card from operating cash.) Then it is a transfer, not income or expense — both legs net to zero across the books. The single most common bank-feed error is booking the incoming side of a transfer as Revenue. A transfer never touches a P&L account. Test: would the company's net worth change? If no, it's a transfer.

2. Did value flow in or out of the business, or just timing? Cash moving does not mean expense/revenue happened. Paying down a loan, paying a supplier invoice you already booked to AP, collecting an invoice you already booked to AR — these only move a balance-sheet account (liability or asset) against Cash. Booking them again as expense/revenue double-counts. Test: "did I already record the expense/revenue when this was incurred/earned?" If yes, this cash event only clears the receivable/payable.

3. Is this the principal or the cost? Split blended payments. A loan payment is interest (expense) + principal (liability reduction) — never all expense. An asset purchased on finance is the asset (capitalized) + interest over time. A payroll run is net wages + tax withheld (liability) + employer taxes (expense). Decompose before posting; one line on the bank, two-to-three lines in the journal.

4. Capitalize or expense? If the thing has useful life beyond this period and exceeds the business's capitalization threshold (set one, e.g. $2,500), it is an asset depreciated over time, not an expense booked now. Below the threshold or consumed this period → expense. Refund/credit: a refund of an expense credits the original expense account (it reverses the cost) — it is not Revenue.

5. Earned/incurred, or just paid/received? Under accrual: revenue posts when earned (delivery/performance), expense when incurred (obligation arises) — regardless of when cash moves. Cash received before earning → Unearned Revenue (liability). Expense incurred before paying → Accounts Payable / accrued liability. A 12-month prepaid (insurance, annual SaaS) is a Prepaid asset amortized monthly, not a lump expense in month one. (Cash basis collapses steps 5's timing distinctions — but steps 1–4 still apply.)

6. Is it actually a business transaction at all? Owner's personal spend run through the business is Owner Draws (equity), never an expense. A genuinely mixed charge (phone, car, home office) is split by business-use percentage; only the business portion is deductible.

If a line survives all six and you still can't place it: post it to a holding/suspense account and flag it — never guess into "Misc." A flagged suspense line gets resolved; a wrong guess in Misc never does. Full catalog of the transactions agents most often misclassify, each with the worked entry: references/tricky-transactions.md.