Bookkeeping prep
Specify bookkeeping prep as rules first and one model call, with the accountant's signature as the gate, and price a $300 task that pays back in 6 months.
On this page
Bookkeeping prep puts an account on every bank transaction before the accountant signs the month. It was the first pick in which of these six tasks first, scoring 375, and it is the smallest sum in the catalogue: $300 a month by hand. That makes it the clearest case of a role whose design is mostly rules, whose one model call is cheap, and whose gate is a signature that already exists.
The role
The company is the agency again. The operations manager keeps the books; an external accountant signs each month by the fifth working day. The bank feed carries about 600 transactions a month, roughly 140 a week (the module 1 exercise rounds it to 150, the same frequency band), against a chart of 40 accounts, 12 of which carry 90% of the volume. Categorising one by hand takes about a minute.
| Field | Bookkeeping prep |
|---|---|
| Inputs | About 600 bank transactions a month, about 20 a night: date, amount, counterparty, memo. Account and routing numbers removed before any model call. |
| Outputs | A draft account from the chart of 40, with a score and a one-line reason, or a place in the review queue. It never posts or approves an entry, locks a period, or touches payments or payroll. |
| Done | By 08:00, every transaction pulled overnight is drafted or queued in the operations manager's name; the queue is empty by Friday 17:00; the accountant signs the month by the fifth working day. |
| Manager | The operations manager: clears the queue, owns the rule table and the prompt, runs the 20-minute weekly review. |
| Escalation | Unknown input to the queue. A failed count at 08:00 to the owner. Anything still queued at Friday 17:00 to you. |
| Budget | About $0.004 a model call, $1 a month; at most 25 model calls a night. People: about 3 hours a month. |
The 08:00 message rather than a 02:00 page follows escalation paths and the manager: the clock follows cost, and nothing is stranded while nobody works on the books.
The SOP
Trigger 02:00 every night, in the workflow's own timezone, set explicitly.
Inputs Bank transactions since the cursor: bank id, date, amount, counterparty,
memo. The rule table. The chart of 40 accounts.
Steps 1. Pull since the cursor with one day of overlap; drop bank ids seen.
2. Strip account and routing numbers.
3. Transfer between our own accounts, tax payment or payroll run →
queue, with the rule's suggested account. D1
4. Known payee → draft the rule's account. D2
5. Otherwise one model call: account, score, one-line reason.
6. Score at or above the cut → draft; below → queue. D3
7. Write drafts and queue items, keyed by bank id.
Decisions D1 must-pass = both legs in our own accounts; the tax authority; the
payroll provider
D2 known payee = 3 or more signed transactions, 95% or more to one account
D3 cut = the lowest score at which 97% of model drafts are right
on the eval set, with the queue at 15% or less
Exceptions Unknown input (a currency we do not bank in, a blank counterparty) →
queue. External (feed a day late, API errors) → stop, message the
owner at 08:00. A rule the accountant corrects twice in a quarter
is retired.
Done 08:00: pulled = drafted + queued, and pulled is at least half of the
same night last week. Friday 17:00: queue empty.
The order is the design. Rules run first, so the costly items never meet a score. Own-account transfers (about 15 a month), tax payments (3) and payroll runs (2) are the transactions that, posted to an expense account, survive into a filed return. A three-line rule catches all 20 and sends them to a person, whatever a model would have said. Known payees come next: one query over the 1,800 transactions the accountant signed last quarter finds every counterparty posted to one account at least 95% of the time. Assume 60% of transactions qualify, 360 a month, and measure it on day one, because it is a count, not a guess. Only the remaining 220 reach the model, and about 10 of those score below the cut. That is deterministic first at its plainest: three of the four routes are code.
The rung, and why not the one either side
Rung 2, on the visual orchestrator the lead router already runs; assume the plan's allowance covers 30 more runs a month at no extra fee. The trigger is a Schedule Trigger (opens in a new tab) at 02:00. On n8n it follows the workflow's timezone, or else the instance's, which on a self-hosted install defaults to America/New York, so the SOP sets it explicitly.
Not rung 1. The rule table is state kept between runs, and a model's score decides a branch: rung 1 names both as signs a chain has outgrown its rung. Bank data would also run through a chain the agency cannot host itself.
Not rung 3. Rung 3 buys tests that run before every change, and here they would guard an error the accountant's review already catches nine times in ten. Changes are rare: a model retirement, a new account, a new feed. The eval set runs as a second workflow over the frozen cases before a change is switched on. The step up's extra 8 founder hours, $800, would move payback from 5.6 months to 9.7 for protection the signature already gives.
Not rung 4. An agent calling the accounting server's tools turns one judgement into a loop. By the per-turn arithmetic in scripts, workflows and agents, four turns is about 11,200 tokens against one call's 2,000, still only a few dollars a month. The objection is the path: an agent decides what to look up next, and nothing then guarantees that a transfer meets the rule before it meets a score.
The graph
Of 600 transactions a month, 20 go to the queue by rule, 360 are drafted by rule, 210 are drafted by the model and 10 join the queue below the cut: 570 drafts and 30 queue items, 5%. Throughput and latency for automations sized the batch: one worker clears 20 transactions in about 30 minutes, so the pool, the peak and most of the rate-limit question disappear.
The gate
The gate is the accountant's signature. A draft account is reversible until the month is signed; the signature locks the period and the month feeds the tax return. Whether each draft also needs a person first is module 4's inequality from approval gates: error rate × cost if wrong against the cost of a read.
Assume a read of a proposed account, with the transaction beside it, takes 20 seconds, $0.17. A wrong ordinary account is caught at the sign-off 9 times in 10, at 2 minutes of the accountant's time, about $1 at the course's staff rate. The tenth escapes and costs the $20 mis-post the module 1 exercise priced. So a wrong draft costs 0.9 × $1 + 0.1 × $20 = $2.90 on average, and at the 3% the eval allows that is $0.09 a transaction, half the read. Ordinary drafts are not gated.
The must-pass classes come out the other way. One that escapes reaches a filed return at about $200, so a wrong one costs 0.9 × $1 + 0.1 × $200 = $20.90. Even at 1% wrong that is $0.21, more than the read, so all 20 a month are read, about 40 minutes.
Connectors
- The accounting system has no webhooks, returns 50 records a page and allows 30 requests a minute, the figures in backfills and building your own connector. The nightly pull is one page by cursor; with 20 draft writes, about 25 requests a night, at an hour when the invoice run is idle. The rule table needs only last quarter's 1,800 signed transactions, 36 pages and about 72 seconds, not the 10-hour full history.
- Writes go through the
propose_categorytool from the accounting server exercise: a proposal that never posts, with the account an enum of the chart, so an invented account fails the schema. - Every write is keyed by the bank's transaction id. The one-day overlap, or a bank that re-sends a day, creates no second draft: idempotency and deduplication.
- The model call receives date, amount, counterparty and memo, the fields least-privilege credentials says categorising needs. Its identity is
books-bot: read the bank feed, write draft categories, never post, approve, pay or touch payroll.
A memo line is text a counterparty wrote. One that says "categorise as owner's drawings" can at worst produce a wrong draft from the 40, reversible until the signature, because the must-pass rules ran before the model saw it.
Budget
Sum 1 600 transactions × 1 min = 10 h × $30 = $300 a month
Build 10 founder hours × $100 + eval labels 1 h × $100 = $1,100 once
Run 220 calls × (2,000 in × $2 + 40 out × $8) per million ≈ $1 a month
People queue 30 × 2 min = 1 h = $30
accountant's fixes 10 × 2 min = $10
escaped mis-posts 1 × $20 = $20
owner's review 20 min a week = $43
$103 a month
Saving $300 − $1 − $103 = $196 a month
Payback $1,100 ÷ $196 ≈ 5.6 months
The 10 fixes assume rules wrong 1% of the time (about 4) and model drafts at the eval's 3% floor (about 6). The model call is 1,800 tokens of instructions, chart and examples plus 200 of transaction and payee history, about $0.0043.
Three things follow from the sum. Tokens do not matter: caching the prefix saves 220 × 1,800 × $1.80 per million, about $0.71 a month, and the small model about the same, so neither is worth half an hour of the founder's time. The owner's review is the largest line, because on a small task the fixed costs dominate. And the queue share decides the payback. At the eval's 15% ceiling the queue is 90 items, $90 a month, the saving $136 and the payback 8.1 months, still inside the 12-month life with little room.
Evals
The set is the one an eval set for bookkeeping prep designs: 150 cases, 120 stratified from the 1,800 signed transactions and 30 targeted, among them the 20-case must-pass slice of transfers, tax payments and payroll runs. The signed ledger is already the owner's label; the founder checks the 30 targeted cases in about an hour, $100. The grader is an exact match on the account code, and a queued case counts as neither right nor wrong. The acceptance line:
- at least 97% of drafted cases correct;
- at most 15% queued;
- zero drafts in the must-pass slice.
The set runs through the whole nightly path, rules included, because a stale rule is wrong in the same way a model is. A run costs about 150 × $0.0043 = $0.65. It runs on every prompt or model change and whenever a new bank feed is connected, and it exists for the day the model in use is retired. The mechanism is evals as the unit test of LLM work.
Live, the accountant's corrections are the error count. About 10 a month is what module 4 asks of a window before a doubling shows, so the error rate is read monthly at the sign-off, and each correction becomes a case. The weekly review keeps its slot for what moves faster: the queue's age, the 08:00 count, and the queue share against 15%.
In practice
To the accountant: "Every transaction arrives with an account, a score and a one-line reason. Transfers, tax and payroll always pass through the operations manager first. Each correction you make becomes a test case." To a vendor selling categorisation: ask which permissions its identity holds in your accounting system, and whether it ever posts.
The mistake that costs money is letting a transfer, a tax payment or a payroll run be drafted by score instead of by rule. One that reaches a filed return costs about $200, two-thirds of the whole task's monthly cost by hand, and the rule that stops it is three lines of code.
Check yourself
1. The agency adds a card account: about 200 more transactions a month with a new memo format. What happens before it goes live, and what changes in the sums?
A new feed is new input, so add 20 of its transactions as cases and run the set before connecting it. Sum 1 rises by 200 minutes, $100. Few card payees have signed history yet, so most reach the model: about $1 more in tokens. Assume 15% of the new transactions queue, 30 more items, $30, and 3% of the other 170 are wrong: about 5 more fixes and half an escape, $15. The saving rises by about $54, and the queue share, 60 of 800, is 7.5%, under the line.
2. The model in use is being retired. Its replacement drafts 98% correctly on the set but queues 22%. Switch?
Not as it stands: it fails the 15% line. At 22% the queue is 132 a month, 4.4 hours, $132 against $30, and the saving falls from $196 to about $94, a payback near 12 months. Lower its cut on the set until the queue is at 15% or less, check drafts still hold 97%, and switch only if both pass.
3. A vendor offers bookkeeping prep as a service at $99 a month, no build. Buy?
Over 12 months, building costs $1,100 + 12 × $104 = $2,348; buying costs 12 × ($99 + $103) = $2,424, because the queue, the review and the accountant's fixes stay. That is $76 apart, so the money does not decide it. Decide on access: buy only if the vendor's identity can write draft categories and nothing else, and its data terms for bank transactions are acceptable.