What happens after a document arrives
Extracting an invoice is a commodity in 2026 — a few US cents a document. So the product isn't in reading it. It's in the three things that come after: how it gets coded, when the system should stop, and how any of it is proven to an auditor.
Five stages
Intake
Each company gets its own forwarding address — suppliers send directly, colleagues forward. Phone capture is a web page, not an app to install. Platforms (Stripe, Shopify, WooCommerce) arrive by webhook. Every file is SHA-256 hashed on arrival, so the same document is never processed twice.
Extraction
A multimodal model returns a strict JSON schema with a confidence score on every field. That matters: an unreadable invoice number and a crystal-clear total are two different situations, and a reviewer needs to see the difference. High-value or low-confidence documents run through a second model — disagreement between two vendors is the strongest signal there is.
Resolution
Suppliers are matched fuzzily on name, tax ID and bank account. Duplicate detection is a weighted rule, not a single field: same supplier, amount within 0.5%, date within seven days, invoice-number similarity — all four together. A new supplier always goes to a human. We don't guess.
Coding
Not a general model trained on everyone's data. We embed "supplier + line description" and retrieve the nearest past entries from this company's own history, then propose the account, tax treatment and cost centre it used before. Usable after roughly fifteen documents per supplier — and explainable, which beats any confidence score.
Post, or hand over
Clear the gate and it writes to Xero with an idempotency key and the source document attached, after checking locally that the accounting period isn't locked. Fail the gate and it goes to the exception queue — stating why it is there.
Why the gate needs two independent conditions
A model's self-reported confidence is not calibrated probability. Using it alone to decide whether to post unattended puts an accounting consequence on an uncalibrated number. So the other half of the gate has to be deterministic, auditable, and completely independent of the model.
| The model half | The deterministic half |
|---|---|
| The lowest confidence across critical fields (supplier, total, currency, date) is above threshold | Amount is below this company's auto-post limit |
| Where cross-check fired, both models agree | The supplier has enough history (default: fifteen documents) |
| — | Not a new supplier; not a suspected duplicate |
| — | Period unlocked; policy checks (budget, cost centre, approver) pass |
Ninety days of reviewing everything
The auto-post limit is set to zero. The system still runs and still proposes, but a person confirms every entry — while it records what it would have done. Only after a measured error rate across hundreds of real documents does anything loosen.
A permanent 10% sample
Even once loosened, 10% of auto-posted entries are sampled and the review is written into the evidence log. If the sampled error rate passes the threshold, the gate tightens automatically. This is the only reason we are willing to post unattended at all.
Evidence is the actual deliverable
Xero records the user on every API write as literally System Generated. From inside Xero there is no way to tell an entry a finance lead reviewed carefully from one posted unattended at 3am. Half the reason Scalebook exists is to supply that difference.
- Inputs at transaction grain — pointing at that specific file, not a summary of a batch
- Model and prompt version — generative output isn't reproducible, so recording what was actually used matters far more than recording "we used AI"
- Output and confidence — with the basis for the decision ("47 prior entries, all consistent")
- Reviewer, timestamp, and what changed — a rubber-stamp approval is not evidence
- Immutable version history — edits appear as new records, never overwrites; each row's hash includes the previous one, so retroactive tampering is detectable
One rule with no exceptions
A posted entry has no edit button. If it's wrong you reverse it and post the correct one, and both stay on the books with a reason. Quietly editing a posted entry is precisely the action that destroys the whole evidence system.
Why phase one builds on Xero rather than starting with our own ledger
The destination is to replace it (see The layer first, the ledger after). But the entrance cannot be the ledger — three reasons.
Time
A correct general ledger, tax engine, FX revaluation and audit trail is two years of work that only reaches 2015 parity. Those two years belong first in the part nobody has done — the evidence layer.
Trust
Auditors already accept Xero. In phase one that trust is borrowable; built from scratch it takes many years to earn. We intend to earn it — but not with a slogan.
Coverage
Xero operates in Hong Kong, Singapore, Malaysia, Australia and New Zealand. Going regional, this layer doesn't get rebuilt.
A limit we won't hide
Xero's documentation states plainly that reconciling bank statement lines through the API is not supported and not planned. So our approach is to create the correctly coded bill before the bank line arrives, so Xero's own reconciliation screen offers it as an exact match — one click, in bulk. That click stays in Xero, and we don't pretend otherwise.
Want to see it run on your documents?
We're looking for our first design partners. Nothing to pay; what we ask for is real documents and honest feedback.
We reply personally. No newsletter, no drip sequence — your address is used to talk to you about this and nothing else.