Why your bookkeeping is behind, and what actually fixes it
Bookkeeping falls behind because the backlog is made of unanswered questions, not unentered data — which is why more discipline never fixes it and making the questions cheaper to answer does.
Nobody is eleven weeks behind on their bookkeeping because typing is slow. Typing a bank statement into a ledger is a boring hour. Eleven weeks of backlog is not eleven boring hours; it is roughly four hundred small decisions, and each one is a tiny amount of thinking you cannot do while tired.
That distinction is the whole thing. Data entry can be forced through with discipline. A queue of judgement calls cannot, because the cost of each item is not the typing — it is the context switch into “what was that $218 in March”.
The three items that actually stall the pile
Watch anyone catch up and the same three things stop them, over and over.
The merchant you do not recognise. SQ * and a string of characters. It is
a Square payment to something, three months ago, and answering it means finding
an email. So it gets skipped, and once one row is skipped the run is broken.
The card that is half personal. One account, two lives. Every row now needs a second decision — business or not — and that decision has consequences you half-remember from something your accountant said.
The thing you are not sure is deductible. This one is genuinely not a bookkeeping question, it is a tax question, and answering it needs a person who is not available at 11pm on a Sunday.
None of these are hard. All of them are blocking, and a queue with blockers in it does not drain — it stops at the first one.
The fix is not doing them faster
The fix is that an unanswered question should stop being a blocker.
In a plain-text ledger, an entry can be recorded and still open. A ! flag
means the money is accounted for and the classification is not settled:
2026-03-14 ! "SQ *UNKNOWN"
Expenses:Unknown 218.60 USD
Assets:Bank:Checking -218.60 USD
The $218 is now in the books. Your bank balance reconciles. The run continues past it. What is left is a question sitting somewhere you can find it later, rather than a gap that invalidates the month.
Contrast the two alternatives people actually use. Skipping the row leaves books that do not match the bank, which means the whole month is untrustworthy until you go back. Guessing produces books that balance perfectly and describe a business that does not exist — and that error is worse, because nothing about it looks wrong.
Batch the questions, don’t chase them
Once the pending entries are entries rather than gaps, they are queryable. Every open question in six months of books, in one list:
SELECT date, narration, account, position
WHERE flag = '!'
ORDER BY date
Now it is thirty minutes of one kind of work, with all the context in one place, instead of four hundred interruptions. That is a completely different task, and it is one you will actually do.
What catching up on six months looks like
| Step | Time | What it costs you |
|---|---|---|
| Export six statements from your bank | 10 min | Clicking |
| Hand them over, entries get written | — | Nothing; you are not in this step |
| Answer the flagged questions | 20–40 min | Actual thinking, once, batched |
| Assert the closing balance per month | 5 min | Proof it is right |
The middle step is the one that changed. Everything else was always survivable.
- The agent reads a statement — CSV, OFX, QFX, a PDF — maps the rows to accounts and writes balanced entries. Shipped
- Anything it cannot classify confidently comes back flagged
!and pending rather than guessed. Shipped - Every write goes through validation first, so a catch-up run cannot leave the ledger in a state that does not add up. Shipped
- Every change is a commit, so a catch-up you are unsure about is reviewable as a diff and reversible on the tip. Shipped
The habit that keeps it from happening again
Once a month, not once a year. Not because monthly is virtuous, but because the “what was that charge” question is answerable in three weeks and genuinely is not in nine months. The decay curve on your own memory is the real deadline, and it is much shorter than the tax one.
The honest edge
What this does not do, including the parts that are specifically relevant to being behind.
- Nothing arrives on its own. There are no bank feeds and none are planned. Not built You still export the file. If the reason you fell behind is that you never log into your bank, this changes less than you want it to.
- Re-importing overlapping exports can double-book today. The deterministic importer with a stable per-row key is being built. Building Catching up often means overlapping “last 90 days” exports, so this one bites exactly this use case — check the balance assertions after a big run.
- Receipts are not archived. The receipt tool is being built. Building The extracted transaction is stored; the photograph is not kept somewhere you can go back to it.
- Nobody answers the tax question for you. Not built No payroll, no filing, no advice on whether that dinner was deductible. The ledger will record whichever answer you give it and has no opinion about which is right.