Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
A single TDS credit download now mixes 194-series section codes and Section 393 payment codes, and many tools re-map or merge them silently.
Run six fixed cases covering dual classification, legacy certificates, quarter drift, old-code corrections, partial credit and PAN or TAN changes, each with a stated expected output.
A decision table of case, input, expected output and red flag, signed off by the tax head and repeated each April.
Evidence of whether a tool keeps both eras on one receivable with an era flag and a reason code, before you sign.
From April 2026, a TDS credit download can carry old section codes (194C, 194J) and new Income-tax Act, 2025 payment codes (1001 to 1092) side by side. A tool passes this test only if both land on the same receivable, keep an era flag and need no manual re-mapping. Hand the vendor these six cases and compare the output to the expected result.
Background on how the two eras interact is in cross-era TDS reconciliation and the payment code table.
Which cases test dual classification?
Case 1: one vendor, two classifications in one quarter boundary. A customer pays your professional fees. The March 2026 invoice is deducted under Section 194J at 10 percent; the May 2026 invoice is deducted under payment code 1027 at the same 10 percent. Expected result: both lines link to the same customer and the same receivable account, with the old section and new code each shown against its own invoice.
Case 2: a legacy certificate arrives late. For the March invoice, the customer issues a Form 16A after you have already received a Form 131 for May. Expected result: the Form 16A attaches to the March invoice, not the May one, and the tool does not ask you to re-key the section.
Which cases test timing and corrections?
Case 3: quarter drift. The customer deducts in Q4 of FY 2025-26 but its return reports the deduction in a later quarter. Expected result: a labelled timing item (“credit in later quarter”), not an open mismatch and not a write-off.
Case 4: a correction statement with old codes. In August 2026 the customer files a correction for a February 2026 deduction. The corrected line still carries 194C because the deduction pre-dates April 2026. Expected result: the tool accepts the old code in a 2026 file and updates the original line, keeping its history.
Which cases test partial credit and identity changes?
Case 5: partial credit. Your book shows ₹50,000 TDS on a ₹5,00,000 invoice; the credit statement shows ₹30,000. Expected result: ₹30,000 matched, ₹20,000 open with a reason (“credit lower than books”) and a follow-up status.
Case 6: PAN or TAN change mid-year. A customer restructures and starts deducting under a new TAN from July 2026. Expected result: the tool lets you link both TANs to one customer without losing the old history, and flags lines where the wrong TAN or your PAN was quoted.
What does the scoring table look like?
| Case | What to give the vendor | What a pass looks like | Red flag |
|---|---|---|---|
| 1 Dual classification | March 194J and May code 1027 invoices for one customer | One receivable, two era-labelled lines | Codes merged or one era dropped |
| 2 Late Form 16A | Form 16A for March after Form 131 for May | Certificate attached to the March invoice | Manual re-mapping needed |
| 3 Quarter drift | Deduction in Q4, credit in a later quarter | Timing item with reason | Shown as unmatched or written off |
| 4 Old-code correction | 2026 correction line carrying 194C | Original line updated, history kept | File rejected for old code |
| 5 Partial credit | ₹50,000 booked, ₹30,000 credited | ₹20,000 open with reason and status | Whole line shown unmatched |
| 6 TAN change | Two TANs for one customer | Both linked, wrong-TAN lines flagged | History lost on new TAN |
The tax head signs off the expected outputs before the demo, so nobody adjusts the answer key after seeing a result.
How do you prepare the test data?
Build the six cases from your own records where you can, and invent the rest with realistic values. A practical pack:
- Pick one customer that deducts under Section 194J and has invoices in both March 2026 and May 2026. Copy the two ledger lines and the matching credit statement lines.
- Pick one contractor-type customer deducting under Section 194C at 2 percent (code 1024 from April 2026) for Case 4, and draft a correction line dated August 2026 that still carries 194C.
- For Case 5, take any invoice of ₹5,00,000 with 10 percent TDS booked and edit the credit line down to ₹30,000.
- For Case 6, create a second TAN for one customer from July 2026.
Write the expected output for each case in one sentence before the vendor sees the data, and keep the file with the tax head. Anonymise customer names and PANs if your policy requires it, but keep the PAN and TAN structure valid, because some tools reject malformed identifiers and you want to test matching, not input validation. Hand over the whole pack at once; a vendor who asks to receive cases one at a time may be configuring per case.
How long does this test stay useful?
For years. Correction statements for old-era deductions can arrive well after April 2026, so 194-series codes will keep appearing next to Section 393 codes. Re-run the script each April and on any vendor release that touches forms or codes. For how a vendor should absorb the next change, see eight questions on rule-change handling; for rate changes inside a year, see TDS rate by date.
How Terra Insight fits
TransactIG’s TDS reconciliation reconciles Form 26AS, Form 168 and AIS against your TDS receivable ledger and routes unexplained lines to an exception queue with audit-ready exports. Bring these six cases to a representative-sample fit benchmark, and ask in discovery how rule changes reach your configuration.