── ── Tax & compliance
Pulling Numbers Out of a Client's Books: Three Ways It Silently Goes Wrong
August 13, 2026 · 6 min read · By Brad Ju
Reading a client's general ledger into a tax analysis fails quietly in three specific ways: treating a missing account as a zero balance, reading debits without netting credits, and overwriting a value a human already reviewed. Each one produces a number that looks clean and is wrong.
The appealing version of AI for a tax practice is that it connects to the client's accounting file and the analysis just appears. The connection part is easy. The part that decides whether the output is usable is what happens when the ledger doesn't say what the code assumed it would say — and those failures don't announce themselves. They produce a clean-looking number with a confident label.
Three of them account for most of the damage.
1. A missing account is not a zero balance
You go looking for the distributions account and it isn't in the chart of accounts. The tempting default is zero. It is the worst possible default, because zero is an assertion: it tells everything downstream that this company verifiably took no distributions. In an S-corp reasonable compensation analysis, distributions are the cap on the exposure — so a false zero makes the entire exposure vanish, silently, and nothing on the screen indicates that anything was missing.
The correct behavior is to carry it as missing and say so. A number that isn't there is a question for the preparer, not a value.
2. Read the net, not the debits
Reversing entries post to the opposite side. Read only the debit column of a distributions account and a distribution that was reversed in full still counts, because the credit that cancelled it was never subtracted. The result is inflated — and inflated in the direction that makes the analysis look more valuable, which is exactly the direction that erodes trust when the preparer ties it back to the books.
Net the debits against the credits, every time, and show the arithmetic so it can be tied out.
3. Never overwrite what a human already confirmed
Extraction runs more than once — the books change, the connection refreshes, someone re-runs it. If a re-run replaces a value the preparer already reviewed and adjusted, the system has just discarded professional judgment in favor of a fresh machine read. Re-extraction should update untouched rows and leave confirmed ones alone. This is a one-line rule that is very easy to leave out and very expensive to discover.
Extracted is not confirmed
Underneath all three is the same principle: reading a number and accepting a number are different acts, and the second one requires a person. Numbers pulled from a ledger drive six-figure conclusions in exactly the way numbers pulled from a prior-year return do. There's no argument for reviewing one and not the other, so both should land in the same queue as pending until someone confirms them.
The review isn't the same review, though, and the queue should say which is which:
| Prior-year return | Current-year books | |
|---|---|---|
| Status | Filed and frozen | Live, unfiled, unreviewed |
| What the reviewer checks | Was this extracted from the right line? | Does this account actually hold this thing? |
| Typical failure | Wrong line on the form | Right account name, wrong contents |
| Confidence display | Meaningful — extraction can misread | Misleading — a deterministic read is always "100%" |
That last row is subtle and worth stating plainly. When a model extracts a figure from a PDF, a confidence score carries information: it might have misread. When code reads an account balance through an API, there is no misreading to speak of — so displaying 100% next to it doesn't mean "this is right," it means "nothing went wrong on the way in." A reviewer reads a green 100% as permission to skip the row. Better to show no percentage at all than to show one that means less than it appears to.
For the same reason, a high confidence score is never a statement that the number is appropriate to use. That judgment belongs to the person who signs.
What you get on an empty ledger
One useful test of whether an extraction layer is designed or improvised: run it against a client who has barely booked anything. Some facts don't need a ledger at all — entity type, for instance, comes from the entity itself. A well-built layer still produces those for confirmation, and simply reports the rest as missing. A brittle one either errors out or fills the gaps with zeros, which is failure mode #1 with extra steps.
How deciqAI handles it
Ledger reads land as pending facts in the same confirmation queue as tax-return extractions, tagged by source so the reviewer knows whether they're checking a filed return or live books. Missing accounts are reported as missing, balances are netted across debits and credits, and confirmed rows survive re-extraction. Educational content — not tax advice.
FAQ
Can AI read a client's QuickBooks file for tax planning?
It can read the balances reliably — that part is a deterministic API call, not a model. The risk is in the handling: whether a missing account is reported as missing or defaulted to zero, whether balances are netted across debits and credits, and whether a human confirmation step stands between the read and the conclusion.
Why is defaulting a missing account to zero dangerous?
Because zero is a claim, not an absence. In an S-corp analysis, distributions cap the exposure, so a false zero erases the exposure entirely with nothing on screen to indicate a value was never found. Missing and zero must stay distinguishable all the way to the reviewer.
Should numbers pulled from the books be reviewed like numbers from a tax return?
Yes. Both drive the same conclusions, so both deserve the same gate. The review differs in kind: for a filed return you're checking whether the right line was extracted; for live books you're checking whether the account actually holds what its name suggests.
What does a confidence score on an extracted figure actually mean?
It means the extraction believes it read the source correctly. It says nothing about whether the figure is appropriate for the analysis — that is a professional judgment. For deterministic reads, where misreading isn't really possible, showing 100% is misleading and is better omitted.
How do you keep re-running an extraction from wiping out a reviewer's work?
Re-extraction should update only rows that haven't been confirmed. Any value a preparer has reviewed and accepted stays put, so a refresh of the ledger connection never overwrites professional judgment with a fresh machine read.