Accounting and tax
AI tax software that shows its working
Language models are good at reading a document and bad at arithmetic. Build on the first, never the second, and the product stops producing confident wrong answers.
How to build AI into a tax product without regretting it
4 things that decide this
- 01Let the model extract, and let deterministic code calculate. A figure produced by a language model cannot be reproduced, defended or diffed against last year's return.
- 02Every extracted value needs the page and the box it came from. A preparer checking a number should reach the source in one click, not re-read the document.
- 03Rules change every year, so a rule engine has to be versioned by tax year. Software that quietly applies this year's threshold to last year's return is worse than no software.
- 04The product is not the answer. It is the reviewable path to the answer, because a licensed professional is signing it.
The wrong number arrives beautifully formatted
Ask a language model to total a column and it will give you a total. It looks right. It is formatted correctly. It is sometimes wrong, and nothing in the output distinguishes those two cases.
In most software that is a bug. In tax software it is a filing position somebody signs their name to, and the person carrying that risk is your customer.
So we split the job. The model finds and reads. Ordinary code computes and checks. When the two disagree, that disagreement is the feature, and it goes in front of a human.
The accounting and tax work we take
Built around document intelligence and rule engines, with a person at the decision point.
Document intelligence
Reading 1040s, K-1s and 1099s and pulling structured values with a source reference for each. IRS Escape Plan does this, including verification against qualified business income rules.
Rule and strategy engines
Deterministic logic evaluating a profile against a library of strategies. IRS Escape Plan runs an intake and scores more than 50 strategies per profile, which is code rather than a model.
Reviewable extraction
Every value linked to the document and position it came from. Without that link, checking the machine costs more than doing the work by hand.
Audit and premium document workflows
PremiumAudit.io runs document intake, extraction and validation across a full audit lifecycle, with the auditor reviewing before anything is final.
Reconciliation and variance
Comparing what a document says against what a system holds, then surfacing only the differences worth a person's attention.
Client portals and payments
Intake, scheduling, secure document exchange and billing around the professional work. Stripe across seven builds.
- IngestThe document, as filed.
- ExtractModel reads. Cites page and box.
- ValidateCode checks totals and ranges.
- FlagDisagreements only, not everything.
- ReviewThe professional decides.
- OutputTraceable back to the source page.
Collapse the middle two boxes into the model and you get a product that is confident, fast and occasionally wrong in a way nobody can see.
Tax rules are versioned. Most software is not.
Thresholds, phase-outs and limits move every year. A product that stores one current value per rule works beautifully in its first season and starts producing quiet errors in its second.
The failure shows up during an amendment. Someone reopens a prior year, the engine applies today's numbers, and the result differs from what was filed with no explanation anywhere on the screen.
Make the tax year a first-class input to every rule. It costs a little at the schema stage and it is close to unfixable once several seasons of data exist.
- Store rule values per tax year, never as a single current setting.
- Recompute a prior year with that year's rules, and show which version ran.
- Keep the inputs as they were at the moment of calculation.
Document-heavy systems with a professional reviewing
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
Two ways to put AI in a tax product
| Criterion | The demo-friendly build | How we build |
|---|---|---|
| Who calculates | The model produces the figure. | Code produces the figure. The model only reads. |
| Traceability | An answer in a chat box. | Each value linked to its page and position in the source. |
| Tax years | One current value per rule. | Rules versioned by year, with prior years reproducible. |
| Errors | Surface as a plausible number. | Surface as a flagged disagreement between reading and arithmetic. |
| The professional | Reviews the output if they have time. | Is the decision point, recorded in the data model. |
What these builds run on
Document AI
Logic
Application
Assurance
What accounting and tax teams ask
01Can AI read a K-1 reliably enough to use?
For extraction, yes, with the output treated as a proposal rather than a fact. Reading a labelled box from a structured form is close to what these models do best. The design question is what happens next: every extracted value carries its source location, arithmetic is checked in code, and anything that disagrees is queued for a person instead of quietly saved.
02Will a language model calculate a tax figure correctly?
A model will calculate correctly some of the time, which is the problem. Nothing in the output separates a correct total from a wrong one, and neither result is reproducible next week. Keep the arithmetic in ordinary code where it can be unit tested, diffed and explained to a reviewer who asks how a number arose.
03How do you keep client financial documents out of a model provider's training data?
By checking the terms before any document is sent, and by choosing an endpoint whose terms forbid training on inputs. The commercial terms you run under are part of the architecture, not a procurement footnote. Keep a record of which service processed which document under which terms, because a client may one day ask.
04Can you build something our preparers will actually use in season?
Only if it saves more time than it costs to check, which is a higher bar than it sounds. A tool that extracts 40 values and forces a preparer to verify each against the original PDF is slower than typing. That is why source links and confidence flags matter more than raw accuracy in this category.
05We are a firm, not a software company. Should we build at all?
Usually not a full product, and often yes to one workflow. Firms rarely need their own tax engine. What they do need is the piece their software does not model: an intake that feeds their process, a reconciliation their team does by hand every month, or a review queue. Start there, and we will say so on a free scoping call if the honest answer is to buy instead.
