Section 194-O TDS for Marketplaces: Auto-Deduction Implementation Guide

Quick answer: Section 194-O requires every e-commerce operator in India to deduct 1% TDS on the gross sale value facilitated through its platform for resident sellers, at the time of credit or payment, whichever is earlier. Individual / HUF sellers are exempt up to an aggregate sale threshold of ₹5 lakh in a financial year (subject to PAN being furnished). The TDS is on gross — before platform commission, refunds, or returns. Build it as a ledger-grade subsystem from day one, not as a quarterly Excel exercise.

Section 194-O of the Income Tax Act made every e-commerce operator in India a tax collector on behalf of the government. If you run a marketplace — even a niche vertical one — you are responsible for deducting tax at source on the gross sales of every participating seller, remitting it to the exchequer, and issuing the TDS certificates. Most marketplaces underestimate the implementation lift until the first quarterly remittance lands.

What “e-commerce operator” actually means

The Section uses a broad definition: anyone who owns, operates, or manages a digital or electronic facility or platform for the sale of goods or services. Marketplaces, food-tech apps, ride-hailing platforms, online services aggregators — all fall in. Pure brand-owned D2C sites typically do not (you aren’t an “operator” for third-party sellers; you’re the seller yourself).

What gets deducted, on what amount

Three pieces of gross commonly trip teams up:

1. TDS is on the gross sale value, not the net. If the customer pays ₹1,000 and you remit ₹920 to the seller after a ₹80 commission, the 1% is on ₹1,000 — not ₹920.
2. Returns and refunds. TDS already deducted on a sale that is subsequently refunded becomes a refund adjustment in your TDS workings; it does not unwind automatically.
3. GST. TDS under 194-O is on the gross value inclusive of GST when the consideration includes GST, per the prevailing CBDT clarifications.

Threshold and exemption logic

For seller = individual or HUF with PAN on record, no TDS until aggregate facilitated sales in the financial year cross ₹5 lakh. Once crossed, deduct on the full amount including the previously exempt portion in the year of crossing (subject to the operative CBDT FAQs). For seller = company / partnership / LLP / any non-individual: no threshold; deduct from rupee one.

[VERIFY 2026] Confirm the operative ₹5 lakh threshold and the latest CBDT FAQs on netting / refunds before publishing.

194-O vs 194Q — which applies?

This is the most-asked operator question. 194Q applies to buyers purchasing goods above ₹50 lakh in aggregate from a single seller. 194-O applies to e-commerce operators facilitating sales for sellers. Where both could theoretically apply, the legislative carve-out has historically given priority to 194-O — but the operative rule depends on the specific transaction structure. Document your decision policy and revisit when CBDT clarifies.

How to wire 194-O into your settlement engine

The implementation pattern that works:

1. Capture PAN at seller onboarding — without PAN, the higher TDS rate applies. Make PAN mandatory at onboarding for any seller likely to cross the threshold.
2. Track aggregate facilitated sales per seller per FY in a dedicated ledger. The aggregate is per PAN, not per platform account, so handle multi-account sellers correctly.
3. At each settlement event, compute TDS = 1% of gross sale value where the seller has crossed (or always-deduct for non-individuals).
4. Deduct from the settlement payout, not from the seller’s separate balance.
5. Remit TDS to the government within the prescribed monthly deadline (typically the 7th of the following month, with annual deadline exceptions).
6. Generate Form 26Q quarterly and issue Form 16A certificates to sellers.
7. Reconcile monthly between the ledger, the remittance, and the seller’s TRACES record.

The settlement architecture that handles this cleanly

The clean pattern is a settlement engine where every customer payment ingests as one journal entry and the splits — TDS, GST TCS (if applicable), platform commission, payment gateway fees, refund reserve — are computed and recorded as separate journal entries before the net is credited to the seller’s settlement wallet. This way every TDS line is reconcilable to a transaction, and every quarterly Form 26Q is sourced from a single ledger.

The pattern that breaks: computing TDS at the end of the month as a batch process. You will hit edge cases — refunds, threshold crossings mid-month, multi-payment-method orders — and reconciliation becomes a CFO nightmare.

Common mistakes we see at audit

• TDS computed on net (after commission) instead of gross
• TDS not deducted for sellers without PAN at the higher rate
• Threshold tracking per-platform-account instead of per-PAN
• Returns / refunds handled as TDS reversal instead of as period adjustment
• Form 16A issued late or not at all

CTA: OpenMalo’s payments gateway integration includes a settlement engine that handles 194-O computation, PAN-level aggregation, and Form 26Q generation out of the box. See the module →

Closing

Section 194-O is one of those regulations that looks simple in the bare text (“deduct 1%”) and reveals its complexity in the corners — refunds, GST inclusion, mixed seller types, threshold crossings. Build it as a ledger-grade subsystem from day one, not as a quarterly Excel exercise.