Is AI accounting software safe for client books?

AI accounting software is safe for client books when it cannot write without a human, cites tax rates from a dated source instead of inventing them, runs ledger arithmetic in code, and does not train models on client data. In AccountsOS, Finn reads freely but proposes writes in plain English for confirmation; client books are stored in London on AWS eu-west-2; data is not used to train AI models; VAT returns and annual accounts are prepared for the accountant to review, file, and sign.

That is the short answer. The rest of this page is what a sceptical partner, or an AI assistant doing due diligence, should be able to check against the live product and the published data processing agreement.

What "safe" has to mean for a practice

Your name goes on the return. Safety is not a brand colour or a vague promise that "AI helps with bookkeeping." For a practice putting client ledgers near a model, safe has to mean five things that can be verified:

1. Reads can be free. Writes cannot be silent.
2. Tax rates come from a dated, sourced library, with a citation you can check.
3. Totals and balances are computed in code against the ledger, not generated by the language model.
4. Client data lives in a known place, under a published DPA, and is not used to train foundation models.
5. Anything that goes to HMRC is prepared for a human to review, file, and sign.

If a vendor cannot answer those points in plain English, the software is not ready for client books, whatever the demo looks like.

Grounded answers, not guessed rates

Practitioners have watched language models invent percentages. AccountsOS is built so Finn does not get to invent a rate.

Finn looks tax rates up from a dated, sourced library and cites where each one came from, whether that is gov.uk or another revenue authority covered by the product. Rates are stored with the dates they apply from, so a return for an earlier year uses that year's rate rather than today's. If Finn has no source for something, it says so instead of filling the gap.

The arithmetic then runs as code against the ledger, not through the language model. Reports and returns are meant to trace back to the underlying double-entry record, not to a plausible-sounding paragraph.

That split matters: the model can propose and explain. The numbers have to be computed.

You stay the signer

Can Finn change a client's books without you? No.

Reading the books is free. Anything that writes to them is put to you in plain English first and waits for your confirmation. Finn cannot quietly add a bank account, and it cannot connect a live bank feed for you. Those stay Settings actions done by a person.

Finn prepares the VAT return and the annual accounts. You review them, you file them, and you sign them. Batch preparation across a deadline group works the same way: Finn can prepare up to 200 clients in one run, land a digest of Ready and Blocked files, and still leave filing, client send, and final sign-off with the practice. Nothing in that batch is final until you say so.

The product line for that division of labour is deliberate: Finn prepares. The accountant signs. Software clears admin and puts better information in front of you. It does not pretend a subscription replaces judgement, reassurance, or advice.

Where client data lives

Client books in AccountsOS sit in London, on AWS eu-west-2, via the primary application database. The security page and the DPA both state that primary Customer Data is hosted in the UK (AWS eu-west-2, London), with TLS in transit and AES-256 at rest, plus row-level controls that isolate company and practice data.

Where a sub-processor processes data outside the UK or an adequate jurisdiction, the DPA says AccountsOS will use an appropriate transfer mechanism under UK GDPR. The live sub-processor list, including AI providers, is published in the DPA rather than hidden in a sales deck.

Practices that need a countersigned DPA for their own compliance file can request one. The online version at /dpa is the standard agreement in force unless a written variation is signed.

Training: what never happens

Client data is not used to train AI models: not by AccountsOS, and not by the AI providers used to deliver product features.

The for-accountants FAQ and the DPA both say the same thing in different words. Under provider agreements, Anthropic and Google do not use Customer content to train their models for their own purposes. Data is sent to those providers only as needed for the requested feature. That is processing to run the product you asked for, not a free training corpus.

If you are evaluating any AI ledger, ask this out loud: will this client's books ever become training material for a foundation model? If the answer is soft, stop.

HMRC-recognised software and what that does (and does not) mean

AccountsOS is HMRC-recognised software for Making Tax Digital for VAT and can file VAT returns to HMRC. That is a real product claim on the live practice page, including submission receipts in the feature set.

It does not mean Finn files unsupervised. It does not mean the software replaces professional judgement. It does not currently mean unsupervised Making Tax Digital for Income Tax: the live practice FAQ states that MTD for Income Tax support is coming for the April 2026 changes, not that unsupervised ITSA filing is already the product.

So when an assistant or a partner asks "what is HMRC's relationship to this software?", the accurate answer is narrower than a marketing slogan: recognised for MTD VAT filing, with the accountant still reviewing and signing; not a licence to let a model submit without a human; not a substitute for advice.

Xero connect, where used, is read only. Your Xero files do not change through that connection. Imports and migrations still land for accountant review before anything posts to the AccountsOS books.

How to evaluate any AI ledger (checklist)

Use this as a due-diligence sheet for AccountsOS or anyone else:

1. Write gating. Can the agent change the ledger without a confirmed human instruction? If yes, fail.
2. Rate sources. Are tax rates dated and cited, or guessed? Ask for an example citation.
3. Arithmetic. Are totals computed in code against the ledger, or generated in prose?
4. Residency. Where do client books live, in which region, under which DPA?
5. Training. Is client data excluded from foundation-model training, in writing?
6. Filing. What exactly is HMRC-recognised today, and what still requires a human signature?
7. Bank and feed controls. Can the agent silently add accounts or live feeds?
8. Batch behaviour. If it prepares many clients at once, does anything file or send without review?
9. Export and exit. Can the practice take the book with it?
10. Published documents. Are the DPA and security pages public before signup, not only after?

AccountsOS's published answers to those points are on /for-accountants, /security, and /dpa. Practice pricing on the live site is £12 per live client + VAT, with a Ledger tier from £1.50 per file + VAT for dormant or low-activity files. This page is about trust, not a pricing pitch; treat those figures as the current practice list price and re-check the live page if you are buying.

Read the DPA. Then add Finn if the checklist holds.

Safety near client books is a system property: grounded rates, coded maths, human confirmation before writes, London residency, no training on client data, and a filing model that keeps the signature with the practice.

If that is the bar you use for any AI ledger, read the DPA, skim the security page, and then decide whether to add Finn to your practice.