Why TDS Compliance Has an Auditability Problem and Why Nobody Is Talking About It?

Why TDS Compliance Has an Auditability Problem – And Why Nobody Is Talking About It

Summary: The content highlights challenges faced by companies in responding to tax notices questioning TDS decisions, particularly under evolving compliance requirements. While enterprise systems record transaction outcomes such as amount, section, and rate, they do not capture the reasoning behind those decisions. With increased scrutiny and complexity in TDS provisions, authorities now require justification for why a specific rate or section was applied. Key gaps include absence of records on decision logic, historical vendor classification, year-to-date thresholds at the time of payment, PAN status at the relevant date, and applicable legal provisions. As a result, companies must reconstruct responses manually using fragmented data, making the process time-consuming and prone to error. The problem is intensifying due to higher transaction volumes, regulatory changes, and data-driven scrutiny. The content concludes that true auditability requires systems that record decision-making elements at the time of transaction, enabling retrieval of explanations rather than post-facto reconstruction.

## The Notice That Changes Everything

It arrives as a PDF. Formal language. Section 201 of the Income Tax Act. The IT department is questioning a TDS deduction from eight months ago on a vendor payment.

The question is simple: why was 2% applied on this transaction and not 1%?

Your finance team opens the ERP. They find the transaction. Amount deducted — correct. Section applied — 194C. Rate — 2%. Vendor PAN — present. Challan number — there.

Everything looks right. But the IT department is not asking what was deducted. They are asking why.

And that answer — the why — is not in the ERP.

## What ERPs Were Built to Do

ERPs are outcome recorders. They were designed to capture the result of a financial decision — what amount was processed, against which vendor, under which section, on which date.

This was sufficient for decades because compliance verification was largely outcome-based. Did you deduct? How much? When was it deposited? The answers were in the records.

Income Tax Act 2025 changed this. The 393-series section references, the revised threshold structures, the PAN operativeness requirements under Section 206AB — all of it introduced a level of decision complexity that outcome recording was never designed to handle.

When a notice arrives today, the IT department is not just asking whether TDS was deducted. They are asking whether the correct decision was made at payment time. These are fundamentally different questions.

## The Five Things ERPs Cannot Tell You

When a Section 201 notice arrives and reconstruction begins, finance teams consistently find five gaps:

1. Why this section over another

The section applied to a transaction is configured in vendor master. When the configuration was set — months or years ago — the logic behind the choice lived in someone’s head, or in an email chain, or in a CA’s recommendation. It was never stored against the transaction itself. When IT asks why 194C was applied instead of 194J for a particular vendor, the answer requires going back to the original configuration decision. That person may have left the company.

2. Why this rate given the deductee type

194C applies at 1% for individuals and HUFs, 2% for companies. The rate depends on deductee classification at payment time. If the classification in vendor master was updated after the payment — even for legitimate reasons — the ERP will show the current classification, not the one that was active on the payment date. The historical rate decision cannot be verified from current master data.

3. What the YTD aggregate was at exact payment time

Threshold-based sections like 194C, 194H, and 194J require tracking year-to-date aggregate per vendor. Whether TDS applies on a given payment depends on whether the cumulative aggregate has crossed the annual threshold. ERPs can show current YTD balance. They cannot show what the YTD balance was at the moment of a specific historical payment. That snapshot — the one that determined whether TDS was applicable — was never stored.

4. What PAN status was at payment date

Section 206AA and 206AB require higher TDS rates when PAN is unavailable or inoperative. PAN status is read from vendor master at payment time. If PAN status has changed since the payment — operative to inoperative, or the reverse — the current master data will not reflect what was true on the payment date. The rate applied may have been correct at payment time but cannot be verified from current records.

5. Which rule version was in effect

Tax rates, thresholds, and section references change with each Finance Act. A payment made in December 2025 was governed by rules that may differ from those in effect today. Without a record of which rule version was active at calculation time, it is impossible to prove that the rate applied was correct under the law as it stood on that date.

## The Reconstruction Problem

When a notice arrives, the 30-day response window begins. Finance teams spend a significant portion of that window not writing the response — but reconstructing the information needed to write it.

This reconstruction process is manual, time-consuming, and error-prone. It involves:

– Checking vendor master history (if the ERP maintains it)

– Reviewing emails and CA correspondence from around the payment date

– Cross-referencing Finance Act provisions that were active at the time

– Manually recalculating whether thresholds had crossed based on payment history

– Verifying PAN status through TRACES records

For a single notice on a single transaction, this might take two to three days. For a notice covering multiple transactions across a financial year — which is common — it can take weeks.

The outcome is a response that is reconstructed rather than retrieved. It answers the IT department’s question with information assembled after the fact, not information recorded at the time of the decision.

This distinction matters. A reconstructed response is inherently weaker than a retrieved one. It introduces the possibility of error, inconsistency, and gaps. It is also significantly more expensive in terms of CA time.

## Why This Problem Is Growing

Three developments are making the reconstruction problem more acute:

Volume of payments is increasing. Fintechs, gig platforms, and B2B marketplaces are processing vendor payments at a scale that was rare five years ago. A lending fintech might process 194A interest payments to thousands of borrowers. A gig platform might make 194C contractor payments to tens of thousands of workers. Each payment is a potential notice trigger. The reconstruction problem scales with payment volume.

Income Tax Act 2025 introduced complexity. The new Act reorganised TDS provisions under 393-series references, revised threshold structures, and expanded the scope of Section 206AB applicability. Companies that were compliant under the old Act need to verify that their systems reflect the new Act correctly — and that they can prove which version of the rules applied to historical payments.

IT department scrutiny is increasing. The combination of higher TDS collections targets and improved data analytics capability at the IT department level means that mismatches are being identified more quickly and more precisely. The days when a broadly reasonable response was sufficient are ending. Notices are increasingly specific about which transaction, which rate, which date.

## What Auditability Actually Requires

True TDS auditability is not about having records. It is about having the right records — specifically, records that capture the decision, not just the outcome.

A genuinely auditable TDS system stores five things per transaction at the moment of calculation:

1. Decision chain — the complete reasoning behind rate and section selection, including which criteria were evaluated and which were determinative

2. Threshold snapshot — the year-to-date aggregate at the exact moment of the payment, not the current balance

3. PAN status as-of — the PAN operative status at calculation time, distinct from current master data

4. Legal reference — the specific provision of the Act that governed the calculation, including the version of the Act in effect

5. Rule fingerprint — a cryptographic identifier for the rule set that was active at calculation time, providing immutable proof of which rates applied

When these five elements are stored per transaction at calculation time, notice response changes from reconstruction to retrieval. The question “why was 2% applied?” is answered not by assembling information after the fact — but by pulling the decision chain that was stored at the moment the calculation was made.

## The Infrastructure Question

The gap between outcome recording and decision recording is not a configuration problem. ERPs can be configured to store more data. But storing the decision chain for a TDS calculation requires something ERPs were not designed to do — run calculation logic at payment time, capture the intermediate reasoning steps, and store them as immutable records alongside the transaction.

This is a reasoning infrastructure problem. It requires a system that:

– Runs TDS calculation logic according to the current version of the Act

– Captures the complete decision path — not just the output

– Stores that decision path immutably against the transaction

– Makes it queryable per vendor, per section, per financial year

– Provides it in a format submittable to the IT department

This is what RegInfra is built to do. A TDS API that attaches a complete, immutable decision chain to every calculation — built for Income Tax Act 2025, designed for the auditability requirements of modern compliance.