Somewhere in the space of Indian salary returns there was a point where earning ₹52,880 more computed ₹10 less tax. No CA ever hit it. No filer ever noticed it. My fuzzer found it: a one-in-350,000 floating-point rounding edge sitting in a tax engine that had already passed every hand-written test I had.
That bug is fixed and pinned as a regression test (the comment in it records the mechanism: a true half-point carried as 4.999...97 that rounded down), and it is the cleanest argument I have for the design rule behind itr-wala, an open-source skill that prepares Indian income tax returns from the terminal: the model is banned from doing math.
TL;DR The LLM reads your Form 16, AIS and 26AS, interviews you the way a good CA would, and fills in one JSON. Every rupee after that comes from plain Python: 51 golden tests hand-derived from the statute, 104 validator tests, a fuzzer past 350,000 random returns. Before anything is submitted, the portal's own computed figure has to match the engine's to the rupee, and you press every button yourself. Non-audit ITR-3/4 returns are due August 31.
In June and July, my feed filled with people filing their ITR with bare Claude. The best-documented run I found is a 250-upvote r/IndiaTax post: a software engineer with RSUs and US stocks, documents redacted, six hours spent reviewing every section before submitting. It mostly went well. The one place the model slipped, by the author's own account, was asking for Schedule AL under a threshold that had since been raised; the filer happened to know the current rule and caught it.
The run succeeded only because the human independently knew the one fact the model had wrong. That is luck with a good operator, and the next ten thousand filers will not all be good operators.
The failure mode of an LLM doing tax is specific: it is silent, confident, and plausible. Nowhere is that more dangerous than in the exact-arithmetic corners of the Income-tax Act, and Indian tax is full of them. Section 87A marginal relief right at the 12 lakh boundary. Surcharge tier cliffs and their own marginal relief. The month-counting rules behind 234B and 234C interest. The order in which the 1.25 lakh exemption nets against 112A gains. These are branch-heavy, exact-integer rules where an answer that is 99% right is simply wrong, and a model that is wrong sounds exactly like a model that is right.
So the skill splits the work by what each side is good at. The model does what models are close to superhuman at: pulling the 17(1)/17(2)/17(3) split out of a Form 16 PDF, reconciling three documents that describe the same income differently, and asking the questions the e-filing portal never asks: the rent you paid, the parents' health insurance premium, the NPS top-up you forgot you made. Its entire output is one JSON file of facts.
Everything with a rupee in it happens in a tax engine written in plain Python. Standard library only, no dependencies, runs offline. The model is not consulted about a single number. It cannot hallucinate a slab rate, because it is never asked.
Between the two sits a validator with opinions. It refuses to run at all if a PAN or Aadhaar shaped string appears anywhere in the input, so redaction is enforced rather than requested. And it cross-checks the TDS you claim against the totals your 26AS and AIS report, because the most common notice is not a wrong deduction, it is a mismatch.
Three layers, each of which has caught real bugs.
Golden tests are scenarios hand-derived from the statute with a calculator, the way you would check a CA's work if you had a free weekend and a grudge. There are 51 of them now. This layer caught an early build that denied surcharge marginal relief on capital-gains-heavy incomes.
Validator tests, 104 of them, pin the input checks: the Form 16 component sums, the TDS cross-checks, the refusal rules.
The fuzzer generates thousands of random returns on every CI run and asserts invariants that must hold for any legal return: the engine never crashes, the same input always produces the same output, the 87A rebate never exceeds its statutory cap, cess is exactly 4%, and the one that earns its keep: bump any income field upward and the tax may never go down. That last invariant is what surfaced the ₹52,880 edge. The cumulative corpus is past 350,000 returns.
On 11 August a contributor filed the best bug report this repo has received, with the statute cited and a fix attached. On a let-out property where municipal taxes exceed the rent, the engine computed a negative annual value and booked a house-property loss that set off against salary. The law caps that deduction at the annual value; only home-loan interest can create a house-property loss. The engine was understating tax for anyone who hit the case.
The fuzzer had been generating municipal-taxes-above-rent inputs on every CI run for weeks. Everything stayed green, because no invariant encoded that section of the Act. A fuzzer only enforces the laws you teach it. Randomness gives you coverage of the input space, not coverage of the statute. I do not know how many other sections the invariants still miss.
What closed the gap was a person who had read the law: a contributor sent a PR citing it and derived four new golden tests by hand. It was verified against the full suite plus 35,000 fresh fuzz cases and merged within a day. Open source is the only mechanism I know that scales "someone who read the statute is looking at your code."
By the end, what a filer is actually trusting is a short list of gates:
The skill never sees your password or OTP. The validator refuses identity-shaped input. And the last gate is the one I would keep if I could keep only one: before you submit, the portal's own computed tax has to match the engine's number to the rupee. If they disagree, something is wrong on one side or the other, and you stop. The Submit click is yours; the tool never touches it.
On 10 August, a user I had never spoken to tweeted:
ITR filled for free with claude
thanks 2 github.com/karanb192/itr-wala
[@ayushmokal6 on X], 10 Aug 2026
He followed up with "btw refund arrived within 24hrs", and the repo went from 37 stars to 628 as I write this. That refund speed is the tax department's doing, not mine; what the tool contributes is a return clean enough not to get stuck. Two community pull requests have landed since: one documenting the AIS/26AS download maze with extraction tests, the other fixing the house-property edge above with the statute cited. For a tax tool, I cannot imagine a better review.
Non-audit ITR-3 and ITR-4 returns for AY 2026-27 are due August 31, and belated returns run until December 31. If you want to try it:
/plugin marketplace add karanb192/itr-wala
/plugin install itr-wala@itr-wala
Then drop your Form 16 and AIS into a folder and say "file my ITR". If you end up filing at 11pm on the 31st, the arithmetic is the part you will not have time to check. It should also be the part you never have to.