Let’s talk
Retail & ecommerce / Finance

Reconcile payment-gateway captures, refunds, fees and bank payouts

By Vikasraj YadavPublished 15 min read

For finance controller with ecommerce operations lead · Plan implementation

TL;DR — what you’ll learn

  • Reconcile direct-to-consumer (D2C) payment gateway activity at the transaction (`payment_id` and `refund_id`) level before posting bank deposits; never book the net bank credit straight to sales revenue.
  • Maintain a separate `Payment Gateway Clearing Account` so gross captures, net-settled refunds, gateway fees, GST on fees, and rolling holds bridge cleanly to the exact bank `UTR` credit.
  • Distinguish an `Authorized` or `Failed-After-Debit` payment from a `Captured` payment, and tie customer refunds to both the order return record and the specific settlement batch where the gateway deducted the funds.
  • Test your reconciliation pipeline against three exceptions: a late-night capture that rolls into `T+2` settlement, a prior-day refund netted out of today's payout, and a fee-tier overcharge.

Topics: payment gateway reconciliation · payment settlement reconciliation · ecommerce payment reconciliation · gateway payout matching

Light-ash and grey warehouse inspection counter with two dark monitors, docked handheld barcode scanners, a stainless parcel scale, unbranded kraft boxes and grey storage totes overlooking a high-bay pallet racking mezzanine.

Illustrative e-commerce returns grading and warehouse inventory reconciliation desk; not a client facility.

All quantities, amounts, product codes and events are illustrative teaching examples.

A direct-to-consumer home-appliances brand exports its Tuesday order log from its ecommerce storefront and sees ₹12,40,000 in prepaid checkout orders (UPI, credit cards, and netbanking). On Wednesday afternoon (T+1), the company's current account receives a NEFT/RTGS settlement credit with UTR UTR2026101488912 for ₹10,82,916—a gap of ₹1,57,084. If the accountant books only the ₹10,82,916 bank receipt or writes off the difference as "gateway charges," revenue, customer receivables, input GST credit, and open refund liabilities will all be misstated. When the finance analyst reconciles the storefront order ledger against the gateway's transaction-level settlement report (such as Razorpay's payment and settlement dashboard records), the ₹1,57,084 delta breaks down into five distinct items: ₹65,000 of late-night checkouts captured after the gateway's daily settlement cut-off (still sitting in unsettled clearing), ₹15,000 of customer checkouts that remained Authorized without capture and auto-voided, ₹48,000 of prior-week customer refunds deducted from Wednesday's payout, ₹10,000 held by the gateway for a pending card chargeback dispute, and ₹19,084 of gateway fees plus 18% GST (₹16,172.88 fee + ₹2,911.12 IGST).

The operational decision in payment gateway reconciliation is how to link four distinct identifiers—order_id (commerce/ERP), payment_id (gateway capture), refund_id / dispute_id (deductions), and settlement_id / UTR (bank credit)—so every rupee captured from a customer is traced to a bank deposit, a verified refund/chargeback deduction, an audited fee + tax voucher, or an aged unsettled clearing balance. Unlike marketplace settlement reconciliation, where the marketplace controls shipping, commission, TCS/TDS, and multi-week payout cycles, a direct payment aggregator settles on a T+1 or T+2 banking-day cycle and nets prior-period refunds and fee taxes directly against current captures. Accounting entries and GST input-tax-credit claims must follow your entity's accounting policy and verified tax invoices reflected in GSTR-2B on the GST Portal; consult your finance and tax advisors for statutory treatment.

Why order totals, gateway dashboards and bank statements diverge

Three structural differences prevent a 1-to-1 daily match between your storefront order report and your bank statement:

  1. Payment state vs order state: A storefront order created at 23:52 may be in Payment Pending, Authorized (funds blocked on customer's card/UPI mandate but not yet captured by the merchant), or Captured. Only Captured payments enter the gateway's settlement pool. Conversely, a customer whose account was debited during a network timeout may trigger a gateway auto-refund without ever creating a fulfilled order in your ecommerce ERP integration.
  2. Cut-off windows and banking holidays (T+1 / T+2 rollovers): Captures completed after the gateway's cut-off or on non-banking weekends/holidays roll into the next settlement batch (settlement_id). Without an unsettled clearing ledger, month-end and day-end cut-offs always look short.
  3. Netting of refunds, chargeback holds, and fee taxes: Most Indian payment aggregators deduct instant or standard refunds (refund_id), dispute reserve holds, Merchant Discount Rate (MDR) fees, and 18% GST on fees from the outgoing settlement batch before initiating the bank transfer:

Net Bank Payout (UTR) = Captured Settled in Batch − Refunds Deducted − Dispute Holds − Gateway Fee − GST on Fee

Scroll horizontally to see all columns.

Reconciliation layer Left-hand record Right-hand record Match key Exception & ageing rule Owner
1. Checkout-to-Capture match Storefront / OMS prepaid order (order_id) Gateway payment entity (payment_id, status Captured) order_id ↔ payment_id + exact gross amount Flag any Authorized payment uncaptured >24h (before auto-void) or any Captured payment with no matching OMS order (orphan capture requiring auto-refund or order creation). Ecommerce operations + order support
2. Capture-to-Settlement batch match Gateway Captured ledger (payment_id) Gateway settlement detail report (settlement_id line item) payment_id ↔ settlement_id Hold unsettled captures in Gateway Clearing Account; alert finance if any Captured payment remains unsettled >T+3 banking days. Finance reconciliation analyst
3. Refund & Dispute deduction match ERP approved return/refund memo (R048) Gateway settlement deduction line (refund_id / dispute_id) refund_id ↔ credit_note_id + settlement_id Block any gateway refund deduction that lacks an approved OMS return/cancellation record; route chargeback holds to the dispute-evidence queue (Mastercard India chargeback guidance). Finance + customer support lead
4. Fee, GST & Bank UTR match Contracted MDR rate card + monthly gateway GST invoice Settlement fee/tax columns + bank statement credit (UTR) settlement_id ↔ Bank UTR + exact net payout Flag any line where Actual_MDR > Contracted_MDR + ₹1; reconcile monthly gateway tax invoice against GSTR-2B before claiming input tax credit. Accounts payable / tax analyst
End-to-end payment gateway bridge from ₹12,40,000 checkout attempts to ₹10,82,916 bank UTR credit Flowchart illustrating how ₹12,40,000 of Tuesday checkout attempts splits into ₹15,000 uncaptured authorizations, ₹65,000 unsettled T+2 captures, and ₹11,60,000 settled captures, followed by deductions for refunds (₹48,000), chargeback hold (₹10,000), MDR fees (₹16,172.88), and GST (₹2,911.12) to equal the ₹10,82,916 bank credit. 1. Checkout Attempts Gross orders: ₹12,40,000 Less uncaptured: -₹15,000 Captured: ₹12,25,000 
  <path d="M219 84 L251 84" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r072)"/>

  <rect x="251" y="36" width="200" height="96" rx="8" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.5"/>
  <text x="265" y="60" font-weight="700" fill="#854d0e">2. Cut-Off Split (T+1)</text>
  <text x="265" y="80">Captured: ₹12,25,000</text>
  <text x="265" y="98">In-transit (T+2): -₹65,000</text>
  <text x="265" y="116" font-weight="600" fill="#0f172a">Batch Gross: ₹11,60,000</text>

  <path d="M451 84 L483 84" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r072)"/>

  <rect x="483" y="36" width="200" height="96" rx="8" fill="#ffedd5" stroke="#ea580c" stroke-width="1.5"/>
  <text x="497" y="60" font-weight="700" fill="#9a3412">3. Batch Deductions</text>
  <text x="497" y="80">Prior refunds: -₹48,000</text>
  <text x="497" y="98">Dispute hold: -₹10,000</text>
  <text x="497" y="116" font-weight="600" fill="#9a3412">Fee + 18% GST: -₹19,084</text>

  <path d="M683 84 L715 84" stroke="#475569" stroke-width="1.8" marker-end="url(#arrow-r072)"/>

  <rect x="715" y="36" width="181" height="96" rx="8" fill="#dcfce7" stroke="#16a34a" stroke-width="1.5"/>
  <text x="729" y="60" font-weight="700" fill="#166534">4. Bank UTR Credit</text>
  <text x="729" y="80">Batch: SETL-20261014-01</text>
  <text x="729" y="98">UTR: UTR2026101488912</text>
  <text x="729" y="116" font-weight="700" fill="#166534">Net Cash: ₹10,82,916</text>

  <rect x="24" y="170" width="872" height="160" rx="8" fill="#ffffff" stroke="#cbd5e1" stroke-width="1.2"/>
  <text x="44" y="198" font-weight="700" font-size="13" fill="#0f172a">Gateway clearing account reconciliation equation (0.00 unallocated variance)</text>
  <text x="44" y="224" fill="#334155">• Gross Captured (₹12,25,000) = Settled in Batch SETL-20261014-01 (₹11,60,000) + Closing Unsettled Clearing Carry-Forward (₹65,000).</text>
  <text x="44" y="248" fill="#334155">• Batch Gross (₹11,60,000) - Refunds (₹48,000) - Chargeback Hold (₹10,000) - MDR Fee (₹16,172.88) - 18% GST (₹2,911.12) = ₹10,82,916.00.</text>
  <text x="44" y="272" fill="#334155">• Fee Audit Check: Contracted blended fee on ₹11,60,000 was ₹14,972.88 + ₹2,695.12 GST = ₹17,668.00 → ₹1,416.00 fee overcharge flagged!</text>
  <text x="44" y="302" font-weight="600" fill="#0369a1">Ledger Rule: Never net ₹48,000 refunds or ₹19,084 fees/taxes against Top-Line Sales; post each component to its dedicated GL account.</text>
</g>
<defs>
  <marker id="arrow-r072" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
    <path d="M 0 0 L 10 5 L 0 10 z" fill="#475569"/>
  </marker>
</defs>
A dedicated gateway clearing account bridges checkout captures, cut-off rollovers, netted refunds, chargeback reserves, and fee taxes to the exact bank UTR deposit.

Worked illustrative example: bridging ₹12,40,000 of orders to a ₹10,82,916 bank payout

Let us walk through the exact arithmetic for Tuesday's trading (2026-10-13) and Wednesday's settlement batch (SETL-20261014-01, bank UTR UTR2026101488912).

Step 1: Reconcile checkout orders to gateway captures

  • Storefront prepaid checkout attempts (2026-10-13, 00:00–23:59): 248 orders totalling ₹12,40,000.00
  • Less: Uncaptured Authorized / timeout orders (3 orders): -₹15,000.00 (orders remained in Authorized state due to webhook drop and were auto-voided; never shipped)
  • Verified Captured payments on 2026-10-13 (245 payments): ₹12,40,000.00 − ₹15,000.00 = ₹12,25,000.00 (debited to Payment Gateway Clearing Account and credited to Customer Order Liability / Revenue upon dispatch)

Step 2: Separate settled captures from cut-off rollovers

  • Less: Late-night captures (22:30–23:59, 13 payments) held for T+2 batch: -₹65,000.00 (remains as the closing debit balance in Payment Gateway Clearing Account at end of Wednesday, to be cleared in Thursday's SETL-20261015-01 batch)
  • Gross captured payments included in Wednesday batch SETL-20261014-01 (232 payments):

₹12,25,000.00 − ₹65,000.00 = ₹11,60,000.00

Step 3: Reconcile batch deductions (refunds, chargebacks, MDR fees and GST)

Inside settlement report SETL-20261014-01, the gateway applies four deductions against the ₹11,60,000.00 gross settled captures:

  1. Prior-period customer refunds (9 refund_ids): -₹48,000.00 (matched 1-for-1 against approved credit notes in the retail refund reconciliation register).
  2. Chargeback dispute reserve hold (1 dispute_id, DSP-9041): -₹10,000.00 (transferred to Disputed Gateway Hold Receivable while support prepares delivery proof under Mastercard India chargeback dispute rules).
  3. Gateway fee (MDR) deducted: -₹16,172.88
    • Rate-card audit check: The ₹11,60,000.00 batch consisted of ₹4,60,000.00 zero-MDR UPI payments (0.00% fee = ₹0.00), ₹5,80,000.00 standard domestic cards/netbanking (1.85% contracted MDR = ₹10,730.00), and ₹1,20,000.00 corporate/EMI cards where the contract specifies 2.535733% (₹3,042.88) plus ₹1,200.00 platform router fee = ₹14,972.88 expected fee. However, the gateway classified ₹60,000.00 of domestic consumer cards at a 3.85% commercial card tier instead of 1.85%, overcharging ₹1,200.00 in base fee (₹14,972.88 + ₹1,200.00 = ₹16,172.88).
  4. 18% GST (IGST) on gateway fee:

₹16,172.88 × 0.18 = ₹2,911.12

(comprising ₹2,695.12 expected IGST plus ₹216.00 IGST on the ₹1,200.00 fee overcharge; total fee + GST deducted = ₹16,172.88 + ₹2,911.12 = ₹19,084.00, of which ₹1,416.00 gross is flagged as a fee-dispute claim).

Scroll horizontally to see all columns.

Bridge line item Amount (₹) Clearing & GL posting impact Reconciliation status & action
Storefront checkout attempts (248 orders) 12,40,000.00 Memo / OMS order log Compare against gateway Captured log
Less: Uncaptured Authorized voids (3 orders) -15,000.00 No GL entry; cancel uncaptured OMS orders Verified voided at gateway
Total Gateway Captures (245 payment_ids) 12,25,000.00 Dr Gateway Clearing Account ₹12,25,000.00 All 245 captures matched to OMS dispatched orders
Less: Post-cutoff captures carried to T+2 (13 payment_ids) -65,000.00 Remains as Dr balance in Gateway Clearing Account Auto-matches in next day's batch SETL-20261015-01
Gross Captures in Batch SETL-20261014-01 (232 payment_ids) 11,60,000.00 Cr Gateway Clearing Account ₹11,60,000.00 Batch header gross verified
Less: Prior-period refunds netted (9 refund_ids) -48,000.00 Dr Customer Refund Liability ₹48,000.00 Matched to 9 approved credit notes (R048)
Less: Chargeback reserve hold (DSP-9041) -10,000.00 Dr Gateway Chargeback Hold Receivable ₹10,000.00 Evidence pack due within acquirer deadline
Less: Contracted gateway fee (MDR) -14,972.88 Dr Payment Gateway Fee Expense ₹14,972.88 Matches rate-card schedule
Less: Excess gateway fee overcharge (tier error) -1,200.00 Dr Gateway Fee Claim Receivable ₹1,200.00 Ticket raised with gateway account manager
Less: 18% GST (IGST) on charged fee (₹16,172.88 × 18%) -2,911.12 Dr GST Input Tax Credit Clearing ₹2,911.12 Reconcile to monthly tax invoice & GSTR-2B
Net Bank Settlement Credit (UTR2026101488912) 10,82,916.00 Dr Bank Current Account ₹10,82,916.00 Exact match to bank statement (₹0.00 variance)

Check the complete bridge: ₹11,60,000.00 − ₹48,000.00 − ₹10,000.00 − ₹14,972.88 − ₹1,200.00 − ₹2,911.12 = ₹10,82,916.00 And the Payment Gateway Clearing Account ends Wednesday with an exact debit balance of ₹65,000.00 (₹12,25,000.00 − ₹11,60,000.00), itemized down to the 13 specific payment_id records awaiting Thursday's settlement.

Daily and monthly reconciliation workflow

Run a two-cadence workflow across ecommerce operations and finance:

  1. Daily T+1 automated 3-way match (Owner: Finance Reconciliation Analyst). Ingest the OMS daily order/refund export, the gateway combined settlement report (payment_id, refund_id, settlement_id), and the bank statement (UTR). Auto-post matched batches only after shadow-pilot sign-off and route four exception types to daily work queues:
    • Orphan captures (Captured at gateway, missing in OMS): route to an urgent OMS/Finance disposition queue—never trigger blind automatic order creation or unapproved auto-refunds. Operations and Finance must verify inventory reservation, webhook logs, and customer payment state, then execute an approved disposition decision: either replay the verified capture event to create/link the controlled OMS order record when stock and customer intent are confirmed, or issue an approved, reference-linked refund within 24 hours.
    • Uncaptured authorizations (Authorized at gateway, marked paid in OMS): hold shipment immediately until capture succeeds.
    • Aged unsettled captures (Captured >T+3 banking days with no settlement_id): escalate to gateway support.
    • Unmatched refund deductions (refund_id in settlement batch with no ERP credit note): freeze manual dashboard refund permissions.
  2. Monthly fee and GST input-tax-credit reconciliation at M+5 days (Owner: Tax / AP Analyst). Sum all daily MDR and GST deductions across the month's settlement batches and compare against the payment aggregator's monthly GST tax invoice and GSTR-2B reflection before transferring GST Input Tax Credit Clearing to final input credit.

Bounded single-gateway shadow pilot, recovery, and exit criteria

Before enabling automated GL posting across payment channels, run a bounded shadow-reconciliation pilot on one payment gateway or payment-method cohort (for example, a single aggregator's daily settlement batches over 5–10 banking days):

  • Owners and pre-pilot baseline: Jointly owned by the Finance Controller and Ecommerce Operations Lead. Record the actual pre-pilot baseline from existing reconciliation registers—specifically the current unallocated clearing-account balance, daily count of unmatched payment_id/refund_id lines, and manual reconciliation preparation time—without inventing unobserved baseline figures.
  • Rollback and controlled replay recovery: Keep existing manual bank-clearing journal approval active as the fallback during shadow operation. If a webhook drop, parser mismatch, or duplicate batch import occurs, disable auto-posting immediately and recover by replaying the verified gateway webhook or settlement batch file into the controlled system-of-record ledger using idempotent transaction keys (payment_id, refund_id, settlement_id).
  • Measurable exit criteria before auto-post: Require formal Finance Controller sign-off confirming ₹0.00 unexplained delta between settlement batches and bank UTR deposits, 100% of orphan captures and unmatched refunds routed to approved disposition workflows, and verified pass results across all four acceptance tests (ACT-R072-01 to ACT-R072-04).

Observable acceptance tests for gateway reconciliation

Test your ERP or reconciliation tool with these four scenarios before turning on automated GL posting:

Scroll horizontally to see all columns.

Test ID Scenario setup Action executed in system Expected pass criteria Failure indicator
ACT-R072-01 Cut-off rollover (T+2 settlement): Order ORD-901 (₹5,000) is captured at 23:40 on Day T and excluded from Day T+1 settlement batch SETL-01. Reconciliation job runs on Day T+1 and Day T+2. On T+1, ORD-901 stays in Gateway Clearing Account (Unsettled <T+3) with no variance write-off; on T+2, it clears automatically against SETL-02. System flags ORD-901 as missing cash on T+1 or forces a manual adjustment to balance the T+1 bank deposit.
ACT-R072-02 Netted prior-period refund without ERP credit note: Settlement batch SETL-01 includes a -₹2,500 deduction for rfnd_8812 triggered manually in the gateway dashboard, with no matching return in OMS/ERP. Daily settlement import processes SETL-01. System posts the bank UTR but isolates -₹2,500 (rfnd_8812) into Unmatched Gateway Refund Suspense and alerts Finance/Support. System buries the -₹2,500 deduction inside net revenue or gateway fee expense.
ACT-R072-03 MDR rate-card overcharge: Gateway deducts 3.85% (₹2,310 + ₹415.80 GST) on a ₹60,000 domestic card transaction contracted at 1.85% (₹1,110 + ₹199.80 GST). Fee-audit rule evaluates settlement line items against contracted rate table. System posts ₹1,110 to Gateway Fee Expense, routes ₹1,200 (+ ₹216 GST) to Gateway Fee Claim Receivable, and exports the payment_id for vendor credit claim. Entire ₹2,725.80 deduction is expensed without checking the contracted MDR rate card.
ACT-R072-04 Duplicate capture/settlement replay and reversal: Webhook or settlement file containing capture pay_9921 (₹4,000) and reversal/refund rfnd_9921 (-₹4,000) is replayed twice after a connector timeout, alongside an orphan capture pay_9950 missing in OMS. Ingestion and reconciliation engine processes the replayed payloads against the controlled system record. System enforces idempotency on unique (payment_id, settlement_id) and (refund_id, settlement_id) keys—posting pay_9921 and rfnd_9921 exactly once (₹0.00 net clearing balance, no duplicate order or double refund)—and holds orphan pay_9950 for an approved order-replay or refund decision. Duplicate replay creates a second OMS order or double-posts GL clearing entries, or orphan pay_9950 triggers an unapproved automatic order/refund.

Next actions to eliminate unallocated gateway balances

To bring your payment-gateway clearing account to a verified, transaction-itemized balance:

  1. Stop posting net bank UTR deposits directly to sales or customer ledgers: create a dedicated Payment Gateway Clearing Account per payment aggregator so gross captures, netted refunds, dispute holds, and fees + GST are booked separately.
  2. Require the gateway's combined line-item settlement report (containing payment_id, order_id, refund_id, settlement_id, fee, and tax), not just the summary payout email, as the mandatory input for daily bank reconciliation.
  3. Lock manual refund creation in the gateway dashboard and govern orphan captures by approved disposition: require routine customer refunds to originate via API from your reconciled OMS/ERP refund workflow, and route orphan captures to a controlled replay-or-refund approval queue rather than blind automation.
  4. Run a bounded single-gateway shadow pilot and acceptance tests ACT-R072-01 to ACT-R072-04, requiring Finance Controller sign-off on zero unexplained UTR variance and idempotent replay recovery before enabling automated GL posting, then reconcile monthly GST against GSTR-2B.

Discuss this workflow

If your finance team is spending hours reconciling `T+1` gateway deposits, netted refunds, and MDR fee discrepancies across UPI and card processors, NextEdge Labs can help you implement automated transaction-level clearing and exception queues in your ERP.

START A CONVERSATION

Let’s talk about your next build.

Prepare your brief below, then review and send it in your email app to sales@nextlabsonline.com.

SELECTED INDUSTRYRetail & ecommerce

Article: Reconcile payment-gateway captures, refunds, fees and bank payouts · Finance

THE FIRST CONVERSATION

Your product idea, AI opportunity or automation challenge—and a useful first milestone.

All fields are required.

A few sentences about the problem, your users and timing are enough.

We’ll use your details to respond to your enquiry. Please don’t include patient records, passwords or confidential information. Privacy Policy · Website Terms.

References

Sources checked 15 October 2026. Vendor documentation supports platform facts; the worked examples and diagrams are original.

About the author

Vikasraj Yadav writes about operational decisions, software and automation for NextEdge Labs.