Confidence and doubt
What should happen when bookkeeping automation is not sure?
It should stop and say so. Doubt ought to produce an exception — a named open item, with a reason, an owner and a date — rather than a plausible answer delivered in exactly the same tone as a certain one. A system with no way to express uncertainty has not eliminated it. It has relocated it, into figures that now look settled.
You cannot inspect anybody’s software, and the marketing will not settle it. What you can inspect is the residue: whether anything is ever held, whether there is a place for “not yet known”, and whether you have ever once been shown something a provider could not resolve.
Three things a system can do when it does not know. Only one is honest.
Every finance process, automated or not, meets items it cannot resolve. That is not a defect — ambiguity is a property of commerce, not of software. What differs between providers is which of three available responses is wired in as the default, and only one of them leaves you able to tell.
| Response | How it looks from outside | What it costs |
|---|---|---|
| Answer anyway | Everything is coded, nothing is outstanding, the month appears finished on time. | The error is now indistinguishable from the correct entries beside it, and travels into every report built on top of it. |
| Do nothing | The item quietly fails to appear. Totals are short and no explanation accompanies the shortfall. | Silence reads as completeness. A missing entry is materially harder to notice than a wrong one, because nothing draws the eye to an absence. |
| Raise an exception | A named open item, with a reason a non-accountant can read, an owner and a date. The period is visibly not finished. | It looks like unfinished work, because it is. This is the correct behaviour and the hardest one to sell. |
The three kinds of doubt behind those responses are worth separating, because providers tend to handle one well and the other two badly.
- Reading doubt. The system is not certain what the document says. A total on a photographed receipt, a handwritten amount, a date in a format that could be two different days, two currencies printed on one page.
- Matching doubt. It is certain what the document says and not certain what it belongs to. A payment that could settle either of two invoices for the same amount, a part payment against a larger balance, one transfer covering three bills, a refund that looks like a receipt.
- Treatment doubt. It knows what happened and not how it should be recorded. A cost that may belong to a specific client engagement, an amount that may be a deposit or a whole job, an item that may be capital rather than expense, a period that could arguably be this one or the next.
Automated mistakes are consistent, and consistency reads as reliability.
A person who resolves an unclear item badly usually does it once, and often remembers doing it. A rule that resolves it badly does the same thing identically every month, at speed, without hesitation. The output is a clean, stable, entirely plausible trend — wrong in the same direction throughout.
That is why these errors survive review. Reviews look for outliers, and a systematic misclassification is the opposite of an outlier: it makes the numbers more regular, not less. The month where a supplier is coded correctly starts to look like the anomaly.
There is also a specific confusion worth naming, because it sits underneath most of this. Automated matching produces a confidence level — a number expressing how strongly the system believes it has found the right answer. A match held at 71 per cent confidence is not 71 per cent right. It is either right or wrong, and the score describes the system’s belief rather than the world.
None of which is an argument against automation. Machine work is faster, cheaper and considerably more consistent than manual entry across the routine majority of transactions, and a business that refuses it pays for that refusal. The argument is narrower: the value of the routine majority is only realised if the residue is handled honestly, because the residue is where the expensive errors live.
How to tell from the outside, without seeing the software.
Buyers try to evaluate this by asking about technology, and the answers are unfalsifiable. These eight are different: each one asks for a thing that either exists or does not, and the difference between a real answer and a described process is audible in seconds.
- Ask to see the held pile. “Show me everything currently unresolved on our account.” A provider with a genuine exception state produces a list within minutes. A provider without one produces a description of its methodology. There is no third kind of answer.
- Ask what happens below the threshold. “When your matching is not confident, does the entry still get made?” Honest replies are “no, it becomes an exception” or “yes, above a level we set, and here is that level”. The evasive reply is a claim about overall accuracy.
- Look for a category of unknown. In the actual chart of accounts and in the monthly reporting, is there anywhere for an item that is not yet understood? If every transaction has reached a real account, either the business is remarkably simple or the unknowns have been dressed as knowns.
- Ask when you were last told something was uncertain. If the answer is “never” across months of real trading, that is not a compliment to the automation.
- Ask what happened to last month’s exceptions. Resolved how, by whom, on what date, on what new information? Items that disappear without a resolution recorded were cleared, not solved.
- Ask for one they got wrong. “Tell me about an error you found in your own work and how you found it.” A provider that has never found one either has none, has never looked, or would not say. Only one of those is likely.
- Watch an awkward month. A month containing a refund, a duplicate payment, a foreign-currency receipt and a supplier who changed their invoicing. Smoothness is the tell — genuinely difficult months should visibly cost more work.
- Check that the exception has a named owner. “Waiting on client” is a status, not an owner. A person and a date is an owner.
The opposite failure is real too, and worth saying plainly because it favours nobody. A provider that holds everything is not being careful — it is moving its work onto you and calling the transfer diligence. If a large share of ordinary transactions comes back as a question, what is missing is not confidence, it is an agreed treatment policy. The right shape is a modest set of genuine exceptions that turns over: raised, resolved, cleared, replaced by new ones.
Where At Par fits — and the limits.
At Par runs machine work across the routine majority of transactions and treats uncertainty as a state the system is required to enter. Where confidence is not sufficient to record something correctly, the item is held rather than posted — visible to the client, with a plain-language reason and a named next step. Two independent checks must agree before a record stands; where they disagree, the item is held rather than averaged. A qualified accountant (ACCA) is accountable for the treatments applied.
That behaviour sits underneath bookkeeping and month-end close, receivables and invoice follow-up, payroll and management reporting. How records and their evidence are stored, isolated and protected is a separate matter, set out under security and data protection. For a wider comparison of automated tools against a managed service, see AI bookkeeping services, compared.
For the related question of what a document itself fails to tell anybody, see what should happen after you send a document. For what an evidence trail behind a figure has to contain, see what evidence-backed bookkeeping means.
Asked by buyers trying to see past a demo.
How accurate is automated bookkeeping? +
Accuracy alone is a poor way to judge it, because the figure quoted is usually measured on the easy majority and says nothing about the remainder. A system that is right most of the time and has no way to flag the rest is more dangerous than one that is right slightly less often and visibly holds what it cannot resolve. The useful question is not the accuracy rate. It is what happens to everything outside it.
What is a confidence score in accounting automation? +
It is a number expressing how strongly a system believes it has reached the right answer — that a document was read correctly, or that a payment belongs to a particular invoice. It describes the system’s own belief, not reality. A match at high confidence is still either right or wrong. Where a provider sets the level above which items are recorded automatically, that setting quietly determines how much unresolved doubt ends up inside the accounts.
How can you tell if a bookkeeping provider is guessing? +
Look for the absence of unknowns. If every transaction has reached a specific account, no item has ever been held, and the client has never been asked a question about an ambiguous cost, the ambiguity did not disappear — it was resolved by somebody or something without saying so. Guessing at scale produces suspiciously tidy books: uniform coding, no open items, and month-end arriving on time regardless of what the month contained.
Why do errors from automated bookkeeping take so long to find? +
Because they are consistent, and consistency looks like reliability. A rule that misclassifies a supplier does it the same way every month, producing a smooth trend rather than an odd-looking spike. Reviews are built to catch outliers, and a systematic error is the opposite of an outlier. The mistake usually surfaces at a year end, in diligence, or during a tax enquiry — long after it was cheap to correct and by somebody with less context.
Does more automation mean fewer questions from an accounting provider? +
It changes which questions get asked rather than how many. Automation removes the mechanical questions — what does this document say, which account does this familiar supplier belong to — and leaves the ones that need business context: which engagement a cost belongs to, whether a payment is a deposit or a settlement, whether an unusual item is a one-off. Those cannot be answered by any system, because the answer exists only inside the business.
Is a provider that raises a lot of exceptions doing a bad job? +
It depends entirely on whether the exceptions turn over. A steady set that is raised, resolved and replaced is a working process. A growing pile that never clears is a process failing quietly. And a provider that returns a large share of ordinary, routine transactions as questions has a different problem: no agreed treatment policy, so the same decisions are being referred back repeatedly instead of being settled once.
What should a business ask a provider about its automation before signing? +
Four things, all answerable in a sentence by anyone who actually runs the process. What happens to a transaction the system cannot confidently resolve. Where an unresolved item appears, and whether the client sees it without asking. Who is named as the owner of each open item, and by when. And what the provider did with last month’s exceptions — resolved by whom, on what date, on what basis. Vague answers to these are the finding.
Send us a month that went wrong. We’ll show you what we could not resolve.
Give us a period with something awkward in it — a part payment, a duplicate, a foreign-currency receipt, a supplier nobody recognises. We will show you what was recorded, and just as importantly what we would have held and why.
Prefer to reach us directly? Tell us a little and we'll come back with a time.
Send an awkward monthWe use your details only to prepare for and hold this call. No spam, ever.
Reviewed by an ACCA on the At Par team · Last updated 29 July 2026 · This page describes how any provider should handle uncertainty, and how a buyer can test for it. See what we actually do.