Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
For OTT and streaming subscription businesses in India, refunds are frequently initiated days or weeks after the original transaction has already settled. The refund cannot be clawed back from the closed settlement, so it lands as a negative adjustment in a later cycle. Finance teams that try to net the refund against the original settled amount produce a broken audit trail; teams that book it in the wrong period miss the Section 34 CGST credit note deadline and the proportional ITC reversal.
The reconciliation runs across two cycles simultaneously. Cycle A holds the original gross settlement, its MDR fee, its ITC on the fee, and the recognised subscription revenue. Cycle B — the settlement cycle in which the refund is initiated — holds the negative refund line, the credit note issued under Section 34 CGST, and the proportional ITC reversal in GSTR-3B Table 4B(2). The two cycles are linked by a common transaction reference (payment_id or order_id) but are booked as independent accounting events. A refund register threads through both, closing only when settlement, credit note, and ITC reversal are all confirmed.
Refund-lag classifier (same-cycle vs cross-cycle), Section 34 credit-note deadline tracker (30 November of following FY), proportional ITC split engine, and negative-net-cycle detector that flags days where refund volume exceeds new settlement volume.
Refund register linked to original orders across cycle boundaries, credit notes issued within the Section 34 window, GSTR-3B Table 4B(2) reversal schedule matched to credit note dates, and a negative-net-cycle exception log that lets treasury anticipate bank debits for shortfall days.
For streaming and OTT businesses in India, subscription refunds rarely align with the original settlement cycle. A customer disputes a mis-billed charge on Day 15; the payment gateway settled the original transaction to the merchant on Day 2. The refund cannot travel backwards through a closed cycle — it lands as a negative adjustment in whichever cycle the merchant initiates it. Finance teams that treat this as a same-cycle offset produce cascading errors: overstated refund-day revenue, understated original-cycle revenue, and a Section 34 credit note dated in the wrong period. The correct model reconciles two cycles simultaneously — one for the original settlement, one for the refund adjustment — linked by a shared transaction reference but booked as independent accounting events.
The reconciliation in one paragraph
When a refund is initiated after the original PG settlement has closed, the deduction hits the next available cycle. Reconciliation matches four records: the original settlement report showing the gross transaction and MDR fee, the subsequent-cycle settlement report showing the negative refund adjustment, the merchant refund ledger showing the customer credit initiation, and the customer bank credit confirmation from the gateway callback. GST layers on top: a credit note under Section 34 of the CGST Act for the refund amount, with a proportional ITC reversal in GSTR-3B Table 4B(2) in the period the credit note is dated. The reconciliation closes when all four records tie back to the same original transaction reference, and the credit note plus ITC reversal are logged against the refund cycle rather than the original cycle.
What the scenario looks like in India
An illustrative streaming subscription service — for example, a Netflix India monthly plan renewal, a Sony LIV Premium subscription, a ZEE5 annual pack, or an Amazon Prime Video India renewal — processes recurring subscription charges through Razorpay, PayU, or Cashfree. On Day 2, the platform settles the Day 1 subscription revenue to the merchant bank account net of MDR. On Day 15, a customer raises a support ticket for a mis-billed charge and the merchant approves a full refund of ₹4,999 via the Razorpay dashboard.
The refund does not reach back into the Day 2 settlement. Instead, Razorpay records a refund initiation event, credits the customer’s card or UPI account within its stated timelines, and deducts ₹4,999 from the merchant’s next available settlement cycle — Day 15 or Day 16, depending on cutoff. That deduction shows up as a negative line in the settlement report referencing the original payment_id.
If the merchant processed several such refunds in a single day, the aggregate deduction can exceed the day’s new settlement volume, producing a negative net cycle. Some gateways carry the shortfall forward to the next positive cycle; others debit the merchant’s linked current account directly. Either way, treasury must anticipate the cash movement.
Illustrative brands here are Netflix India, Sony LIV, ZEE5, Amazon Prime Video India, MX Player, Aha Video, Sun NXT, and Voot Select. Audio streaming platforms like JioSaavn face identical patterns on premium tier refunds. The reconciliation is the same shape regardless of content type — what varies is refund frequency and average ticket size.
The regulatory and PG-rules overlay
Three regulatory dimensions frame this reconciliation.
Section 34 of the CGST Act. When a registered supplier reduces the value of a supply already invoiced — through a refund, a discount, or a return — a credit note must be issued. The time limit is 30 November of the financial year following the year of the original supply, or the date of filing the annual return (GSTR-9), whichever is earlier. For a subscription refunded in July 2026 against a June 2026 invoice, the credit note must be issued by 30 November 2027. Missing the window means the ITC reversal cannot be formally reflected in GSTR-3B and the discrepancy surfaces in GSTR-9C reconciliation at year-end.
GST rate on OTT and SaaS subscriptions. Streaming subscription revenue is taxed as an Online Information Database Access or Retrieval (OIDAR) supply at 18% GST. A ₹4,999 subscription includes ₹762.63 of GST (₹381.32 CGST + ₹381.32 SGST for intra-state, or ₹762.63 IGST for inter-state or B2C). When refunded, the same GST amount must be reversed proportionally through the credit note and reported in Table 4B(2) of GSTR-3B for the period the credit note is dated.
RBI Payment Aggregator framework. The March 2020 RBI framework mandates settlement timelines from PA to merchant and refund timelines from PA to customer. Payment aggregators must maintain nodal escrow accounts and follow prescribed refund timelines — typically 5 to 7 business days for card refunds, faster for UPI. The framework does not force refunds into the original settlement cycle; it only sets the maximum time from initiation to customer credit.
MDR treatment on refunds. The Merchant Discount Rate charged on the original transaction is generally not refunded by the gateway when the merchant refunds the customer. On UPI and RuPay Debit — where the Zero MDR Notification of 30 December 2019 sets MDR at 0% — this is irrelevant. On credit cards and premium cards, the merchant absorbs the original MDR as a cost, and only the customer-facing amount is deducted from the next settlement. This asymmetry — refund without MDR reversal — is a leakage point that reconciliation must surface.
TCS Section 52 of the CGST Act. For e-commerce operators — a category that in some structures can include OTT aggregation — TCS at 0.5% is collected on the net value of taxable supplies. Where TCS was collected on the original supply and the supply is subsequently refunded, the TCS position must also be adjusted in the operator’s GSTR-8. Direct-billed subscriptions to end customers by the streaming service itself typically do not attract Section 52; where the platform hosts third-party OTT content and takes commission, Section 52 may apply.
A worked example — illustrative numbers
Consider a monthly subscription refund for an illustrative Sony LIV Premium plan processed through Razorpay.
Day 1 (original transaction, 2 June 2026)
- Customer charged ₹4,999 including 18% GST via UPI (0% MDR)
- Base subscription revenue: ₹4,236.44
- GST (18%): ₹762.63 (IGST for cross-border B2C or CGST + SGST equivalent for intra-state)
- MDR on UPI: ₹0
- Gross to merchant: ₹4,999.00
- Invoice raised, revenue recognised, GST liability booked
Day 2 (original settlement, 3 June 2026)
- Razorpay settles ₹4,999.00 to merchant bank account net of ₹0 MDR
- Settlement report line: payment_id P123, amount +₹4,999.00
- Book: Dr Bank ₹4,999 / Cr PG Suspense ₹4,999
- Original cycle closes clean
Day 15 (refund initiated, 17 June 2026)
- Customer raises dispute, merchant approves full refund
- Merchant issues Section 34 CGST credit note CN-2026-0847 dated 17 June 2026, referencing original invoice
- Credit note face value: ₹4,999 (₹4,236.44 base + ₹762.63 GST)
- Refund initiated via Razorpay dashboard; refund_id R456 linked to payment_id P123
Day 15 or Day 16 (subsequent settlement cycle, 17 or 18 June 2026)
- Razorpay’s next settlement to merchant now includes a negative adjustment
- Assume the day’s other settlements gross ₹1,20,000; net settlement is ₹1,20,000 − ₹4,999 = ₹1,15,001
- Settlement report line: refund_id R456, amount −₹4,999.00 (linked to P123)
- Book against refund entry: Dr Revenue Reversal ₹4,236.44 / Dr GST Reversal ₹762.63 / Cr PG Suspense ₹4,999.00
- PG Suspense clears when the net ₹1,15,001 lands in bank
GSTR-3B for June 2026 (filed July 2026)
- Reduce output tax liability by ₹762.63 (or report in Table 4A as “other outward supplies” adjusted; Table 4B(2) captures the corresponding ITC reversal if any input ITC was attributable to the refunded supply)
- Credit note reflected in Table 9B of GSTR-1 for June 2026 with reference to the original invoice
Negative-net-cycle variant. If the same day sees ₹20,000 in refunds against only ₹15,000 in new settlements, Razorpay produces a −₹5,000 net cycle. Treasury either sees a ₹5,000 debit to the linked current account or a carry-forward against the next positive cycle. The reconciliation must detect this event, tag it as negative-net, and confirm which resolution path the gateway used.
Common reconciliation breakages
Five patterns account for most refund-lag failures.
1. Netting the refund against the original cycle in the books. Finance teams reopen the June 2 journal entry and reduce it by ₹4,999. The audit trail is destroyed; the original cycle’s revenue and GSTR-1 output line no longer match. Downstream, GSTR-3B reconciliation for June breaks and GSTR-9C reconciliation at year-end surfaces the discrepancy. Correct treatment leaves the original cycle intact and books the refund entirely in the cycle the credit note is dated.
2. Credit note dated in the wrong month. Some accounting systems auto-date credit notes to the original invoice date. This backdates the credit note to Day 1 and forces the ITC reversal into the wrong GSTR-3B period. The credit note date must be the refund initiation date under Section 34, not the original invoice date.
3. Missing the Section 34 deadline. For refunds initiated in Q4 of an FY — January through March — the 30 November of following FY deadline is comfortable. For refunds initiated late in an FY and forgotten operationally, teams sometimes discover them during year-end close after 30 November has passed. Once past the window, the credit note cannot be filed through GSTR-1 and the corresponding output tax cannot be reduced. The refund becomes a permanent tax cost.
4. MDR asymmetry not surfaced. On credit cards, the original MDR is absorbed by the merchant and not refunded by the gateway. Refund reconciliation that does not track this leaves a small permanent leakage — 1.5% to 2.5% of every refunded credit card transaction. Aggregated over a quarter of subscription refunds, this can run into meaningful rupee figures for a large OTT platform. UPI and RuPay Debit refunds carry no such asymmetry due to Zero MDR.
5. Failed refund handling. If the customer’s card has expired or the UPI VPA is invalid, the refund fails at the gateway and the money is credited back to the merchant. This produces a positive line in a subsequent settlement, cancelling the earlier negative. The reconciliation must detect the cancellation pair and, if a credit note was already issued and the ITC reversed, either issue a debit note or ensure the customer is refunded through an alternate channel before the Section 34 window closes.
How a reconciliation platform handles this
A reconciliation platform closes the loop across the two cycles automatically.
For every refund line in a settlement report, the platform resolves the original transaction by payment_id or order_id, retrieves the original cycle’s booked entries, and cross-references the merchant refund ledger to confirm merchant initiation. It then checks whether a credit note under Section 34 has been issued for the refund amount, verifies the credit note date is within the deadline, and posts the proportional GST reversal to the GSTR-3B Table 4B(2) workpaper for the correct period.
Where refunds aggregate to a negative net cycle, the platform flags the day and cross-checks the merchant bank statement for either a debit (gateway pulled the shortfall) or a receivable (gateway carried it forward). This lets treasury reconcile the bank statement without a manual dig into the gateway dashboard.
Where MDR asymmetry exists on card refunds, the platform surfaces the unrefunded MDR as a discrete cost line rather than absorbing it silently into the negative adjustment. This gives finance visibility into refund leakage as a separate category.
Where refund failures produce reversal cascades — refund initiated, refund failed, money re-credited to merchant, credit note already issued — the platform matches the cancellation pair, alerts the compliance workflow, and either voids the credit note (if the Section 34 window is still open and no GSTR-1 filing has occurred) or triggers a debit note as remediation.
Structured payment gateway reconciliation closes the multi-cycle refund loop with the credit note and GSTR-3B position tied to the correct reporting period. Reconciliation software India automates the two-cycle match across high refund volumes without requiring per-transaction manual intervention.
The Reserve Bank of India’s Payment Aggregator framework sets the settlement and refund timelines that every gateway must observe. The March 2020 guidelines, updated periodically, define the outer bounds within which refunds must reach the customer’s bank; the two-cycle reconciliation model sits inside those bounds and closes the merchant-side accounting position independently.
The five FAQs below cover the cross-cycle mechanics, Section 34 timing, and negative-net-cycle handling that arise most frequently for streaming and OTT subscription reconciliation in India.
Frequently Asked Questions
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
- ▸ CGST Act, Section 34 — Section 34 — Credit and Debit Notes; time limit for issuing credit notes
- ▸ RBI — Guidelines on Regulation of Payment Aggregators and Payment Gateways (March 2020, updated) — Payment Aggregator (PA) framework — settlement, refund, and escrow rules
- ▸ CGST Rules, Rule 42 & 43 — Proportional reversal of input tax credit
- ▸ Zero MDR Notification, 30 December 2019 — 0% MDR on UPI and RuPay Debit; variable MDR on credit and premium cards continues