Plenty of business owners ask a fair question: if AI can draft an email and analyze a document, why can’t it just calculate taxes directly? The answer isn’t about how “smart” a model is — it’s about what language models are, structurally. A language model doesn’t guarantee it will calculate the same thing the same way twice. A tax engine has to.
Why a language model isn’t a calculator
A language model like Claude generates its answer token by token, based on probability. That works beautifully for reading, classifying, and summarizing documents — tasks where some flexibility of interpretation is fine. It doesn’t work for calculating tax, where the result has to be identical every single time, regardless of how many times the query is repeated, which model version the provider happens to be running, or how the prompt was worded.
That’s not a flaw in any particular model — it’s a property of the entire category of technology. Taxes and social security contributions follow clearly defined rules, rates, and deadlines set out in regulation. Those rules need to be implemented as deterministic code that always returns the same result for the same input — not posed as a question to a language model.
Even if a model landed on the correct number every time, it would still be a system that’s hard to explain or audit in a straightforward way. Deterministic code can be opened, read line by line, and traced to show exactly which rule produced which part of the result. A language model’s answer doesn’t have that trail — it’s generated, not derived from an explicit formula.
What “no guaranteed repeatability” means in practice
Picture two identical sets of accounting documents, entered a week apart. A deterministic engine will calculate exactly the same tax from them, day in, day out, because it runs on rules, not predictions.
A language model asked directly to “calculate the tax” might arrive at a different result for identical inputs — not because it’s making a random mistake, but because it wasn’t designed for this. It’s a tool for understanding language and document content, not for performing repeatable legal arithmetic. Separating those two roles — AI proposes, code decides — is the foundation we build our own products on, not just advice from an article.
The consequences of a tax mistake aren’t abstract — they’re real money, statutory deadlines, and the business owner’s liability. That’s exactly the kind of place where decisions have to stay deterministic, no matter how good the underlying language model is.
How we solve this in Qkwit: AI reads, the engine calculates
In Qkwit — our AI-assisted accounting product for sole proprietors — separating these roles is an architectural principle, not an add-on.
AI (Claude) reads and classifies documents: extracting data from invoices, receipts, and confirmations, recognizing expense categories, and organizing information into a form that can be processed further. That’s a task language models are genuinely good at — understanding document content even when the format varies.
Calculating the actual tax and social security contributions is handled by a deterministic engine — code that always returns the same result for the same input, in line with current rates and rules. The language model is never the final link in the chain that decides how much a business owner owes.
This approach lets us use AI’s real strengths — reading, understanding, classifying documents — without handing the model responsibility it was never built to carry.
What could go wrong if AI calculated the tax itself
It’s worth considering the reverse scenario: a language model takes the input data and returns the tax amount owed on its own. The first problem shows up during an audit — it’s hard to demonstrate, step by step, how the model arrived at a specific figure, because there’s no explicit formula behind it, just a generated answer. The second problem is rate changes: when a tax bracket or contribution amount changes mid-year, deterministic code gets updated in one place, and the result is immediately consistent for every user. A language model has no single place to update — its “knowledge” of rates depends on what it learned and what it was given in context, and that’s not a mechanism worth building regulatory compliance on.
The third problem is consistency across users. Two business owners with an identical tax situation should get an identical result, regardless of who asks or when. A deterministic engine guarantees that by definition. A language model doesn’t, simply because that’s not its nature.
Where AI genuinely helps in accounting
That boundary doesn’t mean AI plays a small role in accounting — quite the opposite. Document extraction and classification is the single biggest time sink for sole-proprietor bookkeeping, and that’s exactly where AI meaningfully cuts down the work. We covered this in more depth in AI accounting for sole proprietors — compressing the monthly bookkeeping cycle comes from automating document reading, not from automating tax calculation.
We see the same pattern on the accounting-firm side, where document volume is even higher — more in AI for accounting firms.
What this means for accounting firms and sole proprietors
For a business choosing an AI accounting tool, this is a concrete question to ask: what exactly does the language model calculate, and what does code calculate? If the answer is “the model calculates the tax,” it’s worth asking how repeatability of the result is guaranteed — because the nature of language models itself doesn’t have a good answer to that question.
A good AI accounting implementation doesn’t hand the whole process to the model. It draws a precise line: what AI reads and classifies, versus what deterministic code calculates — and guards that line as rigorously as it guards tax deadlines.
FAQ
Should AI have nothing to do with tax calculation at all? AI is well suited to reading and classifying the documents that feed into a calculation. The calculation itself — applying rates and rules to specific amounts — should always be handled by deterministic software, not a language model.
Why doesn’t a language model guarantee the same result every time? Because it generates answers based on probability, not a fixed set of arithmetic rules. It’s an excellent tool for understanding language, but not for performing repeatable legal calculations.
How does Qkwit solve this? AI reads and classifies documents (invoices, receipts, confirmations), while a separate, deterministic engine calculates taxes and social security contributions — the language model is never the final link deciding the amount owed.
Does this approach slow things down compared to “AI calculates everything”? No — AI-driven document extraction is already the most time-consuming part of bookkeeping. Separating the roles doesn’t slow the process; it removes risk exactly where a mistake would cost the most.
Does this apply only to sole proprietors, or to other business forms too? The underlying principle — AI reads, code calculates — is universal, and we apply it beyond accounting too, for example in financial-sector decisions. Support for limited companies and accounting firms in Qkwit is coming soon, but the same split of roles applies from day one of a project, regardless of which business form it eventually supports.
What exactly could go wrong if a model calculated the tax directly? The biggest risk is no guarantee of the same result for the same input, and no clear way to explain where a specific figure came from. During a tax audit or a user complaint, that’s the difference between pointing to a specific rule and admitting the number was “generated.”
Let’s talk about your accounting
If you’re considering how to safely bring AI into your accounting processes without handing it decisions it shouldn’t make — get in touch.