Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Form 16A from March 2026 uses legacy section codes, while Form 131 from April 2026 uses new payment codes. Finance teams must match records across both eras without losing credits or triggering duplicate tax payments.
Identify every TDS receivable and payable record that spans the April 1, 2026 cut-over by financial year. Build an equivalency table between legacy section codes and Income Tax Act 2025 payment codes. Treat paired entries as equivalent matches on vendor, amount, and period. Route unmatched items to a cross-era review queue with a clear era flag.
Three-year cross-era window from April 1, 2026 through March 31, 2029 (FY 2025-26 correction cut-off). Dual-mode reconciliation enabled by default during transition. Era-flagged exception queue for PAN mismatches and amount variances.
Reconciled TDS receivable ledger spanning both eras, era-flagged exceptions, cross-era variance reports for audit, and protected credit claims for income tax returns.
An Indian IT services firm opens its Q1 FY 2026-27 TDS reconciliation in July 2026. The receivables ledger shows eight open items from March invoices where the client’s TDS deduction had not yet appeared in Form 26AS by year-end. Four of those items are now settled: the March invoice entries are matched to Form 16A certificates dated June 2026 carrying Section 194J. Three newer invoices from May 2026 are matched to Form 131 certificates carrying payment code 1003 under Section 393. One item is outstanding and the reconciliation engine cannot decide whether it is a 194J or a 1003 problem.
That is cross-era TDS reconciliation. This guide explains where the problem comes from, how long it lasts, and what a finance team needs to do to handle it without losing TDS credit or triggering notices.
What Cross-Era Reconciliation Means
Cross-era TDS reconciliation is the matching of TDS records that span two legislative regimes. From April 1, 2026, every new TDS deduction is classified under the Income Tax Act 2025 using four-digit payment codes in the 1001–1092 range, grouped under parent sections 392, 393, and 394. Every historical deduction retains its classification under the Income Tax Act 1961 using section codes like 194C, 194J, 194I, and 195.
In practice, the two classifications will coexist in the same Form 168, the same reconciliation run, the same TDS receivable ledger, and the same correction statement pipeline for at least three financial years. A Q1 FY 2026-27 reconciliation run will see March deductions arrive in Form 168 under old section codes (because the Q4 FY 2025-26 return was filed under the 1961 Act) alongside April deductions under the new payment codes. A Q3 FY 2027-28 run will still see correction entries from FY 2025-26 under old codes. The cross-era window does not close until the last correction statement for FY 2025-26 is filed, which under current six-year rules extends to March 31, 2029.
The reconciliation problem is not conceptually difficult. The finance team knows that Section 194J and payment code 1003 refer to the same professional fees payment type. The matching engine needs a configured way to treat them as equivalent so that automated matching does not flag false mismatches on every cross-era item. For a company that processes 500 TDS receipts per quarter, manual intervention on every cross-era item is not a scalable answer.
Where Cross-Era Matching Breaks
The transition creates four specific failure modes that finance teams should expect.
Failure 1. Same vendor, two classifications in one month
A vendor who billed the company for ₹2,00,000 of services in March 2026 and another ₹2,00,000 in April 2026 will have one deduction under Section 194J and another under payment code 1003. The vendor’s account in the TDS receivable ledger carries both. If the reconciliation system splits the account into two classification buckets, the receivable shows artificially unmatched balances. The underlying credit is correctly deducted; the ledger display is fragmented.
Failure 2. Late Form 168 updates shift classification
Form 168 for a given PAN updates as deductors file their returns. A credit originally visible in June 2026 under the new payment code may be corrected by the deductor in October 2026 if they realise the classification was wrong. During the transition, some corrections involve reclassification across the era boundary, for example a March 2026 deduction initially booked under 194C being re-reported under Section 393. The reconciliation system sees the same credit first under one code and then under another, and flags a mismatch unless the equivalency rule is configured.
Failure 3. Correction statement timing collides with new-era filings
A correction statement for Q2 FY 2025-26 filed in November 2026 must reference old section codes. The same deductor’s Q3 FY 2026-27 original filing, prepared in the same week, uses new payment codes. The TDS return preparation tool must support both code sets simultaneously in the same quarter of operating time. A tool that only carries the new payment codes after April 2026 cannot generate valid correction statements for old-era periods.
Failure 4. Partial year certificates with mixed codes
A large client who deducts TDS across multiple sections may issue a consolidated certificate covering FY 2025-26 partial period (January to March) and FY 2026-27 partial period (April to June) for the same vendor. Depending on how the certificate is generated, it may display a single consolidated credit line or it may display two separate lines with different codes. The reconciliation process must handle both presentations.
The Cross-Era Reconciliation Process
Step 1. Build the equivalency table
Create an equivalency mapping between legacy sections and new payment codes. Start with your top 10 to 15 active TDS section codes and map each to the corresponding payment code under the Income Tax Act 2025. Flag each pair explicitly as equivalent for reconciliation purposes. This equivalency table is the single piece of configuration that drives every downstream rule.
Step 2. Classify every open receivable by financial year
For every open TDS receivable, determine the financial year of the underlying deduction (FY 2025-26 or FY 2026-27 onwards). Financial year, not the date the certificate arrives, is the era marker. A March 2026 deduction that arrives in a June 2026 certificate is FY 2025-26 under the 1961 Act. Tag each receivable with its era.
Step 3. Run reconciliation with equivalency-aware matching
Trigger the reconciliation run with the equivalency table active. The matching engine treats an FY 2025-26 receivable under Section 194J as matchable to a Form 168 credit under Section 194J (direct match) or under payment code 1003 (equivalent match if the deductor re-reported). Any credit whose era does not match the receivable’s era is logged as a cross-era flag, not as a mismatch. Amount tolerances still apply.
Step 4. Route genuine exceptions to review
Exceptions that cannot be resolved by era and equivalency rules, such as PAN mismatches, amount gaps beyond tolerance, or deductor identification mismatches, are routed to a review queue. The queue shows both the legacy and new-era identifiers for each item, so the reviewer can see at a glance whether the mismatch is a classification issue or a substantive error.
Era Transition Reference Table
The table below shows the reconciliation era logic for transactions with different deduction dates, certificate issue dates, and correction timings.
| Deduction Date | Certificate Issue Date | Correction Window Ends | Era for Reconciliation | Classification Used |
|---|---|---|---|---|
| On or before 31 Mar 2026 | 15 Jun 2026 (for Q4 FY 2025-26) | 31 Mar 2029 | 1961 Act (legacy) | Section 194C / 194J / etc. |
| 1 Apr 2026 to 30 Jun 2026 | 15 Aug 2026 (for Q1 FY 2026-27) | 31 Mar 2030 | 2025 Act | Payment codes 1001 to 1092 |
| On or before 31 Mar 2026, correction filed Oct 2026 | Revised cert after correction | 31 Mar 2029 | 1961 Act (legacy) | Old section code retained |
| 1 Apr 2026 onwards, correction filed in FY 2028-29 | Revised cert after correction | 6 years from FY close | 2025 Act | Payment code retained |
| Consolidated FY cert covering Jan to Jun 2026 | On or after 15 Aug 2026 | Varies by line | Mixed, split by line | Both classifications on one cert |
| Q4 FY 2025-26 correction statement filed in FY 2026-27 | N/A | 31 Mar 2029 | 1961 Act (legacy) | Old section code |
The rule is simple once stated: the era follows the financial year of the deduction, not the date the certificate is issued or the date the correction is filed.
India-Specific Transition Rules to Know
Three Indian compliance specifics shape how cross-era reconciliation should be designed.
Section 194T on partner remuneration. Introduced by the Finance Act 2024, Section 194T applies 10% TDS on partner salary, bonus, commission, and interest above ₹20,000 per financial year. The first applicable year is FY 2025-26. Q4 FY 2025-26 returns filed in May 2026 will carry Section 194T entries under old-era numbering. Q1 FY 2026-27 returns will carry the same payment type under its new payment code. Partnership firms and LLPs should expect their first two quarters of 194T filings to straddle the era boundary.
Abolition of Sections 206AB and 206CCA. Higher TDS and TCS rates for non-filers of income tax returns are removed from April 1, 2026. Any compliance filter in the vendor onboarding process that flags 206AB applicability should be decommissioned from that date. Cross-era reconciliation must still handle historical 206AB entries in FY 2025-26 Form 168 data, because those deductions occurred under the old regime.
New form numbers and unified 26Q/27Q/24Q. The Income Tax Act 2025 consolidates several TDS return and certificate forms. Form 26AS becomes Form 168. Form 16A becomes Form 131. Forms 26QB (property), 26QC (rent), 26QD (individual contractor), and 26QE (virtual digital assets) consolidate into Form 141. Reconciliation workflows that parse specific form numbers must be updated to recognise the new set. The Income Tax India e-filing portal is the authoritative source for the final notified form specifications.
What Automated Cross-Era Reconciliation Changes
A reconciliation engine with dual-mode capability absorbs the cross-era problem as a configuration setting rather than a code rewrite. The practical capability required is an equivalency layer that treats legacy section codes and new payment codes as matchable identifiers for the same transaction type, combined with an era flag per record that prevents accidental misclassification of correction entries.
TransactIG supports this through three configuration modes: legacy, payment_code, and dual. Dual mode is the operating state for FY 2026-27 reconciliation runs, where new quarterly filings use payment codes but March 2026 items still appear in Form 168 under legacy classification. The engine’s variance taxonomy was expanded to include cross-era-specific codes such as TDS_194T for partner remuneration flows, TDS_194O for e-commerce operator TDS, TDS_194R for benefit or perquisite, and TDS_NR_GENERAL for non-resident payments, so that classification changes during the transition do not break downstream reporting.
For finance teams standardising on structured TDS reconciliation software, the cross-era window is a configuration question and not a rebuild. Teams operating on spreadsheets will spend roughly three to four staff days per quarter during FY 2026-27 handling cross-era exceptions that a configured tool would route automatically. Over a three-year transition window, that is 40 to 50 staff days per company.
Structured reconciliation software India built for Indian compliance typically includes the equivalency and era flag as standard features rather than as custom add-ons. Match rates at Indian enterprises moving from manual spreadsheet reconciliation to structured matching climb from around 51% to 88% after the masters are correctly mapped, and cross-era handling is the kind of regulatory shift where the gap between manual and automated widens further.