Revenue and reconciliation
What Is Payment Reconciliation? Process and Example
Direct answer
Payment reconciliation is the operational process of proving that expected cash from sales or invoices agrees with settlement reports and bank credits after valid returns, fees, taxes and other adjustments. It connects transaction-level commercial records to payment-system evidence and accounting entries, classifies every difference, and keeps unresolved amounts visible until corrected, recovered, accepted or written off under an approved policy.
Also known as: settlement reconciliation, payment matching, cash reconciliation.
Key takeaways
- Reconcile gross activity to each deduction and bank credit; comparing only net totals can hide offsetting errors.
- A useful match joins orders or invoices, fulfilment, returns, commercial terms, settlement lines, tax records, bank entries and the ledger.
- Treat marketplace, quick-commerce, payment-gateway and B2B remittance files as different schemas with different timing and deduction logic.
- A settlement report explains a counterparty calculation; the bank statement proves the cash movement, and neither replaces the books.
- Payment reconciliation is an operational control, not a regulatory definition or assurance that every deduction is contractually valid.
What payment reconciliation does
Operational-practice note: “payment reconciliation” in this article describes a finance control, not a term defined by RBI. RBI’s Payment and Settlement Systems Act FAQ separately explains statutory concepts such as payment instruction, payment system and settlement. It says settlement can occur on a net or gross basis. A commerce team uses those external payment records as evidence, then performs its own reconciliation to contracts and books.
The process starts with what the business believes it earned: fulfilled orders, accepted invoices or other billable events. It then explains every movement from that gross position to cash: cancellations, returns, discounts funded by the seller, commissions, logistics, payment charges, GST on fees, withholding taxes, reserves and prior-period adjustments. The final cash should connect to a bank value date and to the journal posted in the general ledger.
This control is broader than bank reconciliation. A bank reconciliation can show that ₹6,98,400 entered an account. Payment reconciliation explains which orders created it, why ₹3,01,600 did not arrive, whether each deduction was authorised, and how every component was recorded. It is also narrower than revenue recognition: matching cash does not decide when revenue should be recognised under the applicable accounting policy.
A multi-way payment matching process
- Build the expected population. Extract D2C orders, marketplace orders, quick-commerce purchase or sale records, or B2B invoices for the settlement window. Preserve source identifiers, customer, channel, fulfilment status, tax, currency and expected due date.
- Confirm the commercial event. Join dispatch, delivery, service acceptance, cancellations and returns. A paid order later returned belongs in a different bucket from an order never fulfilled.
- Apply approved terms. Map commission, payment-gateway pricing, logistics, promotion funding, reserve rules and tax treatment from effective-dated contracts. Do not infer a valid fee merely because it appears in a settlement file.
- Ingest settlement detail. Retain the original report, settlement ID, line type, event date, amount and payout date. Normalize fields into a common model without overwriting the source description or sign.
- Match bank evidence. Use settlement reference, UTR where supplied, amount, beneficiary account and value date. RBI’s RTGS FAQ explains that a UTR uniquely identifies an RTGS transaction; references from other rails or platforms may use different formats.
- Post and prove the ledger bridge. Connect gross receivable, returns, fees, taxes, withheld amounts and cash to their accounts. Confirm that the journal equals the settlement and that the cash ledger equals the bank.
- Classify exceptions. Separate timing, missing order, duplicate settlement, unknown fee, wrong rate, unprocessed return, short payment, bank mismatch, tax mismatch and mapping error. Assign an owner, evidence request, materiality and due date.
- Close with evidence. Resolve by corrected source data, a later settlement, credit or debit note, counterparty recovery, approved acceptance or policy-governed write-off. Keep the original exception and approval trail.
Matching order to settlement alone is insufficient when a platform nets several days, uses reserves, or applies a prior-period adjustment. Likewise, amount-and-date matching can pair two unrelated deposits. The strongest result retains both line-level links and a batch-level proof that no transaction was omitted or counted twice.
Worked marketplace settlement
Fictional marketplace example: A home-care brand has fulfilled orders with a gross customer value of ₹10,00,000 in one payout cycle. The marketplace reports returns, seller-funded promotions, commission, GST on marketplace fees, logistics, and tax withheld before paying the balance. All figures below are assumed to be supported by the contract and transaction records; that commercial conclusion must be tested in a real reconciliation.
| Settlement component | Amount | Control evidence |
|---|---|---|
| Gross fulfilled orders | ₹10,00,000 | Order and delivery population |
| Customer returns | ₹80,000 | Return receipt and refund lines |
| Seller-funded promotions | ₹20,000 | Campaign terms and order allocation |
| Marketplace commission | ₹1,20,000 | Effective contract rate |
| GST on marketplace fees | ₹21,600 | Tax invoice and eligibility review |
| Logistics charges | ₹50,000 | Shipment-level charge file |
| Tax withheld | ₹10,000 | Applicable statement and ledger |
| Bank credit | ₹6,98,400 | Settlement reference and bank line |
The arithmetic is exact: ₹10,00,000 − ₹80,000 − ₹20,000 − ₹1,20,000 − ₹21,600 − ₹50,000 − ₹10,000 = ₹6,98,400. The deductions total ₹3,01,600, which plus the bank credit returns to gross orders of ₹10,00,000.
Exact arithmetic does not prove validity. The team still checks that every return belongs to the cycle, the promotion was seller-funded, commission used the correct base, fee GST has a valid tax invoice, logistics was not duplicated, and withheld tax is recoverable only under the applicable evidence and tax analysis. If a ₹5,000 logistics line is unsupported, the settlement can remain numerically reconciled while a ₹5,000 commercial claim stays open.
How the matching pattern changes by channel
| Channel | Expected-cash basis | Typical exceptions |
|---|---|---|
| D2C website | Captured gateway payments and cash-on-delivery remittances, linked to fulfilled or refunded orders. | Payment captured but order failed, gateway fee mismatch, refund timing, COD return-to-origin and bank payout lag. |
| Marketplace | Order events rolled into platform settlement cycles after fees, promotions, returns, reserves and taxes. | Cross-cycle returns, retroactive fee adjustment, withheld reserve, duplicate order line, unsupported marketplace deduction. |
| Quick commerce | Platform sale or purchase records combined with store-level fill rate, shortages, expiries and commercial penalties. | Short pick, damaged stock, service-level deduction, different acknowledgement date and high-volume micro-adjustments. |
| B2B | Customer remittance allocated against invoices and approved notes. | Unidentified receipt, partial payment, withholding tax, disputed deduction, wrong legal entity and unapplied credit note. |
One universal matching key rarely works. A D2C gateway may provide payment and payout IDs; a marketplace may provide order, event and settlement IDs; a quick-commerce platform may use purchase-order, inward and claim references; a B2B customer may send only a bank reference and remittance email. Preserve channel-specific keys while mapping them to a common exception vocabulary.
Exception ownership and accounting control
- Freeze the source files, report versions, time zone and settlement cut-off used for each run.
- Prove population completeness with control totals before applying matching rules.
- Use a stable transaction identifier and detect reused identifiers across entities or channels.
- Match exact events first; document any date or amount tolerance and prevent many-to-many overmatching.
- Separate valid timing differences from errors and disputes; assign expected clearing dates to timing items.
- Review fees against effective contract versions, not a single current rate.
- Keep GST on fees, withholding taxes and other tax components in separate accounts pending eligibility or credit evidence.
- Link returns and refunds to the original order and payment so gross sales are not reduced twice.
- Record reserves and rolling holds as receivables only when the accounting conclusion supports that treatment.
- Require an owner, status, evidence, age and financial exposure for each open exception.
- Prevent the same difference from becoming both a chargeback dispute and an accounting write-off.
- Reconcile the final journal to settlement totals and the cash account to the bank statement.
Auto-matching rate is not evidence of correctness by itself. A permissive tolerance can raise the rate while pairing unrelated items. Review unmatched and automatically matched samples, monitor rule changes and keep manual overrides visible.
What official payment sources do and do not establish
RBI sources establish the legal and operational context of regulated payment systems. The Payment and Settlement Systems Act FAQ defines settlement and payment systems; the RTGS FAQ describes transaction-level gross settlement, finality and the RTGS UTR; the TReDS FAQ explains that a TReDS settlement file states amounts to debit and credit and is sent to a payment system for actual movement of funds.
Those sources do not prescribe a merchant’s multi-way reconciliation design, tolerance, exception taxonomy or accounting entries. The control described here is operational practice shaped by contracts, channel data, accounting policy and tax analysis. A marketplace “settled” flag does not establish revenue recognition, tax eligibility or contractual acceptance of every deduction.
Frequently asked questions
What is the difference between payment and bank reconciliation?
Bank reconciliation agrees ledger cash to bank activity. Payment reconciliation additionally explains which orders or invoices created each receipt and why fees, returns, taxes or other deductions changed gross expected cash.
Can a net settlement total be treated as reconciled?
Only after the gross-to-net components and source population are proved. Two wrong deductions can offset each other and still produce the expected net deposit.
What data is needed for marketplace payment reconciliation?
Use order and event detail, delivery and return records, contract terms, settlement lines, fee tax invoices, tax statements, bank credits and the related ledger postings.
How should timing differences be handled?
Give each timing item an expected clearing event and date, then verify it in the later report or bank entry. Do not leave a generic timing bucket permanently open.
Does a UTR prove which invoice was paid?
A UTR can identify an RTGS transaction, but invoice allocation still requires remittance or settlement detail. Amount and bank reference alone may not prove the commercial purpose.
Is payment reconciliation a regulatory requirement?
This article describes an operational finance control. Specific entities may have legal, contractual, audit or accounting obligations, but RBI does not prescribe the merchant workflow presented here.
When is a payment exception closed?
Close it only after evidenced correction, later settlement, approved note, recovery, acceptance or policy-based write-off is reflected in the relevant source and ledger.
Sources and further reading
- Reserve Bank of India: Payment and Settlement Systems Act, 2007 FAQsVerified Jul 25, 2026
- Reserve Bank of India: Real Time Gross Settlement System FAQsVerified Jul 25, 2026
- Reserve Bank of India: Trade Receivables Discounting System FAQsVerified Jul 25, 2026
Educational disclaimer: This material is general information, not legal, tax, or accounting advice. Check current official guidance and your facts with a qualified professional.
From definition to workflow
Apply this concept with connected finance operations
Finnoto connects source records, approvals, reconciliation evidence, and exception ownership so teams can move from knowing the rule to operating the control.
Explore settlement reconciliation