TDS Reconciliation Runbook: Monthly Deposit and Quarterly Form 168 Match for Indian Finance Teams

TDS is the reconciliation stream where a five-day operational slip becomes a Section 200A demand notice with 1 percent monthly interest, and where a quarterly Form 168 mismatch left unresolved for three quarters becomes a permanent write-off. It is also the stream that changes shape most dramatically from 1 April 2026, when the Income-tax Act 2025 shifts the classifier from the legacy Section 194 series to the new Section 393 payment code schedule running 1001 to 1092, and when Form 26AS gives way to Form 168 as the quarterly deductee credit statement. This runbook sequences the TDS window across Days 6 to 10 of the monthly close playbook, with a quarterly Form 168 reconciliation layered on top in June, September, December, and March. It names the roles that run each day, the exact controls at each gate, and the exception categories that separate a clean sign-off from a Section 200A cascade.

Where the TDS window sits in the twenty-day cycle

The pillar reconciliation playbook sequences four streams across the monthly close — bank Days 1 to 5, TDS Days 6 to 10, GSTR-2B input tax credit Days 11 to 15, and GSTR-1 versus GSTR-3B assembly Days 16 to 20. Each stream ends with a sign-off gate; the next stream does not begin until the previous one is closed or its exceptions have a named owner and an aging rule. The TDS window is the second gate because the challan deposit is due on the 7th of the following month under Rule 30, and because the TDS receivable ledger built through Day 9 becomes an input to the Table 6 payment reconciliation in the GSTR-3B assembly on Day 18.

The design pattern is that no stream is calculated for the first time on the day it is filed. The challan is prepared against a Day 6 ledger that has already been extracted, classified, and closed. The receivable match on Day 9 runs against a bank window that has already been signed off on Day 5. The quarterly Form 168 reconciliation runs against a receivable ledger that has been closed month by month across the quarter. Compression collapses the working papers into a single last-day exercise; the runbook prevents the compression.

The relationship between the runbook and its design layer is bidirectional. This document sequences the operational cadence; the TDS reconciliation failure modes article documents the specific failure surfaces each day of the sequence is designed to catch. Read as a pair, the sequence tells the tax executive what to do on Monday morning; the failure modes tell the tax manager why each step exists.

Owner map and preconditions

Owner. The tax executive runs the TDS reconciliation across Days 6 to 10. The tax manager reviews the Day 8 challan-to-ERP match, reviews the Day 9 receivable ledger reconciliation, and signs off the Day 10 exception queue. The controller does not run the TDS window unless a Severity 9 or higher exception surfaces — cross-era code confusion above the tolerance threshold, a large Circular 23/2017 excess-deduction claim, or a Section 206AA higher-rate scenario spanning multiple deductors.

Preconditions. The bank window (Days 1 to 5) must be signed off. The TDS-net customer receipts pre-populated on Day 3 must be tagged in the receivable ledger. The ERP TDS payable ledger must be up to date through the last working day of the month. The Section 393 payment code reference table must be at the current published version. The cross-era mapping table — Section 194C to 1002, Section 194J to 1005 to 1008, Section 194H to 1017, Section 194I to 1019, and so on — must be at the current version and reviewed within the previous month. Every deductor and deductee PAN referenced in the ledger must have a validation status timestamp within the last quarter under Section 206AA.

Day 6 — Extract the ledgers and classify to Section 393 payment codes

The tax executive extracts two ledgers from the ERP on the morning of Day 6. The TDS payable ledger carries every deduction the entity made in the month against a vendor payment, a professional fee, a rent settlement, a commission accrual, or a contractor invoice. The TDS receivable ledger carries every deduction a customer made against a payment the entity was due to receive.

Every line on both ledgers gets classified against the Section 393 payment code schedule. Code 1001 is salary under Section 392 — most non-salary lines will not land here. Codes 1002 to 1092 cover the non-salary Section 393 universe: 1002 for contractor payments to bodies corporate, 1003 for contractor payments to individuals and HUFs, 1005 to 1008 for the professional and technical services successor codes to Section 194J, 1017 for commission successor to Section 194H, 1019 for rent successor to Section 194I, 1021 for interest successor to Section 194A. The full mapping is in the Section 393 payment code reference article. Code 1094 is tax collection at source under Section 394 — retail and marketplace transactions where the entity is the collector.

FY 2025-26 residuals still carry the legacy Section 194 codes. A March 2026 professional-services invoice paid in April 2026 belongs under Section 194J at the legacy rate, not under codes 1005 to 1008 at the successor rate. The tax executive runs the two-key discipline throughout — payment code for FY 2026-27 lines, legacy section code for FY 2025-26 residuals — and carries both fields on the ledger for at least four full quarters after the transition to keep the correction workflow open. The cross-era reconciliation article documents the specific mismatch patterns and the reference table shape.

Day 6 closes with a signed ledger on both sides. Every deduction traceable to a payment code (or a residual legacy section), every deduction traceable to a deductor or deductee PAN with a current validation status, every deduction traceable to an invoice or a settlement in the underlying source system. The tax executive signs the working paper; the tax manager will review the challan and the classification together on Day 8, not on Day 6.

Day 7 — Prepare and deposit the challan against the 7th deadline

The statutory challan deposit deadline is the 7th of the month following the month of deduction (30th of April for March deductions, per Rule 30(2) proviso). Running the extraction on Day 6 and the deposit on Day 7 provides no operational buffer against a portal outage, a bank-side settlement lag, or a last-minute correction. Teams that prefer a buffer run the extraction on Day 5 (in the bank window’s last hours) and the deposit on Day 6, using Day 7 as a portal-issue reserve. Either sequence works as long as the gate discipline is preserved.

The challan is prepared as one deposit per payment code section — the challan schema requires the deductor to specify which Section 393 code(s) the deposit covers. Small entities may consolidate into a single challan across multiple codes if the deposit portal permits; large entities typically file separate challans per major code to keep the downstream reconciliation clean.

The Challan Identification Number, or CIN, is the primary key for the TRACES match in Days 8 and 9. It is a three-part identifier — BSR code of the bank branch, date of deposit, and challan serial number — that appears on both the deposit acknowledgement and the eventual TRACES challan status query response. The tax executive records the CIN on the working paper against every payment-code total, and the CIN becomes the primary field on the Day 8 reconciliation. A challan without a captured CIN is a challan whose reconciliation is not defensible under Section 200A processing.

Day 8 — Match the deposited challan against the ERP TDS payable ledger

Day 8 is where short-deduction, wrong-section, and wrong-payment-code entries surface. The tax executive runs the CIN against the ERP TDS payable ledger, sums the deductions per payment code, and reconciles the sum against the challan amount for that code. Any variance is investigated on the same day.

Three variance patterns are the common ones. First, short deduction — the ERP calculated the deduction at the correct rate but the challan deposit was short of the ledger total. Second, wrong section — the ERP posted a manpower supply invoice against a professional services code (1005) when it should have posted against a contractor code (1002). Third, wrong payment code — the ERP is on a stale reference table and posted the deduction against a code that was superseded in the current published version. Each variance requires a specific correction. Short deposit is fixed by filing a supplementary challan and updating the working paper. Wrong section or wrong code is fixed by filing a correction statement under Section 154 read with Section 200A — the correction workflow is faster than the demand-and-response cycle, and the TDS correction statement article walks through the mechanics for the FY 2025-26 correction deadline running to 31 March 2026.

The tax manager reviews the Day 8 match at the end of the day. Any un-cleared variance carries into Day 9 with a named owner and a target close date. Carrying a variance beyond the current TDS window without a resolution date is the mechanism by which small-value discrepancies become audit findings — the receivable ledger builds a rolling drift that no one has time to unwind by Q4.

Day 9 — Match the TDS receivable ledger against the customer bank credits pre-populated on Day 3

Day 9 shifts to the receivable side. Every TDS-net customer receipt in the month — the customer paid the invoice net of a deduction claimed under Section 393(1)(b) contractor, Section 393(1)(l) commission, Section 393(1)(m) fees for professional or technical services, or another applicable payment code — must produce a matching receivable entry on the ledger. The bank credits carry the net receipt; the receivable is booked for the gross amount less the net; the two together are the trace back to the invoice.

The Day 3 pre-population is what makes Day 9 tractable. The AR analyst has already tagged the TDS-net receipts against the invoice-with-TDS pattern and pre-populated the receivable ledger with the expected credit and the customer’s PAN. Day 9 is a confirmation exercise, not a discovery exercise — the tax executive runs the confirmation against the ERP receivable ledger and flags any customer receipt where the net-of-TDS credit does not carry a matching receivable line.

The Day 9 confirmation is also the point where the quarterly Form 168 reconciliation begins to build up. Each customer TDS-net receipt is expected to appear on the customer’s Form 168 filing within thirty days of the quarter end. The receivable ledger accumulated month by month across the quarter is the base against which the third-month Form 168 match will run. See the Form 168 article for the notified schema and the TRACES portal reconciliation article for the pull mechanics.

Day 10 — Close the window with a categorised exception queue

Day 10 is exception categorisation and sign-off. Every TDS receivable open on the ledger beyond the current window without matching Form 168 credit falls into one of four named categories, each with a documented owner and a next action.

Awaiting Form 168 posting. The receipt is confirmed, the deductor has confirmed the deduction, and the deductor’s quarterly return has not yet posted on TRACES. The aging clock starts on Day 10 and runs against the 30-day expected Form 168 processing window post quarter-end. The tax executive holds the item and re-checks on the next quarterly reconciliation.

Deductor short-deducted. The customer has deposited a smaller TDS amount than the receivable entitles the entity to. The next action is a written request to the deductor for a corrected challan or an interim certificate under the correction workflow. The escalation ladder is the pillar playbook standard — 30 days to the tax manager, 60 days to the controller, 90 days to the CFO with a write-off proposal. See the TDS credit recovery article for the recovery mechanics.

Section 206AA higher-rate deduction due to PAN mismatch. The deductor deducted at 20 percent because the deductee’s PAN did not validate against the Income Tax Department’s PAN database at the time of deduction. The next action is a PAN correction request to the deductor and a supplementary challan under the correction workflow. The exception is often traceable to a stale PAN validation status; the PAN validation article documents the refresh cadence.

Circular 23/2017 violation. The deductor deducted on the GST-inclusive amount rather than on the value exclusive of GST — a common vendor error covered by Circular 23/2017. The excess deduction is a refund reconciliation against the deductor, not an automatic setoff on the receivable ledger.

The tax manager reviews all four categories at the end of Day 10 and signs off the exception queue. The sign-off is the gate that opens the GSTR-2B input tax credit window on Day 11. No item leaves Day 10 without a category, a named owner, an aging clock, and a next action.

Quarterly emphasis — the Form 168 layer in June, September, December, and March

In the third month of every quarter, the Days 6 to 10 window absorbs an additional half day for the Form 168 reconciliation against the quarterly-accumulated TDS receivable ledger. The pull happens once the CBDT-notified Form 168 processing window for the previous quarter has closed and the TRACES account carries the deductor filings for the quarter.

The tax executive pulls the Form 168 from every material deductor’s TRACES-linked feed on the entity’s account, keys the credits by deductor PAN and by payment code, and matches against the receivable ledger accumulated across the three months. Every receivable line falls into one of five buckets — fully credited on Form 168; partially credited; not credited but supported by an interim Form 131 certificate; not credited and unsupported; or credited but not booked on the receivable ledger (a rare case suggesting the entity missed the TDS-net tag on the Day 3 bank window).

Every unsupported item enters the 180-day maximum-open aging queue. The 180-day rule is a specific ceiling — no receivable can age past 180 days without either a Form 168 credit, an interim Form 131 certificate, or a controller-approved provision. The rule is deliberately shorter than the statutory correction window because the reconciliation break the finance team lives with is the receivable ledger that carries phantom credits into the annual filing and cannot be defended when the assessing officer runs the Section 143(3) query.

For FY 2025-26 quarters still in the correction window, the Form 168 pull is preceded by a Form 26AS pull for the residual quarters, and the two-key match discipline holds — Form 168 credit by payment code first, Form 26AS credit by legacy section code second. The cross-era reconciliation article documents the residual patterns; the TDS credit recovery article covers the recovery mechanics for both statements.

The escalation ladder and the exception clock

Every exception category has an aging clock and an escalation ladder anchored to the pillar playbook. The clock runs on calendar days, not on reconciliation-cycle days — an item that entered the Day 10 queue on the 10th of April escalates on the 10th of May, the 10th of June, the 10th of July, regardless of which reconciliation cycle is running.

The 30-day tier escalates to the tax manager. A standard follow-up letter goes out to the deductor. The working paper is updated with the escalation date and the follow-up reference. The 60-day tier escalates to the controller. A second follow-up letter goes out, and the counterparty’s key account owner (typically the sales owner for AR-side deductor items) is looped in. The 90-day tier escalates to the CFO. A write-off proposal or an interim provision is prepared. For very-large-deductor items where the credit is confirmed but the Form 168 posting is delayed, the CFO decision is often to hold rather than write off, with a documented rationale.

For Section 206AA higher-rate deductions and Circular 23/2017 violations, the escalation calendar is compressed because both categories carry a shorter economic recovery window — the higher-rate excess is a real cash outflow that the deductee is trying to recover, and the GST-inclusive excess is a refund reconciliation with a limited claim window. The tax manager holds these two categories on a 15-day escalation to the controller rather than the standard 30.

Where manual detection tops out

The runbook works for a finance team running a receivable ledger of a few hundred deductor entries and a payable ledger of a few thousand payment lines a month. Above that, three specific manual controls break, and the TDS reconciliation failure modes article rates each as a High Action Priority mode above the manual tolerance threshold.

Cross-era matching under two-key logic. Running the Section 393 payment code first, then the legacy Section 194 code, across three financial years while the March 31 2026 correction deadline closes on FY 2025-26 residuals, produces a workload that no manual spreadsheet holds cleanly at scale. The residuals age silently, and the receivable ledger carries a rolling drift that surfaces only when the assessing officer queries the annual filing.

PAN validation refresh under Section 206AA. Keeping every deductor and every deductee PAN validated against the Income Tax Department’s PAN database on a quarterly cadence, with a documented status timestamp on every row, is a workload that outpaces a spreadsheet the moment the deductee or deductor count crosses a low three-digit threshold. The higher-rate deduction exceptions cluster around the stale validations, and the runbook itself cannot detect the stale status without the refresh cadence.

Quarterly Form 168 reconciliation against a thousand-line receivable ledger. Running the five-way categorisation, the 180-day aging queue, the per-deductor follow-up, and the deductor short-deduction correction workflow across a large receivable base — quarter after quarter — is where the manual tax team runs out of hours. The exception queue rolls forward, and the audit committee item lives in perpetuity.

The response is not to accept these failure modes — the Action Priority table above the tolerance threshold forbids that when the severity anchor is a Section 200A demand or a permanent write-off. The response is to install a continuously refreshed detection layer that runs the cross-era two-key logic, the PAN validation refresh, and the Form 168 reconciliation as an automated aging queue with escalation triggers. Terra Insight’s TransactIG delivers this detection surface as the queue the runbook otherwise cannot maintain.

Where this fits

• TransactIG — reconciliation infrastructure
• Reconciliation software India — pillar guide
• TDS reconciliation software
• GST reconciliation software

Related reading

• The Reconciliation Playbook — the twenty-day monthly close pillar
• TDS reconciliation failure modes — the design layer above this runbook
• Form 168 — the new quarterly TDS statement
• Section 393 payment codes 1001 to 1092
• Cross-era TDS reconciliation
• TDS compliance calendar
• TDS correction statement — March 2026 deadline
• TRACES portal reconciliation
• TDS PAN validation mismatch
• TDS on GST component — Circular 23/2017

Frequently Asked Questions

Why is the TDS window sequenced Days 6 to 10 rather than around the 7th deposit deadline itself?

The 7th of the following month is the challan deposit deadline under Rule 30 of the Income-tax Rules. Running the deposit on Day 7 without an upstream extraction and downstream reconciliation window is what produces the demand notice cascade under Section 200A three quarters later. Day 6 is the extraction and payment-code classification day for the tax executive — every payment in the month above the deduction threshold gets keyed to a Section 393 payment code between 1002 and 1092, and the TDS payable ledger is closed. Day 7 is the challan preparation and deposit day, run against the closed ledger and the CIN captured on the working paper. Day 8 is the challan-to-ERP match — every short deduction, wrong-section entry, or wrong payment code surfaces here, and the correction is filed under Section 154 read with Section 200A before the quarterly return is furnished. Day 9 is the TDS receivable side — the customer bank credits pre-populated on Day 3 of the bank window are matched against the receivable ledger, building the quarterly Form 168 reconciliation base. Day 10 is exception categorisation and sign-off by the tax manager. Compressing the sequence into a single day around the 7th collapses the correction window into the demand-response cycle, which is the expensive path.

What changes in the TDS runbook for FY 2026-27 under the Income-tax Act 2025?

Three changes carry through every day of the TDS window. First, the payment code replaces the section code as the primary classifier on the challan and on the ERP TDS payable ledger. Every non-salary deduction takes a code in the range 1002 to 1092, and the mapping between the legacy Section 194 series and the new codes must be maintained as a versioned reference table. Second, Form 168 replaces Form 26AS and Form 26Q as the quarterly TDS statement, and the deductee’s TRACES account carries the Form 168 credit within thirty days of the quarter end. The Day 9 receivable reconciliation and the quarterly Form 168 match run against Form 168 for FY 2026-27 quarters onwards. Third, any TDS receivable belonging to FY 2025-26 or earlier still carries the legacy Section 194x code, and the receivable ledger must run two-key match logic — try the payment code first, then the legacy section code — across three financial years while the correction windows for the older years close. This cross-era matching layer is the single largest source of reconciliation drift under the new regime, and the reason the tax manager review on Day 10 is a hard gate rather than a courtesy check.

How does the quarterly Form 168 match layer onto the monthly five-day window?

In the third month of every quarter — June, September, December, and March — the Days 6 to 10 window absorbs an additional half day for the quarterly Form 168 reconciliation against the deductee TDS receivable ledger. The tax executive pulls the Form 168 from the deductee’s TRACES account, keys the credits by deductor PAN and by payment code, and matches against the receivable ledger accumulated across the three months of the quarter. Every receivable line falls into one of four buckets — fully credited on Form 168, partially credited, not credited but supported by an interim certificate or a signed follow-up from the deductor, or not credited and not supported. The unsupported bucket enters the 180-day maximum-open aging queue and escalates to the tax manager on the 30-day tier, the controller on the 60-day tier, and the CFO with a write-off proposal on the 90-day tier. Without the quarterly overlay, the receivable balance rolls forward into the year-end and becomes an audit finding on the annual filing — the receivable is real but the evidence is not.

What does the Day 10 exception queue look like at the end of a clean TDS window?

The Day 10 queue carries four named categories, each with a documented owner and a documented next action. The first category is awaiting Form 168 posting — the receipt is real, the deductor has confirmed the deduction, but the deductor’s quarterly return has not yet been processed on TRACES. Owner is the deductor’s finance team; next action is a follow-up on the deductor’s return filing date. The second category is deductor short-deducted — the deductor has deposited less TDS than the deductee’s contract entitles them to. Owner is the deductor’s finance team; next action is a written request for a corrected certificate under the correction workflow. The third category is Section 206AA higher-rate deduction due to PAN mismatch — the deductor deducted at 20 percent because the deductee’s PAN did not validate against the Income Tax Department’s PAN database at the time of deduction. Owner is the deductee; next action is a PAN correction request to the deductor and a fresh challan file under the correction workflow. The fourth category is Circular 23/2017 violation — the deductor deducted on the GST-inclusive amount rather than on the value exclusive of GST. Owner is the deductee; next action is a refund reconciliation request against the excess deduction. Every category has an aging clock, and every clock feeds the escalation ladder in the pillar playbook.

When does the manual TDS runbook stop being economically viable?

The runbook holds for a finance team running the cycle against a receivable ledger of a few hundred deductor entries and a TDS payable ledger of a few thousand payment lines a month. Above that, three specific manual controls break. First, the cross-era matching layer running two-key logic against Section 393 payment codes and legacy Section 194 codes across three financial years, refreshed daily as deductors file returns at different cadences, consumes disproportionate analyst time and produces silent misses. Second, the PAN validation refresh under Section 206AA against the Income Tax Department’s PAN database, keyed to every deductor and every deductee for every quarter, produces a validation queue that cannot be run manually at group-controller scale. Third, the quarterly Form 168 reconciliation against a receivable ledger of a few thousand lines with 180-day aging escalation and per-deductor follow-up cannot economically be run out of a spreadsheet without the exception queue rolling forward as an audit-committee item. This is the failure mode surface documented in the TDS reconciliation failure modes article — every mode rated Severity 9 or 10 above the manual threshold routes to a continuously refreshed detection layer, which is where Terra Insight’s TDS reconciliation software fits.

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published Invalid Date

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024