What Human-in-the-Loop Actually Means in Bookkeeping

"Human-in-the-loop" has become one of the most abused phrases in AI software. In too many products it means only that a human could look at what the AI did, if they happened to open the right screen before the consequences arrived. That is not a control. It is a disclaimer.

This article sets out what the phrase means in our platform, precisely enough that you could audit us against it.

Three stages, three different responsibilities

Our workflow separates bookkeeping into three stages with deliberately different owners: AI drafts. AgentLedger validates. People approve.

Each stage does one job, and no stage is allowed to do the next stage's job.

1. The AI drafts

When a receipt, invoice, or bank line arrives, the AI reads it and proposes a double-entry transaction: date, counterparty, amounts, and the accounts it believes should be debited and credited. Every draft carries a confidence score — the model's own estimate of how sure it is about what it produced.

Drafting is what current AI is genuinely good at. Extracting a total from a supplier invoice, recognising a familiar counterparty, proposing the account a recurring cost usually lands in — these are pattern tasks, and models handle the common cases well. They are less reliable with ambiguous categorisation, unusual document layouts, and anything that requires knowing your business rather than reading your paperwork. The design assumes both halves of that sentence are true.

2. AgentLedger validates

Before a draft ever reaches a person, it must pass AgentLedger, our plain-text double-entry ledger kernel. Validation here is mechanical, not judgemental: do the debits and credits balance exactly, do the referenced accounts exist in the chart of accounts, is the date sane, is the entry well-formed? A draft that fails is rejected with a reason — never quietly repaired.

This stage exists so that human attention is never spent on machine-checkable defects. Reviewers should be thinking about whether an entry is right, not whether it is arithmetic.

3. A person approves

Every validated draft then meets a human decision. The reviewer has three verbs:

• Approve — the entry is correct and posts to the ledger.
• Correct — the entry is amended (perhaps the account, perhaps a split) and the edit is recorded alongside the original draft.
• Query — something is genuinely unclear, so the entry is held and a question goes to whoever can answer it, usually you.

Whichever verb is used, the decision, the person, and the timestamp are written into the audit trail. When someone later asks why an entry exists, the answer is a named human being and a recorded reason, not "the model output it".

Why "review by exception" needs explicit policy

At some point every client asks a reasonable question: does a person really need to look at the forty-third identical monthly software subscription?

The honest answer is: not necessarily — but the decision to stop looking must be made explicitly, in advance, in writing. "Review by exception" without a written policy degrades, in practice, into "review by nobody". The exceptions get defined by whatever the reviewer felt like skipping that week, and six months later no one can say which entries were actually examined.

Our version is a per-account automation policy, agreed with you. Each account can run in one of three modes: fully manual, accept-with-edit, or automatic within limits. Automatic posting is gated on two independent thresholds — the draft's confidence score and the transaction's materiality — and both must clear. A high-confidence draft for an unusually large amount still queues. A low-confidence draft for a trivial amount still queues, because doubt is doubt.

Three properties keep this honest:

1. The default is manual. Automation is opted into per account, deliberately, never assumed.
2. Policies are recorded and versioned. If an entry posted automatically, the trail shows exactly which policy, thresholds, and score permitted it at that moment.
3. Auto-posted entries remain visible. They appear in the ledger and in review views like any other entry, and they can be reopened, corrected, or reversed by a person at any time.

The failure mode we design against

There is a known weakness in human-review systems: rubber-stamping. Put a hundred mostly-correct drafts in front of a tired reviewer and approval becomes a reflex. Adding a human to the loop does not automatically add judgement to the loop.

We take this seriously rather than pretending it away. Review queues are ordered doubtful-first, so the reviewer's freshest attention lands on the drafts the model itself was least sure about. Corrections are tracked, which shows where the AI is systematically weak and keeps the review policy grounded in evidence rather than optimism. And duplicates are never silently discarded — suspected duplicates are held for a human decision, because a false positive that deletes a real transaction is worse than a question.

What this does not claim

None of this makes the bookkeeping infallible, and we will not tell you otherwise. Humans miss things; models are confidently wrong in ways humans do not expect; controls reduce error rates, they do not abolish them. What the structure guarantees is narrower and more useful: every entry in your ledger is mechanically valid, traceable to its source evidence, and owned by an identifiable person who decided it should be there under a policy you agreed to.

That is what human-in-the-loop means here. If a vendor cannot describe their loop at this level of detail, it is worth asking whether the human in it is a control or a caption.

Check eligibility / Ask for Details