Deterministic Finance, Probabilistic Models: Why LLMs Break at the Reconciliation Layer

1. The Category Error Nobody Names Out Loud

Reconciliation is not a reading comprehension task. It is a proof. When your books say you bought Rs. 4,82,300 of input tax credit from vendor X in October, and the government's GSTR-2B says the same, reconciliation is the act of establishing that both records describe one identical economic event - with matching GSTIN, invoice number, invoice date, taxable value, tax heads, and period. The answer is either yes or no. There is no 'probably yes.'

A large language model does not produce yes or no. It produces the most statistically plausible continuation of a token sequence. That is a genuinely miraculous capability for unstructured text, and a structurally wrong capability for a ledger. The model cannot tell you whether two invoices match; it can tell you whether, in its training distribution, two strings that look like these usually match. Those are different questions, and in finance the gap between them is measured in rupees, notices, and sleepless nights.

We have watched engineering teams spend six months building 'AI reconciliation' that is, underneath, a very expensive fuzzy string matcher with a chat interface. The model is not the problem. The framing is. 'AI employee' is a marketing phrase. In a regulated ledger, it is a liability with a logo.

2. What We Actually Saw in Production

TaxSync ReconPro has been deployed across Indian businesses running anywhere from 200 to 40,000 invoices a month. We have run both architectures side by side on the same data: a pure LLM-first reconciliation pipeline, and a deterministic-rule-first pipeline that uses the LLM only at the edges. The results are not close, and they are not subtle.

On the LLM-first pipeline, throughput looked spectacular for the first three weeks. Match rates above 90 percent. Demos that made finance heads applaud. Then the second month's GSTR-2B landed, with its amended returns, partial credit notes, and a vendor who had changed his trade name mid-quarter. Match rate held. Accuracy did not. We found a 2.1 percent rate of confident wrong matches - invoice A matched to invoice B because the numbers were close and the vendor names shared a word. On 30,000 invoices, that is 630 incorrect input tax credit claims. At an average ITC of Rs. 18,000, that is over Rs. 1.1 crore of wrongly claimed credit sitting in a ledger that an auditor will eventually read.

The deterministic-first pipeline was slower to configure. It required someone to encode the actual matching rules - exact GSTIN plus invoice number plus date within tolerance, tax-head-level value comparison, credit-note netting, amendment supersession. That took three weeks of domain work instead of three days of prompt engineering. But every decision it made was reproducible: run the same data twice, get the same answer twice. Every match carried a rule ID and a confidence band. Every exception carried a reason code. When the auditor asked 'why was this claimed,' the answer was a rule reference, not a probability.

The lesson was not that the LLM is useless. The lesson was that we had been asking it to do the one job it is structurally incapable of doing - certifying a number.

3. The Three Failure Modes That Survive Every Prompt

We catalogued the failure modes across six months of production data. They are not bugs in our prompting. They are properties of the model class, and they reproduce on every frontier model we tested, including the ones marketed as 'reasoning' models.

Failure mode one: confident wrong matches. The model matches invoice 4521 to invoice 4527 because the digits are adjacent and the amounts are within 4 percent. It reports 97 percent confidence. The GSTINs differ by one character. A human accountant catches this in two seconds. The model cannot, because it has no concept of 'this field must be exact' - it only has 'these tokens usually co-occur.' Confidence in a language model is a measure of plausibility, not correctness, and in reconciliation those are opposites.

Failure mode two: silent omissions. When a line item does not fit the dominant pattern of the document, the model drops it rather than flagging it. A credit note tucked between two debit notes. An invoice with a negative taxable value. A row where the tax head is blank because the vendor's ERP exports it that way. The model produces a clean reconciliation that is quietly missing 3 percent of the data. You will not notice until the totals do not tie, and by then the report has already been filed.

Failure mode three, and the one that should end the conversation: non-reproducibility. Run the same reconciliation on Monday and Thursday. Get different match sets. The temperature is low. The prompt is identical. The model is non-deterministic by construction, and its outputs drift with context window state, tokenization boundaries, and silent model updates. An audit trail requires that the same inputs produce the same outputs forever. A model that cannot promise that cannot be the system of record. Full stop.

4. Where Language Models Actually Belong: The Edge Architecture

None of this means AI has no place in finance. It means AI has a specific place, and that place is the edge of the pipeline, never the center. We run a four-layer architecture in TaxSync ReconPro, and the LLM touches exactly two of the four layers.

Layer zero is the deterministic core: a rule engine that performs exact and tolerance-based matching on structured fields, nets credit notes against originals, applies amendment supersession logic, and computes tax-head-level differences. This layer has no model in it. It is code. It is testable. It is the same on Tuesday as it is on Friday. It produces a match decision, a difference, and a reason code for every single invoice. This is the system of record.

Layer one is LLM extraction and normalization. This is where the model earns its keep. Vendor invoices arrive as scanned PDFs, WhatsApp photos, and Tally exports with inconsistent column names. The LLM reads unstructured documents and emits structured JSON: GSTIN, invoice number, date, taxable value, CGST, SGST, IGST, total. It is a very expensive, very capable OCR-plus-parser, and it is excellent at it. The output is validated against schema and range checks before it ever touches layer zero. If extraction fails validation, the invoice goes to a human queue. The model never gets a second guess.

Layer two is LLM triage and anomaly flagging. Here the model reads the exception log from layer zero - the invoices that did not match - and clusters them: 'these 47 look like the same vendor with a slightly different name,' 'these 12 have dates off by exactly one day, likely a timezone export issue,' 'these 3 are genuine mismatches.' It writes a natural-language summary for the accountant. It does not decide anything. It organizes the work for the human who will decide.

Layer three is the human checkpoint. Every exception above a threshold value, every first-time vendor, every amendment, requires a human sign-off with a reason code. The LLM is not in this loop. It prepared the briefing. The human signs. The immutable audit log records both the model's suggestion and the human's decision, with timestamps, so that in an audit you can see exactly what the machine proposed and what the person chose.

5. The 'AI Employee' Framing Is a Liability in Regulated Finance

We sell AI. We are not anti-AI. But we have stopped using the phrase 'AI employee' in any context that touches a regulated ledger, and we think the industry should too.

The framing does real damage. When a CFO hears 'AI employee,' they imagine a junior accountant who works 24 hours and never complains. What they actually get is a system with no legal personhood, no professional liability, no ability to be cross-examined, and no memory of why it did what it did last Tuesday. If a human accountant makes a wrong ITC claim, there is a person to question, a credential to check, and a professional body to complain to. If a model makes the same claim, there is a prompt and a probability distribution. Regulators and auditors are not ready for that, and they should not have to be.

The reframing we use with clients is 'AI-assisted deterministic pipeline with human checkpoint.' It is less exciting in a pitch deck. It is also the only framing that survives a GST audit, a statutory notice, or a due-diligence data room. We have lost deals to vendors who promise 'fully autonomous reconciliation.' We have also kept clients who came back after those vendors failed an audit. The market is slowly learning the difference between a demo and a system of record.

There is a broader point here about the word 'autonomous.' In finance, autonomy is not a feature. It is a risk transfer. Every time you remove a human from a decision, you are not eliminating cost - you are moving liability from a person who can be held accountable to a system that cannot. That trade is sometimes worth making. It is never worth making silently.

6. Measuring AI in Finance Without Vanity Metrics

The metrics most vendors report are designed to make the model look good, not to make the finance team safer. 'Automation rate' is the worst offender. A system that auto-approves 98 percent of invoices sounds impressive until you learn that the 2 percent it flags are all the hard ones, and that 4 percent of the auto-approved ones are wrong. Automation rate measures how much work the model took off your plate. It says nothing about whether that work was done correctly.

The metrics we track, and the ones we think every fintech AI deployment should be contractually bound to, are these. First, ITC claim accuracy against a manually verified ground truth on a monthly sample - not the model's own confidence, an independent check. Second, reconciliation cycle time from GSTR-2B download to filed return, measured in hours, not in invoices processed. Third, audit exception rate - the number of items an auditor flags per thousand invoices. Fourth, false-positive rate on anomaly flags - how often the model cries wolf, because a triage tool that over-flags trains accountants to ignore it. Fifth, human review hours saved, not eliminated - the honest number, because 'eliminated' is a claim no production system has earned.

The single most useful metric we have found is one we call deterministic coverage: the percentage of transactions resolved entirely by rules, with zero model involvement. A high number means your data is clean and your rules are good. A low number means you are leaning on the model to paper over messy inputs, which is the most expensive way to avoid a data-cleaning project. We have seen deterministic coverage rise from 61 percent to 94 percent over six months of a client engagement, entirely through data hygiene and rule refinement, with no change to the model at all. That is what real AI maturity looks like in finance: the model does less, not more.

7. The Architecture We Recommend, In One Page

If you are building or buying AI for financial reconciliation, here is the architecture we would defend in front of any auditor, regulator, or due-diligence committee.

Layer zero: a deterministic rule engine. Matching, tax treatment, tolerance bands, credit-note netting, amendment supersession. No model. Fully testable. Reproducible. This is the system of record and it never changes without a code review and a regression suite.

Layer one: LLM extraction and normalization. Unstructured documents in, validated structured JSON out. Schema and range validation before anything downstream sees it. Failed extractions go to a human queue, never to a retry loop.

Layer two: LLM triage and anomaly detection. Clusters exceptions, drafts plain-language summaries, suggests groupings. Writes recommendations, never decisions. Every suggestion is logged with the model version and prompt hash.

Layer three: human checkpoint. Threshold-based sign-off on exceptions, first-time vendors, amendments, and anything above a configured value. Reason codes are mandatory. The model is not in this loop.

Layer four: immutable audit log. Every decision at every layer, with inputs, outputs, model version, prompt hash, human identity, and timestamp. This is the artifact that makes the system defensible. If you cannot produce this log for any transaction on demand, you do not have a reconciliation system. You have a very fast guess.

The model touches layers one and two. It never touches zero or three. That boundary is the entire point of the design, and it is the line most vendors will try to sell you across.

8. The Contrarian Conclusion

The companies that win in fintech AI over the next five years will not be the ones with the best models. The models are commoditizing. Every vendor will have access to the same frontier capability within six months of anyone else. The moat is not the model. The moat is the deterministic core, the data hygiene, the audit log, and the honesty about where the machine stops and the human begins.

AI is a powerful solvent for unstructured data. It reads messy documents, extracts structure, and surfaces patterns that would take a human team weeks. It is genuinely transformative at that job, and we use it every day. It is also a terrible notary for structured money. It cannot certify a number. It cannot promise reproducibility. It cannot be cross-examined. Asking it to do those things is not ambitious engineering. It is negligence with a better user interface.

The most cutting-edge thing a fintech company can do right now is not to build a smarter model. It is to build a system that knows exactly what it does not know, says so out loud, and hands the hard calls to a human with the context to make them. That is less impressive in a demo. It is the only thing that survives contact with an auditor, a regulator, and a due-diligence data room. We would rather be boring and correct than brilliant and wrong. In finance, that is the whole game.