Reads
Companies, groups, the ledger master and the daybook, month by month, over Tally's own XML interface. Read-only, always.
What this is
PaperData TDS connects to Tally and pulls the raw daybook itself, uses AI to judge what each payment actually was and which section applies, and then checks what was really deducted. It is not a filing utility, and it is not a calculator you feed a prepared list to.
Reads
Companies, groups, the ledger master and the daybook, month by month, over Tally's own XML interface. Read-only, always.
Judges· AI
Which ledgers can attract TDS at all, and what a payment really was, decided by AI from the ledger names and voucher narrations rather than a keyword list.
Reports
Required against deducted, entry by entry, with the shortfall in rupees and the reasoning behind every call written into the export.
Why this is not another TDS tool
Every other tool in this category starts from a list your team has already built by hand. Building that list, deciding which expenses attract TDS and under which section, is the actual work. That is the part this does for you.
The scrutiny
This is the ledger scrutiny itself, not a calculator bolted onto the end of it. Steps marked AI are where judgement is applied to language rather than numbers.
Company list, group hierarchy, the full ledger master with PAN and GSTIN, and the daybook fetched month by month and de-duplicated by voucher GUID. No export, no template, no prepared list, just the same data a partner would open Tally to read.
Bank, GST, income-tax, stock, equity and round-off ledgers are ruled out, and every remaining expense ledger name is judged individually by AI to decide whether it belongs in a TDS audit at all. An exempt catalogue handles the ledgers that never attract deduction.
Each entry is traced to the party behind it. GSTIN structure, then PAN structure, then the name itself determine whether that party is an individual or a company, which decides the rate. Parties with no PAN are separated for 206AA.
The rule engine derives a section from the nature of the expense. That call is then reviewed by AI against the ledger names, the TDS ledger used and the actual voucher narrations, and can be overridden. Every override is written into the export with its confidence and the reason for it, so you can audit the machine.
Aggregates run per party for the full period, not per invoice, with dated rates, the shared 194I pot, and 194Q's excess-only basis. A vendor who crosses ₹1,00,000 in the eleventh month is caught in the eleventh month.
Required versus deducted, entry by entry, resolving to missing, short, excess or in order, with the shortfall in rupees and a remark explaining the verdict.
Every classification the AI overrides is written into the Excel export with its confidence and its stated reason, so the judgement is reviewable rather than taken on faith.
Where the judgement is
Applying 10% to ₹58,120 is not what takes a firm three days. Working out that a ledger called “Professional Charges” was actually a works contract, and that the next entry under the same head genuinely was professional fees, is what takes three days. That is a reading problem, and it is exactly where the AI is pointed.
“Professional Charges”
Ledger name in the books
Matches on the word professional. Books it to 194J at 10%.
The narration describes fabrication and installation at a plant. That is a works contract under 194C at 2%, and the classifier is given the narration precisely so it can say so.
Eight percentage points, on every entry under that head.
“Insurance”
Ledger name in the books
Reads as an exempt payment and is dropped from the audit.
Premium paid attracts nothing; commission received is 194D. Identical ledger names, opposite treatment. Separating them needs the surrounding context, not the label.
An entire section missed, or a clean payment wrongly flagged.
“Misc. Exp / Delhi Office”
Ledger name in the books
Matches no keyword list anywhere. Silently skipped.
Every expense ledger name is judged on meaning rather than checked against a fixed vocabulary, because no two firms name their ledgers the same way.
The entries nobody thought to look at.
Each of those calls is recorded: what the rule engine derived, what the AI classifier concluded, how confident it was, and why. You are reviewing a judgement, not accepting an output.
What it catches
Every flag carries the section it was tested against, the rate that should have applied, and the shortfall in rupees.
Missing
The threshold was crossed during the year and nothing was deducted. Aggregates are tracked per party across the whole year, not per invoice, so a vendor who creeps past ₹1,00,000 in the eleventh month still gets caught.
Short
2% applied where 10% was due, or the wrong payee type assumed. Required TDS is recomputed per entry from the section rule, the rate in force on that date, and whether the party is an individual or a company.
Wrong section
Professional fees sitting under 194C. The section implied by the TDS ledger is compared against the section the rule engine derives from the expense, and any mismatch is flagged with both.
206AA
Parties with no PAN on the ledger master are flagged, with the higher 206AA rate shown alongside what was actually applied. The report carries a dedicated 206AA chapter.
Coverage
You know the rates. What is worth saying is how the edges are handled: a rate that changed mid-year, two sections drawing on one threshold, and a section that charges only on the excess.
Rules carry dated rate and threshold periods, so an entry from April is measured against the rate in force in April, not today's. 194H moving from 5% to 2% is handled as a date range, not a flag day.
194I(a) and 194I(b) share one threshold. The Finance Act 2025 treatment is implemented as both a ₹6,00,000 full-year cumulative pot and a ₹50,000 calendar-month pot, applied together.
Where most sections charge on the full amount once the threshold is crossed, 194Q charges only on the excess over ₹50,00,000. That is computed separately rather than bolted onto the standard path.
When a party crosses an annual threshold, the full cumulative requirement lands on the crossing entry rather than being spread, which is what the department expects to see.
What you get out
Every figure on screen traces back to a voucher, and every export carries the reasoning with it.
29 columns per entry: base amount, rule-derived section, rate, TDS required, deducted, shortfall, running balance, status and remark, plus a summary sheet. Per party or all parties at once.
Executive summary, section-wise chapters, a 206AA chapter, and a methodology and disclaimers section. Carries your firm name and logo as letterhead.
The same entry-level detail as the workbook, for anyone who wants it in their own tooling.
Your client's data
The honest version, because this is the question that decides whether a firm installs anything at all.
PaperData TDS is a desktop application. The audit engine, your voucher data, and every report it produces stay on the machine you installed it on.
It reads companies, groups, the ledger master and the daybook over Tally's own XML interface on localhost. It does not write to Tally, alter vouchers, or post entries. Corrections are yours to make.
Deciding what a payment was is done by hosted models from OpenAI and Anthropic, and it is part of how the audit works rather than an optional extra. Expense ledger names, party names and voucher narrations are sent for that judgement. Amounts are not part of the classification request.
When you ask the in-app assistant a question about an audit, it is given entry-level detail (party, voucher, section, status and the amounts) so it can answer. That is the only step where figures leave the machine, and only for the questions you ask.
See it on your books
Install it on the PC that runs Tally and run your first audit the same afternoon, or let us walk through a real audit on your data first. The installer is per-user, so it needs no administrator rights on a locked-down firm machine.
PaperData-TDS-Setup.exe · 41 MB · Windows · v1.0.129
TDS is the first compliance we automated. ITR preparation, GST reconciliation and tax audit are what we are building next, on the same review-and-approve workflow. They will appear here when they work, and not before.