Coming soon. We are finishing prices, contact details and policies. Booking and sign-up open shortly.
DownloadsSign in Book a walkthrough
← Journal
BUILDING CORELYTIX · TDS AND TCS RETURNS

A chartered accountant, an AI, and a TDS return

One of them knew which mistakes cost a client money. The other could write code and test it through the night. Neither could have built this alone. This is what actually happened.

Corelytix Journal · by a practising Chartered Accountant, with Claude19 October 202612 min read

Every quarter, in a practice in Kusumpura, the same thing happens. The deductions are in Tally. The challans are in the bank's portal. The return has to be built in another program, by typing the same facts a second time, and then checked by a utility that rejects the file for a reason it explains in a code. Most of the work of a TDS return is not tax. It is copying, and then hunting for the copying mistake.

The chartered accountant who runs that practice decided the copying should stop. He was already building Corelytix, his firm's own software, and he wanted a TDS module in it. He chose not to hand it to his developer. He opened a session with Claude, Anthropic's AI, and gave the work to it instead.

"No demo software"

His first instructions were not technical. They were about the standard.

I need robust, professional stuff — no demo software. It must be well tested, like the Indian Air Force's Rafale.— the CA, in the first hour

Later he reached for other engines — a B-25 bomber, a Toyota — but the point never changed. A TDS return goes to the government under a client's TAN. A wrong figure is not a bug report; it is a notice, a late fee of ₹200 a day, interest at one and a half per cent a month. He wanted software he could sign behind.

That set the terms of the collaboration. Claude would write the code. But nothing would count as done because it looked finished. It would count as done when it had been proved — and the proof would be designed by people trying to break it, not by the code checking itself.

The rule before the code

The first thing Claude did was not write a program. It downloaded Protean's file-format specifications — the Excel workbooks that define, field by field, every line of a TDS return — and read them into tables. Not a summary of them; the workbooks themselves. When the new Income-tax Act, 2025 brought new forms, 138, 140, 143 and 144, the new workbooks were read the same way.

Then the rules were written down in plain words before a line of the engine existed: when interest runs from the date of deduction and when from the date it was due; why the late fee is capped at the tax; why a GST state code is not a TDS state code, so that Bihar is 10 in a GSTIN and 05 in a return. The CA's knowledge decided those rules. Claude's job was to make sure the code obeyed them exactly.

Two engines that are not allowed to talk

A program that checks itself proves nothing. So for the hardest parts, a second engine was written from the written rules alone, without reading the first. Then both were given the same statements — clean ones, statements with mistakes planted in them, and statements made of junk: a date of 30 February, an amount written as 1_000, a PAN in Arabic-Indic digits.

Where the two engines disagreed, one of them was wrong, or the rule was unclear. Both happened. The junk test found that the first engine accepted 1_000 as a number — Python reads it as one thousand; a TDS return should not. The rule was tightened in both engines and the run repeated until they agreed on every input.

The second idea was older and simpler: plant mistakes on purpose. Thousands of synthetic statements were generated, each with a known error put in — a challan paid late, a deduction with no PAN, a challan claimed twice. Every planted error had to be found, and nothing that had not been planted could be flagged. Then the same was done to the code itself: realistic bugs were planted in the engine, one at a time, to prove the tests would notice. A test that cannot fail is decoration.

The competitor's login

Halfway through, the CA sent screenshots of the best-known return software in the market and said: I need these in my app. Then he asked whether he should buy a login to it, for ₹1,800, to study it.

Claude advised against it. A licence bought to copy a competitor may breach its terms, and there was no need: the authoritative references were free. Protean publishes the file formats and its own return preparation utility; TRACES supplies the challan and consolidated files. The screenshots told us what a CA expects to see — a challan master, a deductee master, a return dashboard, an error locator. The specifications told us how it must work. The CA agreed. Corelytix would match the best in the business by being right, not by imitating it.

Things the software refuses to do

Some of the most important decisions were refusals, and most of them came from the CA's own sense of where the line is.

Corelytix never guesses a payment code. If a professional's fee could be technical services or professional services, it asks you once, and remembers your answer for that party. It does not store or type a client's income-tax or TRACES password, and it does not solve CAPTCHAs. It does not invent a government file format it has not seen: the CSI and Consolidated files from TRACES are not yet read, because no real sample has arrived, and a guessed format would be a quiet way to be wrong. And it does not make Form 16 Part A. That comes from TRACES; Corelytix prepares Part B, joins the two by PAN, and sends them.

The hard part: corrections

A regular return is a single statement. A correction is a conversation with a statement already filed. Change a deductee's PAN, and the file must quote the old PAN as a verification key. Add a challan, and it must be numbered after the last one TRACES knows. Change the deductor's address, and a single indicator must be set on exactly one batch. Protean's correction format has a different rule for every field and every correction type — C1, C2, C3, C4, C5, C9.

Claude did not hand-code those rules. It extracted them from Protean's correction workbooks, nine of them, so that every field the format says must be empty for a type is emptied by reading the rule itself. Then it built something that does not exist in the code it was testing: an independent reader that takes a correction file the way the central system would, applies it to the return as filed, and rebuilds the corrected statement. If the rebuilt return is not exactly what the CA asked for, the correction is wrong.

Random corrections, every form, both Acts1,230 / 1,230
Corrections of corrections, three deep506 / 506
Q4 salary corrections (C4)196 / 196
Bugs planted in the correction code, caught26 / 26

The planted-bug run was the humbling one. The first time, the tests caught sixteen of twenty planted bugs. Four slipped through — among them a correction that set the "updated" flag on a challan that had not changed, and a change of PAN filed under the wrong correction type. Each miss meant a check was missing, and each check was added. Only then did the count become twenty of twenty, and later twenty-six of twenty-six.

What the human did that the AI could not

It would be easy to tell this as a story about a machine. It is not. The CA decided what "correct" meant. He knew that one deduction is often paid through two challans, that a deductor's TAN never changes in a correction, that a filed return must be locked. He noticed what a screen should feel like to a person who files hundreds of these a quarter. He asked for the reminder to the client for data, because chasing data is half of the job. And he drew the line on passwords before it was ever a question.

What Claude contributed was stamina and rigour of a particular kind: reading a 450-row specification without skimming, writing the second engine without peeking at the first, running a test five thousand times instead of five, and saying plainly when something was not yet true. When the CA's developer was asked to deploy it, the package carried a note of what it does not do, alongside the tests.

What it does not do yet

Honesty is part of the method, so here is the list. No file from this module has yet been through Protean's File Validation Utility; that is the next step, on the CA's own machine, before the first live filing. The CSI and Consolidated-file imports wait for real samples. Form 138 for the fourth quarter waits for Protean to publish its layout. The certificates are not digitally signed by the software. And the salary tax rates were written from the law as Claude knew it; the CA will check them against his own working on real employees.

A TDS module is never finished, because the law is never finished. But it can be built in a way that makes its mistakes visible — to a test, to a second engine, to a reviewer — before they reach a client. That was the whole idea. A chartered accountant who knows where the bodies are buried, and an AI that is happy to dig all night. Between them, the copying stopped.

The figures in this article are from the test runs on 19 October 2026 and are reproducible: the test suites ship with the code. If you find an error in the article or in the module, write to us; we will correct it in public. The TDS returns module → · The method →