Businesses with previous-year turnover above ₹50 crore face a ₹5,000-per-day penalty under Section 271DB if any sales channel fails to offer the electronic modes prescribed under Rule 119AA — UPI bank-account, BHIM-UPI QR, and RuPay debit. The gap typically opens on a non-website channel (B2B portal, mobile app, call-centre payment link) where the default payment options were chosen for operational convenience and never reviewed for §269SU compliance. The penalty accrues per day from the date the gap opened, not the date it was discovered — so detection lag is real liability.
The audit logic is a channel-by-channel acceptance matrix. For every sales channel through which the business accepts payment, confirm that all three prescribed modes are (a) configured at the gateway, (b) enabled at the merchant checkout layer, and (c) actually selectable in the customer-facing flow. Any channel that fails any of the three tests is a §271DB exposure. Quantify exposure as ₹5,000 multiplied by the number of days since the prescribed mode was last verified as available on that channel.
Channel-acceptance matrix per sales surface (website, mobile app, B2B portal, in-store POS, IVR, payment link), prescribed-mode flag per channel for UPI bank-account / UPI QR / RuPay debit, last-verified-date per channel-mode cell, daily-penalty accrual schedule, and evidence-archive policy keyed to quarterly checkout audits.
Section 271DB exposure schedule with per-channel days-of-non-compliance and rupee penalty; rectification action list with owner, gateway change-request reference and target-restore date; auditor-ready evidence pack of checkout screenshots and gateway configuration logs per channel.
A controller at a ₹120 crore D2C apparel brand pulls a sample of recent orders to verify GST output liability and notices something incidental — the B2B portal that the brand’s wholesale buyers use only accepts RTGS and NEFT. No UPI option is visible. He thinks of it as a customer-experience issue and then realises, with a colder feeling, that the business is above the ₹50 crore turnover threshold and the absence of UPI on that channel is not just operationally awkward — it is a Section 271DB exposure that has been accruing at ₹5,000 a day since the channel went live. The right question for any finance team in this position is not “do we accept UPI?” but “do we accept the prescribed e-modes on every channel through which we accept payment, and what is the audit evidence?”
Quick reference
| Aspect | Detail |
|---|---|
| Statute | Income-tax Act 1961, Section 271DB |
| Linked mandate | Income-tax Act §269SU + Rule 119AA |
| Prescribed e-modes | UPI bank-account, BHIM-UPI QR, RuPay debit card |
| Turnover threshold | Above ₹50 crore in immediately preceding previous year |
| Penalty rate | ₹5,000 per day of failure |
| Effective from | 1 February 2020 (per CBDT Circular 32/2019) |
| Levying authority | Joint Commissioner of Income-tax |
| Statutory defence | ”Good and sufficient reasons” for failure |
| Regulator / network | CBDT, NPCI, RBI |
| Network MDR on UPI / RuPay debit | 0% (zero-MDR mandate) |
| GST on gateway fee | 18% of platform fee only |
Zero-MDR on UPI P2M is current law as of June 2026 but under active review — the Parliamentary Standing Committee on Finance (report tabled 12 March 2026) and the Payments Council of India have proposed tiered/30 bps MDR for large merchants; no binding RBI/CBDT notification yet.
The mandate to offer prescribed e-modes under §269SU and the penalty for failing to do so under §271DB sit on top of the zero-MDR regime — they are the enforcement teeth that turn “you may offer UPI” into “you must offer UPI”. The two regimes were deliberately coupled in the Finance (No. 2) Act 2019 so that a large merchant cannot rationally refuse a payment instrument whose network cost is mandated zero.
What does Section 271DB actually say?
Section 271DB was inserted into the Income-tax Act 1961 by the Finance (No. 2) Act 2019 alongside the new §269SU mandate. The text is short and operational. Where a person who is required to provide a facility for accepting payment through the prescribed electronic modes of payment under §269SU fails to provide such facility, the Joint Commissioner shall, after giving the person a reasonable opportunity of being heard, levy a penalty of ₹5,000 for every day during which such failure continues. The statute carries a single proviso — no penalty shall be imposable if the person proves that there were good and sufficient reasons for the failure.
Three things are worth flagging. First, the penalty is a daily-accrual penalty, not a single-event penalty — each day of failure is a fresh ₹5,000. A six-month gap is not ₹5,000; it is ₹5,000 multiplied by roughly 180 days. Second, the penalty is levied by the Joint Commissioner, which means it cannot be quietly assessed at the Assessing Officer level and must go through a documented hearing. Third, the “good and sufficient reasons” defence is real but the burden of proof sits with the assessee — the default presumption is that the failure attracts penalty.
The CBDT clarified the implementation timeline in Circular No. 32/2019 dated 30 December 2019, which confirmed that no penalty under §271DB would apply if the prescribed facilities were installed and operational by 31 January 2020. From 1 February 2020 onward, the daily clock runs.
Who is in scope, and how is the ₹50 crore threshold read?
Section 269SU applies to every person carrying on business whose total sales, turnover or gross receipts in business exceeded ₹50 crore during the immediately preceding previous year. The threshold is read against the previous year — meaning a business that crossed ₹50 crore in FY 2024-25 is in scope for FY 2025-26, regardless of the current year’s actual turnover.
The mandate is form-of-organisation neutral. It applies to companies, LLPs, partnership firms, sole proprietorships, HUFs and trusts carrying on business. Pure-profession assessees (a doctor, a chartered accountant in personal practice with no separate business) are outside the §269SU mandate and therefore outside §271DB. A professional firm that also carries on business — say, a hospital that runs a pharmacy retail business — is in scope on the business turnover.
A clean read of the threshold needs three checks for finance teams sitting near the line. One — confirm the turnover used is the previous-year figure, not the current-year run-rate. Two — confirm the figure includes total sales, turnover or gross receipts as defined for income-tax purposes (which is broader than the GST taxable supply figure for some businesses). Three — for groups, the threshold applies per legal entity, not at consolidated level — a parent below ₹50 crore with a subsidiary above ₹50 crore has the subsidiary in scope.
Which electronic modes are prescribed under Rule 119AA?
Rule 119AA, notified on 30 December 2019, prescribes three electronic modes that an in-scope business must mandatorily offer to its customers:
- Debit card powered by RuPay
- Unified Payments Interface (BHIM-UPI)
- Unified Payments Interface Quick Response Code (BHIM-UPI QR)
The list is deliberately specific. RuPay debit is named — Visa or Mastercard debit, while perfectly legal payment instruments, do not satisfy the §269SU obligation on their own. UPI is named separately from UPI QR — a checkout that exposes UPI collect-flow but no QR option is technically half-compliant. The statute does not say “the merchant may choose one of the three”; it says all three must be offered.
This matters when a controller audits a channel where physical presence is involved. An in-store POS terminal that accepts Visa debit, Mastercard debit and credit cards but does not accept RuPay debit is failing the §269SU test even though it accepts most card volume. The cure is usually a software update from the acquiring bank to enable RuPay routing on the existing terminal, not a hardware change — but the evidence trail (acquirer confirmation letter, transaction log showing a successful RuPay swipe) needs to exist.
What is the channel-audit framework for a clean §271DB posture?
The right way to audit §269SU compliance — and therefore the right way to prevent §271DB exposure — is channel-by-channel, not aggregate. A business above ₹50 crore typically has between four and eight sales channels: website checkout, native mobile app, marketplace storefronts (Amazon, Flipkart, Ajio), B2B ordering portal, in-store POS, call-centre payment link, IVR collection, and field-collection mobile app for receivables. Each channel needs its own row in the audit matrix.
For each channel, three confirmations are required.
| Check | What it tests | Evidence |
|---|---|---|
| Gateway configuration | Are the prescribed modes enabled at the payment-aggregator level for the merchant ID used by this channel? | Razorpay / PayU / Cashfree / Juspay / BillDesk dashboard screenshot showing UPI and RuPay enabled for the MID |
| Checkout-layer enablement | Are the prescribed modes turned on in the channel’s checkout configuration (Shopify checkout, custom React checkout, Adobe Commerce module, B2B portal payment page)? | Channel admin screenshot showing UPI and RuPay-debit as visible payment methods |
| Customer-flow visibility | Is the customer actually able to see and select the prescribed modes at the point of payment? | End-to-end test transaction screenshot from the customer-facing surface |
A channel that passes the first two checks but fails the third — for example, a B2B portal where UPI is technically configured but is hidden behind a “more payment options” accordion that customers never expand — is a real-world exposure. The customer-flow test is the one that catches it.
The cadence that holds up to scrutiny is quarterly. A quarterly checkout audit with archived screenshots per channel-mode cell gives a controller a contemporaneous evidence pack and a defensible “we knew, we checked, we fixed within X days” narrative if a gap is later found.
Where does §271DB liability hide that finance teams routinely miss?
Four hot-spots account for most of the exposure that surfaces in practice.
B2B portals. A B2B ordering portal built for wholesale or distributor flows almost always defaults to bank-transfer instruments — RTGS, NEFT, sometimes a single net-banking gateway. UPI is rarely the default because B2B transaction sizes (₹2 lakh to ₹50 lakh per order) feel “too large for UPI”. The §269SU mandate does not have a transaction-size carve-out for UPI — the facility must be offered, not necessarily used. UPI in collect-flow mode handles the ticket size; UPI in P2M intent flow has its own per-transaction limit considerations. Either way, the channel must offer the prescribed mode.
Call-centre payment links. A customer-service team that sends payment links over WhatsApp or SMS — common for refund-recovery, lapsed-subscription renewals and ad-hoc invoices — often uses a single payment-link product configured for card-and-net-banking. Adding UPI to the payment-link template is a five-minute gateway-dashboard change, but it gets missed because the team building it is not thinking about §269SU.
IVR collection. Insurance, telecom, NBFC and utility businesses run IVR-based collection flows where the customer enters a card number on the phone. RuPay debit support on the IVR rail depends on the acquiring bank’s processor configuration — and historically, IVR rails have been slow to add RuPay routing. A turnover-above-₹50-crore lender that runs IVR collection without RuPay-debit support has a §271DB exposure on that channel.
Marketplace storefronts. A brand that sells on Amazon, Flipkart, Ajio and Myntra technically does not need to offer payment instruments on the marketplace surface — the marketplace handles the buyer-side payment. But where the brand also runs its own direct channel (D2C website, brand app), that direct channel is squarely in scope on the brand’s turnover. A common mistake is to assume marketplace coverage carries through to the direct channel; it does not.
Worked example — ₹120 crore D2C brand finds a UPI gap on the B2B portal
The shape of a real §271DB exposure is easier to see with numbers. Consider a D2C apparel brand with total turnover of ₹120 crore in the previous year. The brand operates three sales channels:
| Channel | Configured payment methods | UPI bank-account offered? | RuPay debit offered? |
|---|---|---|---|
| Website checkout | UPI, Visa/MC/RuPay debit, credit cards, net banking, COD | Yes | Yes |
| Mobile app | UPI, Visa/MC/RuPay debit, credit cards, wallets | Yes | Yes |
| B2B (wholesale) portal | RTGS, NEFT, single-bank net banking | No | No |
The brand is above the ₹50 crore threshold and is therefore in scope of §269SU on every channel through which it accepts payment. The website and mobile app pass the test. The B2B portal fails — UPI is not offered, RuPay debit is not offered.
Assume the controller discovers the gap during an internal audit, and confirms from gateway dashboard history that the B2B portal went live 45 days ago without UPI or RuPay debit support. The Section 271DB exposure for those 45 days is:
₹5,000 per day × 45 days = ₹2,25,000
That number is the daily-accrued penalty exposure at the moment of detection. It does not stop accruing until the prescribed modes are actually live on the B2B portal. If rectification takes another 14 days (gateway change request, B2B portal release window, regression test, customer-flow verification), the total exposure at the point of restoration is:
₹5,000 × (45 + 14) = ₹5,000 × 59 = ₹2,95,000
Two operational lessons fall out of the example. First, the detection lag is real money — the controller’s discovery 45 days in, rather than at channel launch, cost the business ₹2,25,000 of baseline exposure. A quarterly channel-acceptance audit with the B2B portal in scope would have caught the gap at week 2 instead of week 6. Second, the rectification clock matters — every day between detection and restoration is a fresh ₹5,000. A pre-agreed rectification SLA with the B2B platform vendor (say, 7 calendar days for §269SU restorations) materially reduces residual exposure.
The right entry in the brand’s exception register reads something like: “B2B portal channel — §269SU prescribed e-modes (UPI bank-account, RuPay debit) not enabled since portal go-live on [date]. Section 271DB exposure ₹2,25,000 as on [audit date], accruing at ₹5,000 per day. Rectification request raised with [gateway / vendor]; target restoration [date]. Evidence pack archived.” That register entry, dated and signed, becomes the “good and sufficient reasons / corrective action taken” defence under the §271DB proviso if the matter is ever assessed.
For broader merchant-fee context — including what zero-MDR actually covers, where gateway platform fees diverge from network MDR, and how the three “UPI” sub-instruments are priced — the Income Tax Department’s published Section 269SU FAQs and the linked sibling articles below are the primary references.
Quantify your true blended merchant-fee rate per channel
The MDR Effective-Rate Calculator decomposes your settlement file into instrument-level rates — bank-account UPI, RuPay debit, RuPay-credit-on-UPI, PPI-on-UPI, Visa/MC debit, Visa/MC credit, Amex/Diners, international — and shows the gap between your contracted rate card and what the gateway actually billed. A useful companion to a §269SU channel-acceptance audit because it surfaces channels where UPI is enabled but adoption is low enough to suggest a customer-flow visibility problem.
Open the MDR Effective-Rate Calculator →Reconciliation discipline — turning the audit into a recurring control
The audit framework above prevents §271DB exposure if it runs continuously. The control that turns a one-off audit into a recurring discipline has four moving parts.
Channel-acceptance matrix as a controlled document. The matrix is owned by the controller’s office and reviewed at every quarter close. The rows are sales channels, the columns are the three prescribed e-modes plus any non-prescribed modes the business chooses to offer. Each cell carries a status flag (enabled / disabled / not applicable) and a last-verified date. The matrix is signed off by the channel owner and the finance controller every quarter — the sign-off is the contemporaneous evidence.
Gateway change-management hook. Any new channel, new marketplace integration, new payment-link template or new gateway MID change triggers a §269SU compliance check before go-live. The check is a five-minute checklist — UPI bank-account enabled, RuPay debit enabled, customer-flow screenshot captured — but it has to be a gate, not a suggestion. Without the gate, new channels open §271DB exposure the moment they go live.
Reconciliation cross-check against settlement files. The settlement file is the proof that the prescribed modes are not just offered but actually being used. Pull instrument-level transaction counts per channel per month — a channel that has UPI configured but zero UPI transactions for two consecutive months is a signal that the prescribed mode is technically enabled but functionally invisible. The combination of “configured in dashboard” plus “not used by customers” is the most common pattern that an income-tax audit team finds disquieting.
Exception register and rectification SLA. Any gap detected enters an exception register with the days-of-non-compliance, accrued penalty exposure, owner, target rectification date and evidence pack. The register is the single source of truth that an auditor, the Joint Commissioner or the board’s audit committee will ask for. A well-maintained register with rectifications tracked to closure is, in practice, the most defensible posture a finance team can hold.
These four controls cost very little to set up and almost nothing to operate — a quarterly half-day exercise per channel owner. The downside of skipping them is open-ended liability at ₹5,000 per channel per day for as long as the gap persists. For any business in scope, the cost-benefit is asymmetric.
Continue reading in this cluster
The merchant-fees cluster covers UPI zero-MDR, the §269SU mandate, RBI debit-card MDR caps, gateway platform-fee leakage and the reconciliation disciplines that hold the regime together.
- Cluster hub: /insights/merchant-fees/
- Sibling article: UPI zero-MDR regime — Section 269SU and PSS Act §10A
- Sibling article: MDR fee reconciliation — verifying gateway charges against contracted rates
- Sibling article: RBI debit card MDR cap — the 2017 circular still in force
- Money page: Payment gateway reconciliation
- Money page: Reconciliation software India