The shift to Income Tax Act 2025 on April 1, 2026 requires pre-migration closure of legacy correction windows, vendor master updates, GL code loads, cut-over planning, and dual-mode testing. Without a structured checklist, finance teams risk missing correction deadlines and carrying incorrect configurations into production.
Sequence the migration across four phases. Close time-barred correction windows for FY 2018-19 through FY 2022-23 before March 31, 2026. Update vendor master and chart of accounts with payment code placeholders. Decommission Section 206AB and 206CCA compliance filters. Run end-to-end cut-over and test cycles.
Cut-over window targeted end-March 2026. Dual-mode reporting enabled on go-live so the same source data produces both legacy and new-era outputs. Read-only history retained for 206AB and 206CCA filters.
Go-live readiness checklist, pre-migration correction completion report, vendor master gap report, and cut-over test results covering ERP master updates, GL code loads, reconciliation configuration, and end-to-end test runs.
Most Indian finance teams treat April 1, 2026 as a date on the compliance calendar rather than as a programme deadline. The shift from the Income Tax Act 1961 to the Income Tax Act 2025 is not a flag that flips overnight. It is a migration with dependencies in the ERP vendor master, the chart of accounts, the TDS return preparation utility, the bank’s challan deposit interface, and the reconciliation system that reads Form 26AS and writes to the receivable ledger. This checklist covers what has to be done, in what order, and by when.
If your finance team has not started preparation by the beginning of March 2026, the risk is not a missed April payroll cycle (that will get done manually). The risk is that Q1 FY 2026-27 reconciliation in July 2026 uncovers a cascade of classification errors from April, May, and June that then require correction statements, TRACES interaction, and reconciliation rework.
What the Migration Actually Covers
The migration programme touches five functional areas in a typical Indian enterprise: the ERP vendor master and payment type master, the chart of accounts (TDS payable GL codes may have the section number embedded), the TDS return preparation utility (Saral, ClearTDS, or a direct TRACES interface, each needing the updated FVU validator), the bank’s challan deposit interface section code dropdown, and the reconciliation system that consumes Form 26AS and Form 168.
None of these steps is individually complex. The challenge is dependency order: the reconciliation system cannot be fully configured until the ERP master data is updated; GL code additions require accounting team approval; the return preparation utility update depends on the software vendor’s release; and the cut-over has to happen while the team is also closing March books and filing Q4 FY 2025-26 returns through May and June.
Why the Migration Breaks If Treated as a Flag Flip
Three patterns consistently cause April 2026 problems that could have been avoided with proper migration planning.
Pattern 1. Master data partially updated before go-live
A team updates the top 10 TDS sections in the vendor master but leaves the less-frequent ones (for example, Section 194D for insurance commission or Section 194N for cash withdrawal) pointing at old codes. The first transaction hitting one of those sections in April fails validation. The team scrambles to update the master while a payment is waiting to be processed. Partial updates are more dangerous than no update, because “it worked for the first five transactions” creates false confidence that the migration is complete.
Pattern 2. GL code additions made, but the posting rule is not rewritten
The accounting team adds new GL codes for payment code 1003 TDS payable and payment code 1002 TDS payable. The ERP’s automatic TDS posting rule still routes every TDS debit to the old 194J TDS payable GL. April’s TDS ledger entries sit in old GLs while challans are being filed under new payment codes, creating a reconciliation break between the ledger and the return.
Pattern 3. Correction window closed late
The March 31, 2026 time-bar for FY 2018-19 through FY 2022-23 corrections is a hard deadline. Finance teams that discover an old mismatch after April 1 find that TRACES no longer accepts the correction. The TDS credit for that year becomes non-recoverable. For a mid-size company with regular TDS receivables, this can mean ₹2 to 8 lakh of TDS locked out per forgotten correction year.
The Migration Checklist Step by Step
Step 1. Close time-barred correction windows before March 31
Pull a six-year correction exposure report from TRACES for FY 2018-19 through FY 2022-23. For each year, identify any unmatched TDS credit in your receivable ledger, any challan mismatch still open, and any Form 26AS discrepancy flagged by the tax team or the auditor. File correction statements before close of business on March 31, 2026. Save the TRACES acknowledgment receipts as part of the migration evidence file. This step alone recovers TDS credits that would otherwise be written off.
Step 2. Update the vendor master and chart of accounts
Run a report on every active TDS section code in the ERP. For each, add the new payment code as a parallel field or as a replacement, depending on your ERP’s data model. If the ERP supports effective-dated master data, configure the new payment codes with an effective date of April 1, 2026 and leave old section codes in place with an end date of March 31, 2026. Add new TDS payable GL codes if needed, and document the posting rule change. Test the master update on a single vendor in a test environment before rolling to production.
Step 3. Decommission Section 206AB and 206CCA filters
Sections 206AB and 206CCA are abolished under the Income Tax Act 2025. Any vendor onboarding workflow that screens new vendors for 206AB applicability, any monthly check against the compliance portal, and any vendor master field that stores 206AB status should be switched off effective April 1, 2026. Preserve the historical data as read-only, because correction statements for FY 2025-26 and earlier may still need the higher rate where it applied. The active filter logic can be disabled on the cut-over date.
Step 4. Plan the cut-over weekend
Block two consecutive weekends in March 2026 for cut-over activities: one for rehearsal (mid-March) and one for production cut-over (the weekend before April 1). The rehearsal weekend runs the full update sequence in a test environment with representative transaction data. The production weekend runs the update against live data with a documented rollback plan. The cut-over includes:
- Freezing March 31 closing entries by end of day
- Running the master data update script against production
- Loading the updated FVU validator and testing against a sample Q1 FY 2026-27 return file
- Configuring the reconciliation system in dual mode
- Running an end-to-end test transaction (invoice, challan, return preview)
- Sign-off from finance, tax, and IT representatives before Monday April 1 open
Step 5. Test dual-mode reporting
Dual-mode reporting is the operating state for FY 2026-27 reconciliation. The same source ledger must be able to produce two outputs: a current-period view classified by new payment codes, and a correction-period view classified by old section codes. Test that your reconciliation tool produces both from the same source data without duplicating the underlying entries. If the tool cannot do this, the finance team will end up maintaining two parallel sets of records for three years.
TDS 2026 Migration Task Reference Table
The table below summarises the migration tasks, owners, deadlines, and evidence artifacts.
| Migration Task | Owner | Deadline | Evidence Artifact |
|---|---|---|---|
| File time-barred corrections for FY 2018-19 to FY 2022-23 | Tax team | 31 Mar 2026 | TRACES acknowledgment for each year |
| Update vendor master with new payment codes | ERP / Master data team | 28 Mar 2026 | Master data change report, audit log |
| Add new GL codes and update posting rules | Accounting team | 28 Mar 2026 | Chart of accounts change memo |
| Decommission 206AB / 206CCA active filters | Compliance / IT | 1 Apr 2026 | System change ticket, archive of history |
| Install updated FVU validator for Q1 FY 2026-27 | Tax team | 31 Mar 2026 | Validator version screenshot |
| Configure reconciliation system in dual mode | Finance systems team | 29 Mar 2026 | Configuration export, test run log |
| Run end-to-end cut-over test with sample data | All functional owners | 30 Mar 2026 | Signed cut-over sign-off document |
| Confirm April 7 challan deposit runs under new codes | Treasury / AP team | 7 Apr 2026 | OLTAS challan receipt with new payment code |
| Validate Q1 FY 2026-27 draft return by mid-June | Tax team | 15 Jun 2026 | Draft return FVU pass confirmation |
The table is the project plan. Owners should be named individuals, not departments, and each deadline should be tracked against a go/no-go meeting in late March.
India-Specific Migration Considerations
Three Indian compliance specifics affect how the cut-over should be executed.
Q4 FY 2025-26 return filing straddles the cut-over. Q4 FY 2025-26 returns are due by May 31, 2026 for Form 26Q and 27Q, which means they are prepared and filed in April and May, after the cut-over. These returns must use old section codes because the underlying deductions are under the 1961 Act. The return preparation utility must therefore support both old and new code filing simultaneously from April 1. Confirm with your return preparation software vendor that the update released for April 2026 retains legacy filing capability for prior-period returns.
Form 16A issuance for FY 2025-26. Form 16A certificates for Q4 FY 2025-26 deductions must be issued by June 15, 2026. These certificates carry old section codes because they reference 1961 Act deductions. Any automated certificate generation workflow in the ERP or the TRACES download interface must continue producing Form 16A format (not Form 131 format) for prior-period periods. Finance teams receiving Form 16A in May or June for March deductions should not flag them as out-of-date; they are correct.
Partner remuneration under Section 194T. Section 194T TDS on partner remuneration, introduced by the Finance Act 2024, first applies to FY 2025-26. The first Q4 FY 2025-26 return (filed May 2026) will carry Section 194T under old-era numbering. The first Q1 FY 2026-27 return (filed August 2026) will carry the same payment type under its new payment code. Partnership firms and LLPs should plan for 194T being present in the very first cross-era reconciliation, not a future compliance issue.
Confirm current migration details at the Income Tax India e-filing portal and watch for CBDT circulars in March 2026 covering the final payment code list and updated return utility version.
What Automated Reconciliation Changes During Migration
A reconciliation platform with configurable classification and dual-mode reporting absorbs most of the migration risk above. TransactIG supports three modes (legacy, payment_code, and dual); switching from legacy to dual is a configuration change, so the March 31 cut-over for reconciliation is a matter of flipping a setting rather than rebuilding matching rules. The expanded variance taxonomy includes cross-era codes (TDS_194T, TDS_194O, TDS_194R, TDS_194S, TDS_NR_GENERAL, and others) so exceptions during FY 2026-27 carry a clear classification in the review queue rather than generic “unmatched” labels.
TDS reconciliation software with cross-era capability means the reconciliation step inherits the migration rather than duplicating it. For teams standardising broader compliance work around reconciliation software India, the same dual-mode capability applies to GST IMS, DRC-01B and DRC-01C reply cycles, and other regulatory shifts expected through 2027.
Match rates at Indian enterprises moving from manual spreadsheet TDS reconciliation to structured matching typically climb from about 51% to 88%. A migration completed before April 1 preserves that trajectory through FY 2026-27. A migration that spills into April depresses match rates in Q1 and Q2 until the classification errors are worked through.