bookkeeping git:20260602.484d945A

Immutable. This exact content never changes and is served at /api/v1/blob/24b4f87cf3f1e928.

---
name: bookkeeping
description: "Use when a small business needs clean, audit-ready books — standing up a chart of accounts, recording a transaction and unsure which account or which side (debit vs credit), a bank feed full of uncategorized lines, a month-end ledger that won't reconcile to the bank, or choosing cash vs accrual. Triggers: 'set up a chart of accounts', 'where does this transaction post', 'which side is a debit when I pay rent', 'my books don't tie out to the bank', '300 transactions sitting uncategorized', 'cash or accrual accounting', 'how long do I keep receipts', 'categoriza los movimientos del banco', 'mi contabilidad está hecha un desastre', 'cuadra el libro con el extracto', 'comptabilitat feta un desastre'. The loop is record → classify → reconcile so the numbers downstream skills read are trustworthy. NOT analyzing runway/burn/P&L or the monthly finance cadence (that is finance-ops), NOT issuing a customer invoice (that is invoicing), NOT setting a price (that is pricing), NOT future projections (that is financial-model)."
tags: [bookkeeping, double-entry, chart-of-accounts, reconciliation, ledger, accounting, categorization]
recommends: [finance-ops, invoicing, pricing, financial-model, cost-tracking, stripe, spreadsheet-ops]
origin: risco
---

# 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

This skill answers "where does this transaction go and does the ledger balance." When the ask is something else, stop and route:

- 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 of thumb: "where does this post and does it balance" is bookkeeping; "what do these numbers mean for the business" is finance-ops.

## 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:

```text
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.

| Account type | Normal balance | Increases with | Decreases with |
| --- | --- | --- | --- |
| Asset (cash, AR, equipment) | Debit | Debit | Credit |
| Expense (rent, software, wages) | Debit | Debit | Credit |
| Liability (AP, loans, unearned revenue) | Credit | Credit | Debit |
| Equity (owner capital, retained earnings) | Credit | Credit | Debit |
| Revenue (sales, service income) | Credit | Credit | Debit |

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:

| Range | Category | Examples |
| --- | --- | --- |
| 1000–1999 | Assets | Cash, Accounts Receivable, Equipment |
| 2000–2999 | Liabilities | Accounts Payable, Sales Tax Payable, Loan Payable |
| 3000–3999 | Equity | Owner Capital, Owner Draws, Retained Earnings |
| 4000–4999 | Revenue | Service Revenue, Product Sales |
| 5000–5999 | Expenses | Rent, Software, Payroll, Bank Fees |

**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:

```text
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:**

```text
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:**

```text
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 5 — pick cash or accrual once, deliberately

| Method | Income recorded | Expense recorded | Use when |
| --- | --- | --- | --- |
| Cash | when received | when paid | simple, no inventory, under the gross-receipts ceiling |
| Accrual | when earned | when incurred | inventory, C-corp, or above the ceiling — and gives a truer P&L |

US trigger: the Section 448(c) gross-receipts test caps cash-method eligibility at **~$31M average for tax year 2025 (rising to $32M for 2026, Rev. Proc. 2025-32)**, averaged over the prior three years. Above it — or with inventory or C-corp status — accrual is generally **required**. Why pick once and commit: switching method later means a Form 3115 and a Section 481(a) adjustment, not a checkbox. Spain note (autónomo) and full retention rules: `references/reconciliation-playbook.md`.

## Rule 6 — Uncategorized must end at zero

A bank feed is raw input, not a record. Drive uncategorized to **0 every reconciliation period** — an "Uncategorized" balance is a pile of unrecorded business facts pretending to be done.

1. Set **auto-rules** for recurring payees (the same SaaS charge → Software Subscriptions every time). Rules cut the manual load on the 80% that repeats.
2. **Review each match** against type/date/amount before accepting — auto-match guesses on payee strings and gets transfers, refunds, and owner draws wrong.
3. **Batch-review** the long tail: sort by payee, classify in groups, leave nothing in Uncategorized.
4. Treat automation as an **assistant, never the authority** — verify against the invoice or statement. Reconcile at least monthly; weekly for high transaction volume.

## Rule 6.5 — month-end reconciliation, and what to do when it won't tie

Reconciliation proves the book balance equals the bank statement balance for the period. Checklist:

- [ ] Statement balance and book ending balance both pulled for the same cutoff date.
- [ ] Every bank line is matched to a book entry (and vice-versa).
- [ ] Uncategorized = 0.
- [ ] Difference = 0, or fully explained by listed timing items (uncleared checks/deposits).

**If book ≠ bank**, walk the diagnostic ladder — do not "plug" the difference:

1. **Timing** — a deposit or check not yet cleared the bank. Legitimate; list it as a reconciling item.
2. **Duplicate** — the same transaction entered twice (common after an import).
3. **Missing entry** — a bank line with no book counterpart (bank fee, auto-debit you never recorded).
4. **Transposition** — if the difference is evenly **divisible by 9** (e.g., $90, $540), suspect two digits swapped (54 entered as 45).

Posting a "plug" entry to force a match hides the error instead of finding it — and the error compounds next month. Full diagnostic ladder: `references/reconciliation-playbook.md`.

## Rule 7 — keep records as long as the law requires

US retention floor (IRS "How long should I keep records"):

| Keep | Records |
| --- | --- |
| 3 years | general default |
| 4 years | employment-tax records |
| 6 years | if income underreported by >25% |
| 7 years | bad-debt / worthless-security claims |
| Indefinitely | unfiled or fraudulent returns; asset basis records |

Spain (autónomo, estimación directa simplificada): the obligation is **libros registro** — libro de ingresos, libro de compras y gastos, libro de bienes de inversión — plus VAT registers (facturas expedidas / recibidas), each entry carrying fecha, nº factura, NIF, base imponible, tipo y cuota de IVA, total. Full PGC partida doble applies under estimación directa normal. Detail: `references/reconciliation-playbook.md`.

## Anti-patterns

| Anti-pattern | Why it breaks | Do instead |
| --- | --- | --- |
| One giant "Misc" expense account | Reports become meaningless; tax prep guesses | Real named accounts; split only by reporting need |
| Categorizing from memory, not source docs | Invents numbers an audit can't trace | Classify from the invoice/receipt/statement |
| Recording a customer prepayment as revenue | Inflates income, hides the liability you owe | DR Cash / CR Unearned Revenue until earned |
| Treating an owner draw as an expense | Understates profit; distorts equity | Owner Draws is an **equity** account, not expense |
| Booking a loan principal repayment as expense | Double-counts cost; only interest is expense | DR Loan Payable (liability down) / CR Cash |
| Never reconciling, or plugging the difference | Errors compound silently month over month | Reconcile monthly; walk the diagnostic ladder |
| Mixing personal and business in one account | Untraceable books, tax and liability exposure | Separate business account; owner draws/capital for transfers |
| Trusting bank-feed auto-match blindly | Miscategorizes transfers, refunds, draws | Review every match against type/date/amount |
| Over-splitting the COA into 200 accounts | Every classification becomes a coin flip | Start at ~20–30; merge when you hesitate |

## References

- `references/chart-of-accounts.md` — full numbered example COA across the five categories, contra accounts (accumulated depreciation, allowance for doubtful accounts), add-vs-merge rules, the over-splitting failure mode.
- `references/reconciliation-playbook.md` — step-by-step month-end reconciliation, the full won't-tie-out diagnostic ladder, and the jurisdiction detail (IRS retention table + Spain libros registro de IVA fields).