TDS reconciliation after the Income Tax Act 2025

Nothing about the way you compute TDS on a vendor bill has changed. What changed is every label around it — the section number you code the deduction to, the name of the certificate you issue, and the mapping table sitting inside your AP system since FY 2025-26. That mapping is where the first year's errors will come from, and a rate-times-base check will not find them.

Start with the vendor master, not the return

FY 2026-27 is the first financial year running under the Income-tax Act, 2025 (Act 30 of 2025), which came into force on 1 April 2026 together with the Income-tax Rules, 2026 (notified by G.S.R. 198(E) dated 20 March 2026). No TDS provision was deferred past that date. Q1 has closed. If you have not yet reconciled a quarter under the new numbering, do the work in this order — and note that the first step is not a return at all:

1. Export your vendor master with its TDS columns. Every vendor row carries a section code, a rate and usually a threshold. Those three fields were populated under the old Act and, unless someone changed them deliberately, they are still populated under the old Act.
2. Remap the section codes. The provisions were renumbered. A code that was valid in March 2026 may not exist in the new scheme, may point at a different category, or may simply be a string your accounting system happily stores and your statement utility later rejects.
3. Re-agree the three ledgers — books, challans, statement — for a quarter you have already filed, not for the current one. Errors in a remap are systematic, so a closed quarter tells you the size of the problem across the whole year.
4. Fix the master, then reprocess. Correcting the return without correcting the master means you do the same reconciliation again in three months.

The reason to start at the master is that the deduction arithmetic is unchanged. Rate times base is still rate times base. A reconciliation that only tests whether the numbers multiply correctly will pass on every wrongly-coded bill in the file.

What actually changed, and what did not

Read that table as a warning about scope. What breaks in a renumbering year is reference data — codes, form names, mapping tables — and reference-data errors are invisible to every check that operates on amounts.

A worked example: April 2026, 214 vendor bills

A mid-size contractor runs 214 vendor bills through AP in April 2026, ₹2.31 crore gross. TDS is deducted on ₹1.83 crore of it; the balance is nil-deduction or GST-only. The rates below are the ones sitting on the vendor master. They are illustrative of one file — the row in the Section 393 table depends on the payee's status and the exact nature of the payment, so read them as an example, not as your rate card. Two traps are visible in this table alone: contractor deduction is 1% only where the payee is an individual or HUF, and 2% for everyone else; and fees for technical services attract 2%, not the 10% that applies to professional fees — a vendor master that carries a single blended "194J · 10%" row is already wrong before any renumbering.

Challans deposited for the month: ₹5,66,000. Books and bank agree exactly. Every controller-level check passes, and the month closes clean.

Then the quarterly statement is prepared and only ₹5,43,600 of it is accepted. A gap of ₹22,400 on a month where the cash was right to the rupee. Reconciled to the bill:

16 bills out of 214 — 7.5% of the file, with the cash reconciled perfectly throughout. That is the shape of a renumbering-year error: small in value, systematic in cause, invisible to a totals check. One incorrect row in the vendor master produced nine defective deductions in a single month, and would have produced roughly a hundred over the year had the quarter not been reconciled.

The transition trap: work done in one Act, paid under another

The renumbering does not respect your PO dates. A bill raised in March 2026 for work completed in FY 2025-26 but approved and paid in May 2026 sits across the boundary, and your AP system will code it from whichever master state it finds at the time it is processed. The legal test itself is settled, and it is simpler than the panic around it suggests:

• The trigger is credit to the vendor's account or payment, whichever is earlier — the same test as under the 1961 Act.
• That trigger date, and nothing else, decides which Act governs. Where the earlier of credit or payment fell on or before 31 March 2026, the 1961 Act governs the deduction; where it falls on or after 1 April 2026, the Income-tax Act, 2025 does. Section 536 (repeal and savings), read with Section 6 of the General Clauses Act, preserves obligations that had already accrued under the old Act — the repeal does not reopen them.
• What remains a judgement call is the reporting mechanics — which certificate form, and in which quarterly statement, a pre-commencement deduction now being corrected or revised should be reflected. Settle that once with your CA for the whole population, not bill by bill.

Note the practical consequence: a March 2026 accrual was almost certainly credited to the vendor's account in March, so it is a 1961-Act deduction however late the cash actually leaves. The risk is not the legal test — it is that your AP system codes the bill from whichever master state it finds at processing time. Do not let this be decided implicitly by processing order. Pull the list of open bills with a service period ending on or before 31 March 2026 that were still unpaid at the start of Q1, decide the treatment for that population once, in writing, and code them as a batch. It is a finite list and it shrinks every month. Leave it to the system and you will discover the answer from a rejection notice instead.

The five checks that actually catch a remap failure

Run these quarterly, on a filed quarter, not just at year end:

1. Section-code census. Group every deduction in the quarter by section code and count. Any code with a suspiciously low count, or any code you cannot name from memory, is a remap survivor. This one check would have found all nine bills in the example.
2. Cumulative-per-PAN test. Sum payments by deductee PAN for the year to date and test each against its annual aggregate threshold — not bill by bill. Threshold breaches happen between bills, which is precisely where a per-bill control cannot see them.
3. PAN status re-validation. Re-check deductee PAN status before each statement, not only at onboarding. Status changes after you onboard the vendor.
4. Three-way tie-out. Books TDS payable, challans deposited, statement accepted. All three, every quarter. The example passed a two-way tie-out cleanly and still carried a ₹22,400 defect.
5. Certificate-issuance trace. Confirm a certificate has actually issued, under the correct current form — Form 131 for non-salary deductees, Form 130 for salary — for every deductee with a deduction in the quarter. Vendors chase these, and a template still naming the old form is a vendor-relations problem before it is a compliance one.

Check 1 is the highest-yield control in a renumbering year and takes about ten minutes on a pivot table. Run it before anything else.

Where Recoup fits

Recoup's Payment Approvals computes TDS at the point of approval rather than in a spreadsheet after the fact — the section and amount are picked per bill from your vendor master, across the common vendor-payment sections, and clean invoices post straight to Zoho Books. That matters here for one specific reason: when the deduction is computed from the master at approval time, correcting a master row corrects every bill that follows it, immediately, instead of leaving a trail of manually-typed section codes to hunt down a quarter later. The nine-bill error in the worked example is a one-row fix under that model.

It does not decide the new section numbers for you. That mapping is a call your CA signs off once, against the bare Act — and then it needs to be enforced on every bill, which is the part software should be doing.

Related guides