BillDesk MDR Reconciliation: Bill Aggregator and Institutional Merchant Pricing

Every BillDesk settlement batch a finance team sees in its biller bank statement is the net of a mixed basket — net banking through one or more partner banks, credit card and debit card across networks, UPI bank-account P2M, wallets, and for BBPS-routed payments a biller-share line that does not exist on a horizontal payment-gateway file. The bill payment surface BillDesk operates is different from a Razorpay or PayU checkout flow in three structural ways. The biller base is institutional — DTH operators, telecom, state electricity boards, gas distributors, insurance companies, mutual funds, recurring-collection institutional merchants — rather than a long tail of D2C checkouts. The MDR slab is segmented by biller category and bill type rather than billed as a flat blended rate. And the Bharat BillPay layer adds a regulated biller-share apportionment that flows through the settlement at the BBPS-network level rather than as a private MDR line.

This article is written for the Indian utility, telecom, insurance and institutional biller finance controller running a bill-cycle level reconciliation on BillDesk. The reconciliation discipline it describes is for biller-side finance teams, BBPS-aware payment-ops owners and internal audit teams that treat the BillDesk settlement file as a primary cost-of-collection source and want every basis point of fee leakage isolated against an explicit contract and the regulated BBPS apportionment.

Quick-Reference Table

What Does BillDesk’s Settlement File Actually Contain?

The BillDesk biller portal exports a settlement report that finance teams can pull by settlement-batch date range. Each row of the report corresponds to a single bill payment captured against a biller’s collection account; the rows are batched into a settlement_batch_id that maps one-to-one with a NEFT or RTGS credit on the biller’s bank statement. The columns that matter for MDR and BBPS-apportionment reconciliation are the ones that determine which slab each payment was billed against — Customer Reference, Biller Reference, Bill Number, Bill Type (the biller’s internal categorisation, such as Electricity Bill, DTH Recharge, Insurance Premium, Telecom Postpaid, Mutual Fund SIP), Payment Instrument (NetBanking, Credit Card, Debit Card, UPI, Wallet, with the partner bank code or card BIN or UPI handle as applicable), Gross Collection, MDR Amount, Biller-Share, Gateway-Share, GST on MDR, and Net to Biller.

The reconciliation join from this file to the biller’s books has three halves. The outer join is settlement_batch_id against the bank credit UTR — confirming that the batch of bill payments in the report adds up to the NEFT or RTGS credit in the biller’s bank statement on the cycle date. The middle join is the bill-cycle reconciliation: each bill payment’s customer reference and bill number must match against an open bill in the biller’s MIS, and the gross collection must equal the customer-billed amount within the tolerance for partial-payment handling. The inner join is the per-transaction MDR equation: each transaction’s Gross Collection minus the MDR Amount (including the biller-share if it is biller-borne for that bill type, plus the gateway-share) minus GST on MDR should equal Net to Biller, and the MDR Amount should equal the Gross Collection multiplied by the expected rate for that Payment Instrument and Bill Type. A variance on any of the three halves is a reconciliation exception that needs to be classified.

The published column structure is consistent across BillDesk biller exports, but the Bill Type field is configured per biller during onboarding and the Payment Instrument field carries an additional BBPS-channel attribution when the payment is routed through the Bharat BillPay network — a flag that determines whether the regulated BBPS biller-share apportionment applies or whether the transaction is on a direct BillDesk biller channel with the biller’s privately contracted rate. The discipline is to bind the reconciliation tool to the column structure once at onboarding, verify the BBPS-channel flag is reliably populated, and confirm each new export matches the contracted schema.

How Does BBPS Biller-Share Differ from Standard MDR?

Under the Bharat Bill Payment System operated by NPCI, the fee structure on a bill payment routed through the BBPS network is regulated and apportioned among the participating entities. The Bharat Bill Payment Operating Unit on the agent side (the entity that accepts the customer’s payment), the Bharat Bill Payment Operating Unit on the biller side (BillDesk, for institutional billers onboarded as biller-side BBPOU), and NPCI as the central network operator each receive a defined share of the regulated fee. For a regulated utility bill — electricity, water, gas, telecom — the customer-borne convenience fee is capped under the BBPS framework, and for many bill categories the customer-facing fee on bank-account UPI is zero by the same regulatory mandate that drives the broader zero-MDR regime on UPI P2M.

The reconciliation discipline that follows is to bind the expected biller-share per bill type and payment instrument to the NPCI-published regulated schedule, and to verify the BillDesk settlement file’s biller-share column against that expected schedule on every cycle. The leakage cell here is drift — a regulated apportionment that is updated by NPCI, a new bill type added to a biller’s portfolio that is mapped to the wrong BBPS category in the BillDesk configuration, or a private-channel transaction silently flagged as BBPS or vice versa. Each of these drifts shows up as a single basis-point variance on a single transaction but compounds across millions of bill payments over a quarter.

This is structurally different from a horizontal payment-gateway file. On a Razorpay or PayU file the MDR is a single private contractual rate, segmented only by instrument and BIN. On a BillDesk file routed through BBPS, the biller-share is a regulated number that the reconciliation tool must verify against an external schedule. Treating BBPS biller-share as a standard MDR line and reconciling only against the BillDesk contract — without the NPCI schedule overlay — is the most common configuration gap on first deployment.

Where Does BillDesk Bill Net Banking Flat-Fee Versus Percentage?

Net banking is the dominant payment instrument on the institutional biller base — for an electricity utility or telecom postpaid biller, net banking commonly carries 50 to 70 percent of monthly collection volume. The fee structure on net banking diverges from card MDR in a way that is material at high ticket sizes. The convention across Indian gateways for net banking on partner banks is either a flat per-transaction fee (commonly Rs 7 to Rs 20 per transaction, depending on the partner bank and the biller contract) or a percentage rate (commonly 0.9 to 2.0 percent on a non-partner-bank net banking line).

At a low ticket size — a Rs 500 mobile recharge — the flat fee and the percentage are roughly equivalent. At a high ticket size — a Rs 5,000 electricity bill, a Rs 25,000 insurance premium, a Rs 100,000 vendor payment — the difference is structural. A 1.8 percent rate on a Rs 25,000 insurance premium is Rs 450; a Rs 7 flat fee on the same transaction is Rs 7. The reconciliation leakage arises when the biller has not contractually established whether net banking on a given partner bank is flat-fee or percentage, and the BillDesk settlement file silently applies one over the other.

The discipline is to bind the expected net-banking rate per partner bank to the signed biller contract, and to verify on every cycle that the MDR Amount on each net-banking transaction equals either the flat fee for that partner bank or the percentage of the gross collection, not both and not a different value. The reconciliation tool flags any transaction outside the bound contracted rate as a billing exception, and the variance file feeds the next contract review.

What Is the Per-Instrument MDR Table for BillDesk?

BillDesk does not publish a horizontal D2C-style flat-rate card the way Razorpay or PayU does — pricing is negotiated per biller and segmented by biller category and bill type. The reconciliation discipline is to load the contracted rates from the signed biller agreement as the expected-rate baseline, overlay the BBPS regulated schedule where the channel is BBPS-routed, and use the published Indian-market rates for each instrument only as a sanity-check band when the contracted rate is renegotiated.

A consistent reconciliation note: the BillDesk MDR line and the BBPS biller-share line are distinct columns on the settlement file and reconcile against different reference schedules. The MDR is contracted between the biller and BillDesk; the biller-share is the apportionment of the regulated BBPS fee. Treating them as a single fee column collapses the variance signal that surfaces leakage.

Worked Example: Electricity Utility on a Rs 85 Crore Monthly Collection Cycle

Consider a state electricity utility running customer bill collections through BillDesk and Bharat BillPay at Rs 85 crore per month in gross collection. The instrument mix is 60 percent net banking (Rs 51 crore), 22 percent UPI bank-account P2M (Rs 18.7 crore), 12 percent credit card (Rs 10.2 crore), and 6 percent other (a blend of debit card, wallet and RuPay-credit-on-UPI at Rs 5.1 crore). The bills are routed through the BBPS network for the regulated utility category; the customer-borne fee on bank-account UPI for the utility is zero under the BBPS framework, and the customer convenience fee on net banking and card is regulated per the BBPS schedule with the utility absorbing the biller-side share.

Under the published Indian-market conventions and the BBPS apportionment, the expected monthly MDR and biller-share work out as follows. Net banking at Rs 51 crore on the partner-bank flat-fee convention of approximately Rs 7 per transaction — assuming an average ticket size of Rs 1,800 across approximately 28.3 lakh net-banking transactions, the flat-fee component is approximately Rs 1.98 crore. If a fraction of net-banking volume routes to a non-partner bank on the percentage convention at 1.5 percent on, say, Rs 5 crore of that mix, the percentage component adds approximately Rs 7.5 lakh. Credit card at Rs 10.2 crore on a contracted utility slab of approximately 1.5 percent is Rs 15.3 lakh. UPI bank-account P2M at Rs 18.7 crore is zero customer-borne network MDR under the utility BBPS framework — the leakage audit at this line is the verification that the BillDesk settlement file shows zero MDR on every UPI bank-account P2M transaction in the basket. Any positive MDR on a contractually zero-rated UPI transaction is the leakage cell. The other basket at Rs 5.1 crore is segmented across debit card (capped under the RBI 2017 schedule), RuPay-credit-on-UPI (zero at or below Rs 2,000, approximately 2 percent above Rs 2,000) and wallet (PPI on UPI at up to 1.10 percent above Rs 2,000).

The reconciliation discipline that surfaces leakage at this scale is the per-instrument variance ledger. Without it, the utility’s finance team would compute total fee divided by total collection, land at a blended figure of approximately 0.25 percent or so, and have no way to attribute the gap between that blended figure and the contracted schedule. With the per-instrument variance ledger, the variance is decomposed: any non-zero MDR on UPI bank-account P2M is isolated as zero-rated-instrument leakage; any net-banking transaction billed at a percentage when the partner-bank contract is flat-fee is isolated as net-banking-convention leakage; any BBPS biller-share line that does not match the NPCI regulated apportionment is isolated as BBPS-apportionment drift; any RuPay-credit-on-UPI above Rs 2,000 billed at the wrong slab is isolated as instrument-mislabel leakage. At Rs 85 crore monthly collection, even a 0.05 percentage-point drift across the basket is Rs 4.25 lakh per month — a material number that compounds across a fiscal year.

What Does an Automated Reconciliation Tool Check for BillDesk?

A reconciliation tool configured for BillDesk performs six deterministic checks on every settlement cycle. The first is the outer join: each settlement_batch_id must match a single NEFT or RTGS credit on the biller’s bank statement on UTR, date and net amount; any orphaned batch or orphaned credit is flagged as a cycle-boundary exception. The second is the bill-cycle join: each bill payment’s customer reference and bill number must match against an open bill in the biller’s MIS, with partial-payment handling explicit in the rule; orphaned customer references and unmatched bill numbers are flagged as biller-MIS exceptions. The third is the per-transaction MDR equation: Gross Collection minus MDR Amount minus Biller-Share (where biller-borne) minus GST on MDR must equal Net to Biller; sub-rupee differences are rounding exceptions, larger differences are fee-deduction exceptions.

The fourth is the per-instrument expected-rate check: every transaction’s MDR Amount divided by Gross Collection must equal the contracted rate for that Payment Instrument, Partner Bank Code or Card BIN, and Bill Type within a defined tolerance; transactions outside tolerance are billing exceptions. The fifth is the zero-rated-instrument verification: every UPI bank-account P2M transaction on a regulated utility BBPS flow must have zero network MDR in the settlement file; any positive MDR on a contractually zero-rated instrument is flagged as zero-rated leakage. The sixth is the BBPS biller-share verification: every BBPS-routed transaction must show a biller-share line that matches the NPCI-published regulated apportionment for that bill type and biller category; drift in either direction is flagged as BBPS-apportionment exception.

Two further checks overlay the regulatory dimension. The TDS check matches the operator’s Section 393(1) Sl. 8(v) deduction at 0.1% (payment code 1035) against the biller’s Form 26AS — every transaction credited or paid by BillDesk as an e-commerce operator carries the 0.1% deduction, and the biller claims credit in its income-tax return. The GST check matches BillDesk’s tax invoice for the GST on the MDR fee plus the retained biller-share against the biller’s GSTR-2B; the 18% GST on the BillDesk fee components (not on the bill amount itself) is recoverable as input tax credit for registered billers, but only if the invoice flow reconciles cleanly. These two checks turn the BillDesk settlement file from a collection-ops artefact into a regulatory artefact that ties into the biller’s broader compliance posture.

Where Does the BillDesk Reconciliation Connect to Wave 1 Leakage Patterns?

The BillDesk per-instrument reconciliation maps directly to several Wave 1 leakage patterns that operate across gateways. The zero-rated-instrument verification on UPI bank-account P2M flows under utility BBPS is an instance of the MDR charged on zero-MDR UPI or RuPay debit pattern — the network MDR is mandated zero, and any positive MDR on a contractually zero-rated transaction is the leakage cell. The net-banking flat-fee versus percentage exposure shares structure with the flat-rate MDR concealing per-network cost differences pattern — the single blended-rate calculation obscures that a partner-bank flat-fee line and a non-partner-bank percentage line have materially different unit economics at high ticket sizes, and the fix is the per-instrument effective-rate model rather than a single weighted average.

The refund and chargeback discipline maps to MDR not reversed on refunds — BillDesk follows the industry-standard non-reversal practice on the MDR component, so the leakage is structural and the biller should model the refund-MDR cost explicitly rather than discover it as a residual after each cycle. The BBPS biller-share verification has no direct horizontal-gateway analogue, but the discipline of binding an expected-rate model to an external regulated schedule is the same pattern used in the per-instrument reconciliation on a Razorpay or PayU file — see PayU MDR reconciliation: standard 2% and premium slab handling for the equivalent on a horizontal gateway, and PhonePe PG MDR reconciliation: blended Standard Plan and wallet interchange for the wallet-interchange line that recurs on the BillDesk wallet basket.

Continue Reading in This Cluster

The merchant-fees cluster on Terra Insight covers the per-gateway and per-aggregator reconciliation surface and the platform-level leakage patterns that operate across them. Adjacent to this article: PayU MDR reconciliation: standard 2% and premium slab handling for the horizontal payment-gateway equivalent; PhonePe PG MDR reconciliation: blended Standard Plan and wallet interchange for the wallet-on-UPI interchange line; MDR charged on zero-MDR UPI or RuPay debit for the zero-rated-instrument verification discipline; flat-rate MDR concealing per-network cost differences for the blended-rate trap; and MDR not reversed on refunds for the refund-cost structural pattern.

For the broader category, the merchant-fees cluster hub collects every per-gateway and per-leakage-pattern article into a single index. For the money page that anchors the topic, payment-gateway reconciliation covers the platform-level reconciliation product surface that ingests BillDesk, Razorpay, PayU, Cashfree, PhonePe and the other Indian aggregators into a single cost-of-collection view. For the broader buying decision, reconciliation software India anchors the comparison frame.

The regulated apportionment referenced throughout this article on the Bharat BillPay biller-share line is set by the National Payments Corporation of India, which operates the BBPS network and publishes the fee structure that BillDesk’s biller-share column reconciles against. For the authoritative source on the regulatory framework that governs Bharat BillPay and the underlying zero-MDR regime on UPI bank-account P2M, see the National Payments Corporation of India.