One PG Settlement Arriving as Two Bank Credits: Split Reconciliation

Payment gateways in India confirm a single settlement to the merchant, but the money often arrives at the merchant’s bank as two credits — a rail-side artifact of how the PG’s nodal bank routes large amounts between NEFT batches, RTGS transfers, and sometimes UPI credit legs. Streaming, subscription, and other PG-heavy businesses see this pattern most often on peak billing days, when the daily aggregate crosses the RTGS threshold and the sending bank splits the disbursement.

Reconciliation must sum the two credits back to one PG settlement — not flag a duplicate, not raise a missing-second alarm, and not conflate this rail-side artifact with intentional marketplace split settlements. This article covers the India-specific mechanics, the regulatory overlay, a worked example on an audio-streaming subscription cycle, the common breakages, and how a platform handles the pattern without operator intervention.

The reconciliation in one paragraph

The PG’s daily settlement file lists one line for a given settlement date: one settlement ID, one gross amount, itemised deductions (MDR, GST on MDR, TDS Section 194O, CGST Section 52 TCS where applicable), and one net amount to be credited. The bank statement, for that same settlement date, shows two credits from the PG’s nodal account — one via RTGS, one via NEFT, or one via each of RTGS and UPI — landing anywhere from a few seconds to about half an hour apart. The reconciliation must group the two credits by shared narration or settlement ID substring, sum them, match the sum to the PG-file net amount, and close the settlement as reconciled. The two bank credits are not separate settlements; they are two halves of one settlement.

What the scenario looks like in India

A subscription-heavy streaming business — say an audio streaming service comparable in shape to JioSaavn — clears its monthly subscription bill on the first of every month. Card and UPI transactions from paying subscribers batch into the payment gateway’s daily settlement cycle. On the first, when subscription renewals concentrate, the daily settlement amount pushes past Rs 2 lakh, and the PG’s nodal bank routes the disbursement in two legs: RTGS for the bulk (real-time above Rs 2 lakh), NEFT for the tail (whatever the sending bank’s internal treasury rules choose to route as a batched transfer).

The same pattern shows up on Netflix India billing waves, Sony LIV monthly plan renewals, ZEE5 auto-debit cycles, and Amazon Prime Video India annual plan clusters. It is not specific to streaming — any subscription or high-ticket business with monthly renewal spikes will see it. But streaming and OTT are the most visible cases because subscription batches concentrate on the same billing anniversary, day after day. Prime Video and other annual plan renewals produce the highest-value spikes and split most reliably.

The pattern also appears with PG rails other than the “usual four” — Razorpay, PayU, Cashfree, BillDesk, CCAvenue — because the split is a property of the nodal bank’s outbound treasury, not of the PG’s software. Whichever bank the PG’s nodal account sits in decides how to route the outbound. HDFC, ICICI, Axis, Kotak, SBI, and Yes Bank all show this split behaviour on large settlements, in different frequency patterns.

The identifying features on the merchant’s bank statement:

• Two credits on the same value date, from the same remitter (the PG’s nodal account name).
• Both narrations reference the same PG settlement ID, the same merchant code, or a common substring (for example, CFRE20260701SETT-01 and CFRE20260701SETT-02, or a shared UTR-group prefix).
• The gap is typically under 30 minutes, occasionally same-second, occasionally as much as a couple of hours if the second leg is a NEFT batch waiting for its next window.
• Each credit has its own UTR, its own IFSC of the sending branch, and its own value.
• The sum equals the PG file’s net settlement amount for that settlement ID.

The regulatory and PG-rules overlay

The relevant rules that shape this pattern are RBI’s Master Direction on Payment Aggregators (17 March 2020, with subsequent amendments), the operating parameters of NEFT and RTGS, and the tax deductions layered on top by Section 194O of the Income Tax Act and Section 52 of the CGST Act.

Under the Payment Aggregator framework, the PG holds customer money in a nodal or escrow account and settles to the merchant’s bank account on a defined cycle — typically T+1 for most PGs on standard risk profiles, with T+0 available on premium tiers. The PA framework does not prescribe how the nodal bank must route the outbound: it only requires the settlement to reach the merchant within the committed timeline. When the nodal bank routes a large settlement, RTGS handles amounts of Rs 2 lakh and above in real time, and NEFT handles amounts below that in half-hourly batches. The nodal bank’s own treasury logic may cap a single RTGS transaction, split at internal cut-offs, or hold part of the settlement for the next NEFT batch. From the merchant’s side, the bank statement is where this decision becomes visible.

The tax-side rules — 0.1% TDS under Section 194O (deducted by the e-commerce operator on the gross value of goods and services facilitated) and 0.5% TCS under Section 52 of the CGST Act (deducted on net taxable supplies by the e-commerce operator) — are handled at the PG’s ledger layer, not at the bank rail. The deductions appear as line items in the PG settlement file. When the bank splits the outbound into two credits, the tax deductions do not split with it: they remain attached to the single settlement ID. This matters at reconciliation, because the TDS and TCS reversal in the merchant’s books belongs to one settlement, not two.

MDR on the underlying customer transactions follows the standard India regime: zero MDR on UPI and RuPay Debit (Zero MDR notification dated 30 December 2019), variable MDR on credit cards and premium debit cards. The MDR is deducted at the PG layer and shown in the settlement file, so it too is unaffected by the bank-side split. UPI credit legs at the settlement-to-merchant stage — where the PG chooses to push part of the settlement via UPI to the merchant’s bank — inherit UPI’s zero-MDR posture, but that is a separate MDR from the customer-side transactions.

A worked example

Consider a subscription-heavy audio streaming service (illustrative persona, not a Terra Insight customer). On 1 July 2026, the service’s Cashfree merchant account records a daily settlement.

The Cashfree settlement file for 1 July 2026, settlement ID CFRE20260701A1B2C3:

(The line-item amounts are illustrative and rounded; the point is the shape of the settlement, not the exact arithmetic.)

The merchant’s finance team expects a single credit of Rs 19,15,200 into the HDFC current account on 1 July.

The HDFC statement for 1 July 2026 shows:

Two credits, same value date, same remitter, both narrations reference the shared PG settlement date and merchant code, gap of 26 minutes, distinct UTRs. Sum is Rs 19,15,200 — exactly the PG file’s net settlement amount.

The reconciliation posture:

1. Match by PG settlement ID group. Group the two bank credits under the shared settlement key.
2. Sum the group. Rs 12,00,000 + Rs 7,15,200 = Rs 19,15,200.
3. Match the summed value against the Cashfree file’s net settlement amount for CFRE20260701A1B2C3. Match closes at zero paise variance.
4. Book the tax deductions (194O TDS Rs 1,972.15, Section 52 TCS Rs 8,435.11, MDR and GST-on-MDR as expense) once, against the single settlement ID.
5. Store UTR-level traceability from the PG settlement ID to both bank UTRs, so audit can trace either credit back to the source settlement without ambiguity.

A single settlement closed against a summed pair of bank credits, with the tax and MDR position reflected on one line — not two.

Common reconciliation breakages

When rules-based matching runs one-to-one at the settlement level, the split pattern produces one of five breakages:

Duplicate revenue booking. The reconciliation treats the two credits as two separate settlements, matches each against a phantom PG line, and books the revenue twice. This surfaces at month-end when the PG-side gross revenue and the bank-side receipts diverge by exactly the value of the second credit. The correction is a reversal, but the entry has already flowed downstream to GSTR-3B, TDS reporting, and MIS.

Missing-second-half alarm. The reconciliation matches the first credit against the PG line, marks the settlement closed at the partial amount, and flags a variance for the shortfall. The operator investigates, discovers the second credit sitting in the unmatched pool, and manually closes the loop. Multiply this by the settlements-per-day count and the labour cost compounds.

Marketplace-split confusion. Where the merchant also runs an intentional marketplace split settlement configuration (for example, an OTT operator that splits payments with a content partner), the reconciliation applies the marketplace rule to a rail-split settlement, tries to allocate the two credits to two beneficiaries, and produces meaningless variances. Marketplace splits are one settlement per beneficiary; rail-splits are one settlement across two credits.

TDS and TCS double-counting. When the reconciliation books the two bank credits as two settlements, it also books the tax deductions twice — once against each fictitious settlement line. GSTR-3B and 26AS positions drift. The correction requires reversing one of the phantom entries, which is manual and error-prone.

Value-date drift. RTGS lands within seconds; NEFT lands at the next half-hourly batch. If the operator books the first credit on the value date and the second credit on the next day (because the operator only sees the second credit the following morning), the receipt date on the two halves diverges. Downstream cash-flow reports show a phantom timing mismatch.

How a reconciliation platform handles this

A production reconciliation platform closes the pattern with a small number of rules and a clear rule-firing order:

1. PG-file ingest first. Load the PG settlement file for the value date. Each settlement ID becomes an expected settlement line with a fixed net amount.
2. Bank statement ingest. Parse each credit line into a candidate match. Extract the sending party (the PG’s nodal account), the narration, and the UTR.
3. Group candidates by settlement key. Where the narration contains the PG settlement ID or a shared substring (settlement date + merchant code + tranche suffix), group candidates under the same key.
4. Sum-and-match. For each group, sum the candidate amounts. Match the sum against the PG-file expected amount. Where the sum equals the expected amount within a zero-paise tolerance, close the settlement.
5. Partial-hold with T+1 window. Where only one credit has landed and the amount is less than the PG-file expected, mark the settlement partially reconciled — matched by ID, unmatched by amount — and hold. Do not raise a duplicate alarm; do not raise a missing-settlement alarm. Only after the T+1 window expires without the second credit landing should the platform escalate to missing.
6. Separate ruleset for intentional marketplace splits. Marketplace split settlements — one customer transaction, multiple settlement IDs, one per beneficiary — follow a different rule: match one-to-one per settlement ID, do not sum. Distinguishing between rail-splits and marketplace splits is a matter of the PG file’s schema: marketplace splits have multiple settlement rows for a single customer payment, rail-splits have one settlement row for a customer payment batch and multiple bank credits under one settlement ID.
7. Trace and close. Store the UTR of each bank credit against the settlement ID. On audit, the trail from PG settlement ID to two bank UTRs is one query.

A platform that implements this without operator involvement — through payment gateway reconciliation rules and reconciliation software India grouping logic — reduces the settlement-closure exception queue on peak billing days from dozens of manual investigations to zero. The platform never asks the operator to decide whether two bank credits are “one settlement or two”; the PG file is the source of truth, and the bank statement is the confirmation. See the Reserve Bank of India Master Directions for the payment aggregator framework and settlement expectations that shape this behaviour end-to-end.

Related patterns in the streaming payment gateway cluster: refund after PG settlement, chargeback-dispute recovery, weekend and holiday settlement stretch, mid-month MDR renegotiation, premium card fee embedded in UPI lookalike, ghost 98-paise test transaction, and subscription vs ad-revenue multi-stream. Adjacent cluster reads: Cashfree settlement reconciliation, Razorpay settlement reconciliation, and UPI settlement reconciliation.

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published 1 July 2026

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024