Why do AI tools keep failing in accounting workflows?
Because the tolerance for a confident wrong answer is effectively zero, and most AI products are built assuming it is merely low. A summary that misreads a column, a total that does not tie to the ledger, a date pulled from the wrong period: each is invisible in a fluent paragraph and expensive downstream.
The second failure is trust collapse. A reviewer who catches two bad numbers stops trusting all of them, and then checks everything manually, at which point the tool costs time instead of saving it. Validation is not a safety feature here, it is the product.
What does deterministic validation actually check?
Code, not a second model, so the same input always gives the same verdict. Totals in the response reconcile against the matching rows in the source file. Every number cited is traceable back to that file. Dates fall inside the selected period. Categories come from your allowed list. Required fields are present, and reasoning text or prohibited content is absent.
A failed rule is never silently corrected. The service retries once with the failure fed back to the model, and if it fails again the response is returned as rejected with the failing rules listed, so your review screen shows a needs-review state rather than an answer. Your existing rules are the starting list, not a replacement for them.
Does client financial data have to stay in our own systems?
Increasingly, yes, and it is usually your clients who decide rather than you. Once an engagement letter or a customer's own policy says financial records cannot be processed by a third-party service, a hosted model API stops being viable no matter how good it is.
The alternative is a model running inside infrastructure you control, reached over a private path that is never publicly exposed. Your data stays where your clients expect it to be, and the question stops coming up in every sales conversation.
Where does AI save time in a practice?
Document intake and structuring, reconciliation support with every figure traced to its source row, categorisation against your own chart of accounts, drafting client-facing explanations a preparer then edits, and flagging anomalies for a human to judge. All review-only, all reconciled, none of it filing anything.
What we will advise against is anything that writes to a return or a ledger without a person approving it. Not because the model cannot do it, but because the liability sits with your firm and review-only output is what keeps it manageable.
How an engagement runs
| Stage | What happens | Timeline |
|---|---|---|
| Assessment | Your workflow, data path and existing review rules examined, with validation rules written as testable statements | About one week |
| Build | Model serving, validation gate, failure handling, and the reviewer-facing surface, delivered as separately accepted checkpoints | About three weeks |
| Private deployment | Where client data cannot leave your systems, the model runs inside your own infrastructure | Scoped on a call |
Work runs on synthetic data throughout, with review-only output and no automatic save or apply. Accounts stay yours and access is removed at handover.