A three-hundred row statement hides the four rows that matter. Every conversion is checked for the things a reviewer would want flagged — a payment large enough to raise a TDS question, the same amount paid twice on one day, cash near a statutory limit — and they arrive on a Review sheet in your Excel file.
It flags. It does not rule.
Whether TDS actually applies depends on facts that are not in a bank statement. Every finding is worded as something to check, never as a conclusion. This is a second pair of eyes, not a second opinion.
Questions
Does this tell me whether TDS applies?
No, and it deliberately never will. Whether TDS applies depends on the payee's status, the section, the year's thresholds and facts that simply are not in a bank statement. The audit says "this payment is ₹87,500 — review it". The judgement stays with you.
Are the thresholds current?
They are the commonly cited figures for Indian practice and they are configurable. Thresholds change with each Finance Act, so treat them as prompts, not authority — the tool is there to make sure a row is looked at, not to decide the answer.
Where do the findings appear?
On a Review sheet inside the Excel export, listing each finding, the rows it concerns and the amount. The sheet is only added when there is something to report — an empty tab in every file would just teach people to ignore it.
How does it identify the same payee across rows?
By stripping scheme codes, UTRs and bank identifiers from the narration and keeping what looks like a name. It is a heuristic, which is exactly why aggregate findings are worded as "payments that look like they go to the same payee" rather than asserting they do.
Is any of this sent to an AI service?
No. It is arithmetic over the rows already extracted from your PDF, run in the same request. No model, no external API, nothing about the statement leaves the server.