TDS on construction payments, explained as a mechanism

Tax deducted at source is a collection mechanism. When one party makes certain kinds of payment to another, the payer withholds a portion and remits it to the government against the recipient's tax account, then pays over the balance.

The recipient has not lost that money. It sits to their credit and is set against their own tax liability when they file. What has changed is the timing and the identity of who hands it over.

This piece is about the mechanism and the errors it generates, not about rates, thresholds or section numbers. Those change, they depend on facts about the payee that only your accountant should be deciding, and getting them from an article is how people end up with demands. Take the numbers from your accountant. Take the shape from here.

Why the mechanism exists#

Collecting tax from a large number of small recipients is difficult. Collecting it from a smaller number of payers who are already keeping books is easier.

So the obligation is placed on the payer. And because the obligation is on the payer, the consequences of getting it wrong land on the payer too — which is the part that surprises people. If you fail to deduct when you should have, the shortfall, and interest on it, is generally recoverable from you, not from the person you paid.

That single fact explains why finance departments are cautious about this to a degree that looks disproportionate from outside.

The four decisions in every deduction#

Each payment requires four questions to be answered, in order, and each has its own failure mode.

Is this payment of a type that attracts deduction? Different categories — contract work, professional services, rent, commission, purchase of goods — have different treatments. Construction organisations pay all of these, often to the same vendor, sometimes on the same invoice.

Who is the payee, in tax terms? The treatment can depend on the legal status of the recipient and on whether they have furnished a valid tax identification. A missing or invalid identifier typically attracts a materially harsher treatment, which is why collecting and verifying it before the first payment matters far more than it seems to at the time.

On what amount? Generally the value of the service, and whether tax charged on the invoice forms part of the base depends on how the invoice is drawn and on the category. An invoice that does not separate the components makes this question harder than it needs to be.

When? Deduction obligations are usually triggered at the earlier of credit in the books or payment. This catches people who assume nothing happens until money moves. A provision made at year end can trigger the obligation without anybody writing a cheque.

Where construction makes it harder#

Mixed invoices. A single bill for material supplied and labour to install it may attract different treatment on different components. If the invoice shows one figure, somebody has to apportion, and an apportionment done by guesswork is a decision made by the least qualified person in the chain.

Running account bills. These are cumulative — each restates the job to date and subtracts what was already certified. Deduction is on this bill's payment, not on the cumulative figure, and a system that applies a percentage to the wrong one over-deducts spectacularly. The cumulative structure is set out in running account bills.

Advances. Money paid before work is done can still trigger an obligation depending on the category and the terms. A mobilisation advance, being a loan rather than a payment for services, may be treated differently from an advance against an order — one more reason to book the two distinctly.

Retention. Money withheld and released later raises a timing question that is easy to get wrong in both directions: deducting twice, or never deducting at all because the release looks like a balance movement rather than a payment.

Set-off. When a payment is netted against a counter-claim, the deduction base is the gross amount, not the net you actually pay. Systems that compute deduction from the payment figure get this wrong every time. It is another reason to record gross and recovery separately rather than paying a net number, which is the argument made in set-off.

The certificate is the point#

The recipient can only claim credit for what has actually been deposited and reported against their identifier. So three things have to happen, not one: deduct, deposit on time, and report correctly in the periodic return.

A deduction that is made but not reported is worse than no deduction at all from the payee's point of view: their money has gone and they cannot claim it. This is a very common cause of vendor disputes, and it is invariably discovered months later when the vendor's own filing does not reconcile.

Two practical consequences:

• The vendor's tax identifier is a critical data field. It should be validated when the vendor is created, not when the first payment is made, and a change to it should be treated as significant rather than as an ordinary edit.
• The mapping from payment to identifier must be exact. Paying one legal entity and reporting against another's identifier produces a credit that lands in the wrong account, and unwinding it is slow.

What a system should and should not do#

It should compute the deduction, using rates held as configuration rather than in code, per category and per payee status. It should show gross, deduction and net separately on every payment record. It should make the deduction reconstructible: which rule was applied, on what base, on what date.

It should not decide the category. That is a judgement about the nature of the work, and a machine which quietly categorises payments is making tax decisions in the dark. The right shape is the one we use for everything of this kind — the system proposes a treatment with its reasoning visible and a person confirms. The argument for that is in the machine proposes, a person decides.

The short version#

Deduction moves a slice of a payment to the government on the payee's behalf, and the obligation — and the liability for getting it wrong — sits with the payer.

Four questions per payment: what type, who is the payee, on what base, and when. Construction complicates all four because of mixed invoices, cumulative bills, advances, retention and set-off.

And the deduction is only half the job. Depositing and reporting it correctly is what turns a withholding into a credit the vendor can actually use.