Deterministic math, LLM narration: why it matters for GST
When a factory owner opens a dashboard the morning a GST return is due, they are not looking for a good guess. They are looking for the number. "Probably right" is a category error here — a return is either filed on correct figures or it is wrong, and wrong has a name, a penalty, and a notice.
This is the line InsightPilot draws through everything it builds: the numbers are computed, the words are narrated. A large language model is extraordinary at turning a table into a sentence a busy owner will actually read. It is the wrong tool for deciding what 18% of a reconciled taxable value is. So we don't ask it to.
Two jobs that look like one
Most "AI for accounting" demos blur two very different jobs into a single prompt: work out the figures and explain the figures. They read well in a demo because the model is fluent. They fail in production because fluency is not arithmetic. A model that has seen a million invoices can still return ₹1,00,000 as "100,000" — or quietly add a line that reconciles to nothing.
InsightPilot splits the job on purpose:
- The compute layer is deterministic. GST slabs, input-tax-credit matching, taxable-value roll-ups, lakh/crore formatting — these run in code, against the actual ledger rows, with the same result every single time. Re-run it a hundred times and you get one answer.
- The narration layer is the LLM. Once the figures exist and are trusted, the model's job is to say what they mean: which supplier's credit didn't match, which month drifted, what to check before filing.
The owner reads a clear paragraph. Underneath it, not a single rupee was invented by a language model.
Why this ordering is non-negotiable for tax
Three properties matter when GST is on the line, and only deterministic compute gives you all three:
- Reproducibility. The same input must yield the same output, today and at assessment time nine months later. A sampled model does not promise this; arithmetic does.
- Auditability. When a figure is questioned, you must be able to point at the rows and the rule that produced it — not at a prompt and a temperature setting.
- Explainability without hallucination. The LLM explains a number it did not compute, so it cannot silently change it. Narration can be wrong in tone; it cannot be wrong in the total.
Put narration first and you get a system that sounds confident and cannot be checked. Put computation first and the model becomes what it is genuinely good at: a translator between a correct table and a human who has forty other things to do.
What this looks like in practice
A reconciliation runs over the month's purchase and sales registers in code. Mismatched input-tax-credit entries fall out as structured rows. Only then does the model get involved — and only to write the summary: "Three suppliers' GSTR-2B credits (₹2.4 lakh total) don't match your books; two are timing differences that clear next month, one needs a call before you file."
Every figure in that sentence came from the ledger. The model chose the words, not the amounts. If you deleted the model tomorrow, the numbers would still be exactly right — you'd just be reading a table instead of a paragraph.
The takeaway for founders building on LLMs
The instinct to "just ask the model" is strong because it is fast to build. But for anything where a number carries a consequence — tax, payroll, credit exposure — the durable architecture is boring on purpose: compute deterministically, narrate with the LLM, and never let the two swap roles. Trust is not a feature you add later. It is the order in which you do the two jobs.