Skip to main content
Payment Gateway Integration · India

BillDesk Reconciliation Software for India — Bill Aggregator Settlement, MDR, GST, TDS

BillDesk is a bill aggregator, not a direct-to-consumer payment gateway — utilities, NBFCs, insurers, banks, and mutual funds rely on it to concentrate millions of regulated bill, EMI, premium, and SIP collections daily, settled T+1 net of commission. The reconciliation problem is biller-centric: every collected payment must match a bill reference in the institution's billing system, every commission and 18% GST must be classified for ITC, and Section 393(1)(f) TDS at 5% on commission (payment code 1007) must reconcile to Form 26AS. TransactIG handles the bill-aggregator pattern end-to-end.

Request a Demo Payment gateway reconciliation overview →
File formats
CSV · fixed-width · SFTP
Use case
Institutional billers
TDS treatment
393(1)(f) 1007 commission
Implementation
2–4 weeks

What BillDesk Aggregates Natively, and Where the Reconciliation Gap Appears

What BillDesk handles natively

BillDesk concentrates bill, EMI, premium, and SIP collections from customers across banking channels, UPI, cards, and netbanking, on behalf of biller institutions. It validates the bill reference against a biller-supplied master, accepts the payment, settles T+1 to the biller's nominated bank account, and publishes a settlement file with transaction-level detail. The biller sees one credit per day and one file that explains it.

For institutional clients with disciplined bill-master maintenance and a single nominated settlement account, BillDesk's own reporting answers the routine cash-arrival questions.

Where the reconciliation gap appears

The reconciliation requirement is at bill level: every settled amount must post to a specific customer's outstanding bill in the billing system. Bills paid twice, bills paid against a closed account, overpayments, partial payments, and BillDesk-rejected items all need bill-master-level investigation. Commission per transaction varies by instrument and channel; 18% GST on commission is ITC-eligible only when the BillDesk tax invoice appears in GSTR-2B; Section 393(1)(f) TDS at 5% on commission (payment code 1007 under the Income Tax Act 2025) must reconcile to Form 26AS.

For an NBFC with a million-EMI book or an insurer with monthly premium runs in the lakhs, this is not a spreadsheet problem.

TransactIG Capabilities on BillDesk

Six matching surfaces designed for the bill-aggregator pattern — biller billing system as the master, BillDesk as the collector, bank account as the cash leg.

Bill-reference-level matching

Every settled payment matched to a specific bill reference in the biller's billing system — utility bill number, loan account number, policy number, customer ID, SIP folio.

Commission + 18% GST classification

Commission per transaction separated from the 18% GST. GST flagged ITC-eligible and aged against BillDesk's monthly tax invoice in GSTR-2B under Rule 36(4).

Section 393(1)(f) TDS — code 1007

5% TDS on commission under Section 393(1)(f) of the Income Tax Act 2025 (payment code 1007, replacing legacy 194H). Reconciled to Form 26AS at code level.

Reversal and biller-rejection handling

SETTLEMENT_REVERSED, BILLER_REJECTED, CHARGEBACK each tracked separately. Reversal clawback aged from original settlement to bank debit.

High-value audit evidence

Bill-level evidence pack for institutional clients — NBFC EMI reconciliation for RBI inspection, insurer premium reconciliation for IRDAI, statutory audit trail for ICFR.

Variance taxonomy

BILL_REF_INVALID, CUSTOMER_NOT_FOUND, BILL_PAID_TWICE, OVERPAYMENT, PARTIAL_PAYMENT, SETTLEMENT_REVERSED — structured codes with maker-checker.

BillDesk Integration — Settlement File Architecture

Each row is a discrete feed configured during implementation. BillDesk publishes via its documented SFTP delivery to the biller; TransactIG owns the matching schema, bill-master alignment, and variance taxonomy.

Source Ingest method Cadence Field mapping Variance codes
BillDesk settlement report Scheduled SFTP delivery from BillDesk to biller Daily, T+1 Settlement batch ID → biller payout batch PAYOUT_MISSING_IN_BANK, AMOUNT_MISMATCH
Transaction-level breakdown CSV / fixed-width line items per settlement Per settlement Bill reference / customer ID → biller billing system BILL_REF_INVALID, CUSTOMER_NOT_FOUND, PARTIAL_PAYMENT
Biller billing system extract Daily bill master export to SFTP Daily Bill number → outstanding ledger BILL_PAID_TWICE, BILL_NOT_DUE, OVERPAYMENT
Refunds / reversals Reversal entries in settlement file Per reversal event Reversal ID → original bill payment SETTLEMENT_REVERSED, BILLER_REJECTED, CHARGEBACK
Commission + 18% GST Service-charge + GST columns in sidecar; monthly tax invoice Per transaction, monthly tax invoice Commission expense GL + GST input GL FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B
Section 393(1)(f) TDS — 1007 TDS column in sidecar; quarterly 26AS download Per transaction, quarterly 26AS WT line → payment code 1007 TDS_NOT_IN_26AS, RATE_MISMATCH
Bank credit (net settlement) MT940 / CAMT.053 / bank portal Daily Bank narration BillDesk batch → settlement ID NARRATION_UNPARSED, CREDIT_TIMING, NET_AMOUNT_DIFF

Common BillDesk Reconciliation Gaps

Bill paid twice, account already closed

Customer settles the same bill through two channels — BillDesk and direct UPI to the biller. The biller's billing system rejects the second posting; cash sits in the suspense account.

Partial bill payment

Customer pays part of an electricity bill or insurance premium. The billing system may not natively support partial — the unmatched residual ages in the biller's books.

BillDesk reversal across periods

A settled bill payment is reversed in a later period due to an upstream issue. The original credit, the eventual debit, and the biller's posting to the customer ledger live in three different timestamps.

Commission GST unclaimed in ITC

The 18% GST on BillDesk commission is ITC-eligible — booked to expense by default and lost unless explicitly classified and aged against the 2B feed.

High-value bill timing variance

For large insurance premiums or commercial electricity bills, a single Above ₹1 lakh payment can swing the daily settlement materially — timing investigation needs single-bill granularity.

Multi-biller settlement to one bank account

Large institutions register multiple biller codes (state-wise, business-line-wise) all settling to a single nominated bank account — the bank credit needs decomposition by biller code.

How TransactIG Reconciles BillDesk

01

Ingest settlement file

BillDesk SFTP drop lands the daily settlement and transaction breakdown. Biller billing-system export, bank statement, GSTR-2B, and Form 26AS feeds land alongside.

02

Decompose deduction layers

Gross-to-net waterfall rebuilt per bill payment — commission, GST on commission, TDS under 393(1)(f). Each layer routed to the correct GL.

03

Classify variances + evidence

Unmatched items route to the exception queue with variance codes, ageing, and audit-ready evidence at bill level. Maker-checker before any biller-ledger posting.

Frequently Asked Questions

How is BillDesk reconciliation different from a typical PG settlement? +

BillDesk operates as a bill aggregator — concentrating bill payments on behalf of biller institutions like electricity boards, gas utilities, telecom operators, NBFC EMI collections, insurance premium receipts, mutual fund SIPs, and bank credit-card payments — rather than as a merchant payment gateway acquiring direct-to-consumer card payments. The reconciliation pattern is biller-centric: BillDesk passes through a high-volume, high-value collection of bills on behalf of the institutional client and settles net of a per-transaction commission. TransactIG reconciles BillDesk settlements against the biller's billing system — utility bill numbers, loan account numbers, policy numbers, customer IDs — rather than against a merchant's order or invoice schema.

What does the BillDesk settlement file contain? +

BillDesk publishes settlement reports to billers (institutional clients) with a transaction-level breakdown of every bill payment collected — bill reference, customer reference, biller-defined fields, payment instrument, MDR or commission deducted, 18% GST on commission, refunds and reversals, and the net settled amount. Settlement is typically T+1 for live banking-channel collections. TransactIG ingests the BillDesk file on a scheduled SFTP cadence and joins it to the biller's billing system extract (utility billing system, LOS, policy administration system, mutual fund RTA file) on the bill reference. No invented API endpoints — TransactIG works with BillDesk's documented settlement file delivery to the biller.

How is the 18% GST on BillDesk commission classified? +

BillDesk deducts a per-transaction commission (effectively MDR in PG terms, called a service charge in the bill-aggregator context) and adds 18% GST on that commission. For an institutional biller — an NBFC collecting EMI through BillDesk, an insurer collecting premium — the 18% GST is ITC-eligible input tax subject to Rule 36(4) and the BillDesk-issued tax invoice appearing in GSTR-2B. TransactIG classifies the commission and the GST separately, ages the provisional ITC, and flags ITC_INELIGIBLE_2B when the invoice is missing from 2B at filing-cutoff time.

Where does TDS apply on BillDesk commission? +

Commission paid by the institutional biller to BillDesk for aggregator services attracts Section 393(1)(f) of the Income Tax Act 2025 at 5% (payment code 1007, replacing legacy Section 194H). TransactIG maps the biller's WT entries to payment code 1007 and reconciles against Form 26AS at code level. Section 393(1)(j) (payment code 1010, e-commerce sales) does not apply on BillDesk's institutional-biller flows because BillDesk is not selling goods or services on the biller's behalf — it is collecting a regulated bill or premium that the biller has already billed.

How are refunds, reversals, and failed payments reconciled? +

Bill payments can fail at multiple points — at the customer's bank during debit, in transit, or after settlement when the biller rejects the payment for an invalid bill reference. TransactIG tracks each state separately: PAYMENT_FAILED at the customer side (no settlement impact, no reconciliation needed), SETTLEMENT_REVERSED where a settled amount is clawed back from a later payout (REFUND_REVERSAL with the expected debit date), and BILLER_REJECTED where the biller has flagged the bill reference invalid (needs manual investigation against the billing system master).

Does TransactIG handle BillDesk for high-value institutional clients? +

Yes. BillDesk's customer base is concentrated in regulated institutions where bill-payment reconciliation is itself a regulatory deliverable — NBFCs need to demonstrate clean EMI collection reconciliation for RBI inspection, insurers for IRDAI, banks for credit-card payment posting to customer ledgers, mutual funds for SIP processing. TransactIG produces the audit-ready evidence pack (bill-level matching, ageing, variance taxonomy, maker-checker workflow) that these institutional clients need to support their own regulatory and statutory audit reporting.

Reconciliation built for the bill-aggregator pattern

Bill-reference-level matching, commission and 18% GST classified for ITC, Section 393(1)(f) TDS reconciled to 26AS, audit-ready evidence for RBI, IRDAI, and statutory inspection. 2 to 4 weeks, ISO 27001:2022, AWS Mumbai.

Request a Demo Payment gateway reconciliation overview →