── ── Tax & compliance
The Silent Default Is the Bug: What Tax Software Must Never Pick for You
August 15, 2026 · 7 min read · By Brad Ju
When automation touches a client's books, the dangerous failures aren't wrong arithmetic — they're silent picks. Which workspace, which entity, whose return, and which stale conclusions get cleared on a re-scan are four questions software must answer out loud or refuse to answer at all.
The bugs that scare us in automated tax work are almost never arithmetic. A number that comes out wrong tends to look wrong, and a preparer catches it. The expensive failures are the ones where the software quietly made a choice on someone's behalf, the output looked entirely reasonable, and nothing on the screen said a choice had been made at all.
Four of those turned up in one week of connecting to real accounting data — not in edge-case fixtures, in production ledgers belonging to actual firms. Each one has the same shape: a default that stands in for a decision, with no way for a human to see it or override it.
1. "The first workspace" assumes there is only one
Ledger APIs commonly return a list of workspaces or organizations an account can reach, and the shortest possible integration takes the first element. That works right up until the account is a firm's — at which point it has several, and the software is now reading one of them because of list order rather than because anyone chose it.
The failure is invisible from the outside. The data comes back well-formed, the analysis runs, and the conclusion is about some real company. Just not necessarily the one the preparer had open.
2. "The first company" is the same bug one level down
Fix the workspace and the identical mistake is still sitting inside it, because one workspace can hold many entities — which is exactly the shape a firm's books take. Picking the first non-personal entity means the answer to "whose books am I reading?" was never chosen by a person and can't be stated by the interface.
Two rules make this safe. The selected entity has to be stored explicitly on the connection, the same way an OAuth-based integration already stores the account identifier it was authorized against. And if the stored entity is no longer present in the workspace, the correct behavior is to stop with an error — never to fall back to a different company's books. A fallback here doesn't degrade the answer, it changes whose answer it is.
3. A demo ledger reads exactly like a real one
Accounting platforms often ship sample or test entities, and they usually mark them with a flag. Ignore that flag and a ledger built for a product tour flows through the same extraction path as a real one, and a six-figure figure on screen turns out to describe a fictional company.
The rule we settled on: a demo entity is never selected automatically, but it can be selected explicitly. Tests and demos need to read fake books on purpose; nothing should ever read them by accident.
4. Whose return is this engagement even for?
A design partner put it plainly: the accountant who does the company's books isn't necessarily the one who does the owner's personal return. Compliance obligations already carry an obligor — the entity or the individual — so the missing piece was never the classification. It was the declaration of which side of that line this particular engagement was hired for, plus a gate that every read path goes through.
Three disciplines make a scope boundary safe to add to a live product. Default to everything visible and treat narrowing as a deliberate act, because hiding existing data behind a new permission is worse than having no permission at all — people conclude the data is gone and go looking elsewhere. Show the count of what's excluded rather than silently dropping rows, so "not yours to file" never reads as "the scan missed some." And enforce it on the server, per relationship, so a new read endpoint isn't a new hole. An unrecognized scope value falls back to showing everything: over-showing is a nuisance, silently under-showing is a missed filing.
The one that only appears on the second run
The fourth silent default isn't about what gets picked — it's about what never gets unpicked. Set a company's entity type, re-run the scan, and the S-corp return that was flagged before the entity type was known is still sitting on the board, open. The sweep only cleared the filings the current run happened to look at, so anything it stopped looking at stayed forever.
Clearing stale rows has a hard boundary worth stating precisely, because it's the kind of thing that quietly deletes a real obligation:
| Driven by | Examples | Swept when classification changes? |
|---|---|---|
| Federal/state tax classification | 1065, 1120-S, 1120 and their state analogues | Yes — a different classification means the return isn't due |
| Legal form of the entity | State LLC annual tax, franchise tax, annual reports | No — an LLC taxed as a C-corp still owes its state LLC tax |
| The individual, or payroll history | 1040, personal estimates, payroll filings | No — flag only, and payroll is add-only |
Machine-closed rows also need to say they were machine-closed, and stay revivable. Change the entity type back and the filings should come back with it; a cleanup that can't be undone is just a slower kind of data loss.
The general rule
All four are the same rule wearing different clothes: when the software has to choose something a human would want to know about, it either names the choice or refuses to make it. Store the selection instead of re-deriving it at each call site, because three call sites each guessing independently means one of them will guess differently and no one will notice. Fail loudly instead of falling back when the stored selection has gone stale. And when you hide something, say how much you hid.
How deciqAI handles it
Which workspace and which company a ledger read came from are stored explicitly on the connection and shown in the interface, with demo entities labelled and never auto-selected; if a stored selection disappears, the read stops rather than falling back to another company's books. Engagement scope — the business, the owner, or both — is enforced server-side on every read path and reports what it excluded instead of silently dropping it. Re-scans clear machine-closed filings with a reason attached, and only ones that tax classification determines. Educational content — not tax advice.
FAQ
Why is picking the first entity from a ledger API dangerous?
Because one workspace can contain many companies — which is exactly what a firm's books look like — so the software ends up reading whichever company happened to be first in the list. The result is well-formed and about a real company, just not necessarily the one the preparer meant.
What should happen if a saved ledger selection no longer exists?
Stop with an error. Falling back to another entity doesn't produce a slightly worse answer, it produces an answer about a different company, and nothing downstream will flag it.
How should software treat demo or sample ledgers?
Never select them automatically, but allow selecting them explicitly. Platforms usually flag these entities; ignoring the flag lets a fictional ledger produce real-looking conclusions.
What is engagement scope in a tax workflow?
A declaration of which side of a relationship the preparer was hired for — the entity's filings, the owner's personal return, or both. Obligations already carry an obligor; scope records what this engagement covers, and the filter has to run server-side on every read path.
When a re-scan clears stale filings, what must it not clear?
Anything driven by legal form rather than tax classification. An LLC that elects C-corp taxation still owes its state LLC tax and annual report, so sweeping those on a classification change erases a genuine obligation from the board.