Why the AI never writes your ledger

There is a rule inside Bizzle that everything else is built around, and it is short enough to fit on a sticker: the AI proposes, deterministic code disposes.

Language models read your paperwork, work out what a document probably is, and suggest where it belongs. They do not post to your ledger. Not ever, not once, not for the easy ones. Every journal entry is written by ordinary double-entry code that balances to the penny, links to the event that caused it, and reverses properly if it turns out to be wrong.

This is not a hedge while we wait for the models to improve. It is a permanent architectural choice, and it is worth explaining why.

Models are good at reading and bad at counting

A language model is genuinely excellent at the job we give it. Hand it a crumpled photograph of a builders merchant receipt and it will pull out the supplier, the date, the total, the VAT and the line items, in a way no rules engine written by hand ever managed. That is a hard problem that was basically unsolved ten years ago.

But the thing that makes a model good at that — it produces the most plausible answer given everything it has seen — is exactly the thing you do not want anywhere near a set of accounts. Plausible is not the standard. Correct is the standard, and it has to be correct in a way somebody can check afterwards.

A model that is right 99% of the time sounds impressive until you run four hundred transactions a month through it. That is four wrong postings a month, arriving silently, in a system where nobody is looking because the whole promise was that they would not have to.

What "deterministic code disposes" means in practice

The split runs through every automated action in the product.

The model does this: reads the document, extracts the fields, proposes a match to a bank transaction, assigns a confidence, drafts the reply.

Code does this: decides whether the confidence is high enough, checks the match against rules learned from your previous answers, writes the double-entry, and logs the whole chain.

The code is boring. It is the kind of thing accountants have been writing since before any of this, and it is boring on purpose — it is auditable, it is testable, and it does the same thing every single time you run it.

When Bizzle is not sure, it does not guess. It asks you one question with two buttons, and remembers the answer so it never has to ask again.

The audit trail is the product

Every automated action carries its reasoning with it. A single transaction looks like this from the inside:

06:29:41  bank.txn.received   £62.40 · The Grove Café
06:29:44  match.proposed      receipt #R-1182 · confidence 0.87
06:31:02  user.confirmed      owner tapped yes
06:31:02  ledger.posted       entry #2,481 · balanced
06:31:02  crm.linked          contact updated

You can click any entry in the books and walk backwards: journal, bank transaction, source document, the confirmation that filed it. Nothing is ever silently deleted — a correction creates a proper reversing entry, the way it would if a human had made the mistake.

An assistant that touches your money has to be auditable by the same person who audits the money.

Why your accountant cares more than you do

We built it this way for accountants as much as for owners, and their objection is the sharp one.

An accountant looking at AI bookkeeping software is not worried that it will be slightly inaccurate. They are worried that it will be confidently wrong in a way that is invisible until something breaks — a year of postings that look fine, sum correctly, and describe things that did not happen. Unpicking that is worse than doing the books from scratch, and they know it, because they have unpicked bad bookkeeping before.

"The model never writes to the ledger" is the only answer to that objection that actually holds. Every other answer is a promise about accuracy, and promises about accuracy are exactly what they have learned not to accept.

What this costs us

Being honest about the trade: this rule makes the product slower to build and occasionally more annoying to use.

There are cases where a model would get it right and our rules make us ask you anyway. There are features that would ship faster if we let the model just decide. We take that cost deliberately, because the alternative is a product that is delightful for eight months and then loses somebody their VAT return.

You can read the rest of how the system fits together on the product page, or the specific commitments we hold ourselves to on trust and security. Both are written to be checked rather than admired.