The burden of proof is ours, not yours
No standard-setter has yet blessed AI-generated accounting entries. So scepticism is the correct default — if a system can't produce evidence, your only honest position is to treat everything it posted as unsupported. This page exists so you don't have to.
Existing systems cannot tell you which entries a human looked at
A concrete example: Xero records the user on every entry written through its API as System Generated. An entry a finance lead reviewed line by line and an entry posted unattended at three in the morning look completely identical.
That isn't one vendor's flaw. That generation of accounting software was never designed to record who exercised what judgment, because the operator was always a person. Once a machine becomes the primary operator, the layer is missing — and it cannot be added afterwards, because what it needs to record happens before the data reaches the system.
So Scalebook is not built on top of anything. The ledger is ours, and the evidence row is written in the same transaction as the journal. That is the only basis on which we would ask you to accept a machine-posted entry.
Four rules enforced by the database, not by code or a handbook
Worth reading first, because it determines whether the evidence below is worth anything: if the books themselves can be quietly altered, no amount of evidence matters.
- Journals must balance. Every journal, every currency, checked at commit time by a deferred constraint; unbalanced means the whole journal is rejected.
- Append-only. Update and delete rights on the journal tables are revoked — the application itself cannot alter a posted entry. Corrections are reversals plus re-postings, both on the books.
- Locked periods reject writes. A before-insert trigger. Once a month is closed, no tool and no code path can post into it.
- The evidence chain cannot break. Each evidence row's hash includes the previous row's hash; altering any record breaks the chain, with no separate logging system needed to detect it.
- Segregation of duties. Whoever submits cannot approve; whoever approves cannot change policy thresholds. Enforced in code, not in a handbook.
Five things, per transaction, immutable
Inputs at transaction grain
A pointer to the specific file — an image or a PDF, with its content hash — not a summary of a batch. You can click from the trial balance back to the document itself.
Model and prompt version
Generative output is not reproducible, so "we used AI" is not evidence. We record which vendor, which model ID, which prompt version, which region, and how long it took.
Output, confidence and basis
Per-field confidence — not one overall score — plus the basis for the coding, e.g. "47 prior entries for this supplier, all consistent".
Reviewer, timestamp, changes
Who approved, when, what they were shown, and which fields they changed. A rubber-stamp approval shows as "no changes" rather than being hidden.
Immutable version history
Each decision record's hash includes the previous record's hash. Retroactive edits break the chain — no separate logging system needed to detect them.
The AI-posted entry list
At year end you can pull every unattended entry for the period, with its confidence, the gate conditions it satisfied, and the sampling record. That list is your basis for deciding whether to accept the workflow at all.
Automated does not mean unsupervised
- A two-condition gate. To post unattended an entry must satisfy model confidence and a set of checks that don't depend on the model at all — amount limit, supplier history depth, duplicate detection, period lock, policy checks. Any single failure routes it to a person.
- Tiered sampling. Every entry is reviewed in month one, 25% in months two and three, and 10% indefinitely after that, with every review written into the evidence log. Not a one-off acceptance test — a continuing control.
- Thresholds loosen only on evidence, and every change is logged. Loosening a threshold reduces human review; the system records who changed it, when, and on what basis.
- An aggregate control. The system continuously computes auto-posted value × sampled error rate = projected undetected error and compares it against the company's performance materiality; above a quarter of it, the gate tightens automatically and warns.
About materiality
The auto-post ceiling is not a number we invented — it is derived from the company's materiality. But materiality is your judgment, not ours. It is a setting, expected to be confirmed by the auditor at the start of the engagement; our default is only a starting point.
What we do not do
Scalebook does not audit, does not express an opinion, and does not assess materiality for you. It also does not claim its output is accurate — it claims that every output carries enough information for you to judge its reliability yourself. That distinction matters to us.
A complete set of books, not a pile of exports
Trial balance, general ledger, P&L, balance sheet, cash flow statement, AR and AP ageing, and a draft set of financial statements prepared under the Hong Kong SME-FRS. Every figure clicks through to its journal; every journal clicks through to its document.
A draft is a draft. The opinion and the signature remain yours.
What would you need
to accept a machine-posted entry?
The five items above are ours. We've read the discussion and looked at what others do, but no practising auditor has reviewed this and told us whether it is sufficient. That is the single biggest unknown in this product, and it matters more than any technical question.
We're looking for a few auditors practising in Hong Kong to look at the evidence structure and tell us directly: what's missing, what's insufficient, what's unnecessary. This is cheap to fix now and expensive to fix in a year.
Nothing to sign, and this isn't a sales conversation. If your conclusion is "I wouldn't accept this format", that is the most valuable sentence we could hear today.
We reply personally. No newsletter, no drip sequence — your address is used to talk to you about this and nothing else.