TDS Payment Code List 2026: Every 4-Digit Code Mapped to Its Old Section

If you have paid a TDS challan since 1 April 2026, you have already met the change: the familiar section reference is gone. Where a challan once read 194C or 194J, it now carries a four-digit payment code such as 1023 or 1027, and the section is stated under the Income Tax Act, 2025 as 392, 393 or 394 rather than the 194-series you have used for years.

This is not cosmetic. The code is what the return-filing utility validates against, so quoting an old section number for a payment made on or after 1 April 2026 produces a validation error rather than a helpful warning. For anyone reconciling challans against books or Form 26Q, it also means the join key has changed mid-year: challans paid before April 2026 carry a Nature of Payment code, and challans paid after carry a numeric one.

The table below is the complete mapping, grouped by the provision each code now sits under. It is generated from the same data our converter uses internally, so what you read here is exactly what the tool writes into your reconciliation sheet.

What actually changed on the challan

Three things changed at once, which is why the transition catches people out.

1. Section numbers became payment codes. The 194-series was consolidated into sections 392 (salary), 393 (all other deductions) and 394 (TCS), with a four-digit code identifying the specific nature of payment.
2. One challan can now carry many payments. The old ITNS 281 challan recorded a single Nature of Payment. The new ITNS 281N carries a section-wise table, so a single challan may settle a dozen different codes at once.
3. The challan itself was renamed. Receipts now print ITNS No. 281N rather than 281, which is the quickest way to tell which format you are holding.

Complete TDS and TCS payment code list (FY 2026-27)

Rates shown are the headline rates where the payee has furnished a valid PAN; higher rates apply for non-furnishing and for non-filers, and thresholds are not reproduced here. Always confirm against the provision before relying on a rate for a deduction decision.

Salary — Section 392

Payments to Residents — Section 393(1)

Payments to Non-Residents — Section 393(2)

Winnings, Cash Withdrawals & Partner Payouts — Section 393(3)

Tax Collected at Source (TCS) — Section 394

Reverse lookup: from the section you know to the code you need

Most practitioners approach this from the other direction — you know you are deducting under 194J and need the code that belongs on the challan. This table inverts the mapping. Where a section lists more than one code, pick by the nature of the payee or payment described in the main table above.

Where this bites during reconciliation

The practical difficulty is rarely looking up a single code. It is that a quarter's challans now arrive in two shapes at once, and a single ITNS 281N challan expands into several rows of a working sheet rather than one.

• Mixed formats in one period. Challans for deductions made before April 2026 and paid after will still be legacy ITNS 281, so most FY 2026-27 workings contain both formats.
• One challan, many rows. A challan settling eight codes needs eight rows in a reconciliation sheet, each tying back to the same CIN, BSR code and deposit date.
• Interest and fees sit outside the section table. Interest, penalty and late-filing fee appear only in the tax breakup, not against any payment code, so they need their own line or they silently disappear from section-wise totals.
• Fee section renumbered. The late-filing fee formerly under section 234E is now section 427, and challans may print either label depending on the format.

A note on accuracy

Code lists circulating informally contain errors, and we found several while building this one — codes 1072 and 1074 are frequently published as 206C(1F) and 206C(1G), when both are in fact 206C(1); 206C(1F) actually spans 1075 to 1085 (motor vehicles through racehorses), and 206C(1G) covers 1086 to 1089. Because this table is generated from the same source our converter uses, and a test asserts the two agree on every single code, a correction here cannot silently fail to reach the tool.