What Is Payment Reconciliation? Meaning & Process

Your bank shows a credit of ₹4,97,350. Your invoice says ₹5,00,000. Nobody has stolen anything, but until you can explain the ₹2,650, your books don't close and your cash position is a guess.

That gap is the whole job. Payment reconciliation is how a finance team proves that what a customer paid, what the bank credited, and what the ledger records are the same transaction, then explains every rupee of difference in writing.

This guide covers the definition, the eight-stage payment reconciliation process with real numbers, gateway settlement mechanics, where automation still breaks, and how the work changes once money crosses a border into India.

Payment reconciliation runs in three moves, and everything else is detail.

• Gather - pull the bank statement, the gateway settlement report, your invoices and receipts, and the accounting ledger for the same period.
• Match - pair each external credit to an internal record on date, amount and reference number. Rules handle the clean majority.
• Resolve - investigate what didn't match, identify the cause (fee, tax deduction, timing, FX movement, wrong payer name), book the adjusting entry, and document it.

Verify that the adjusted balances agree, keep the working papers, and get a reviewer to sign off before the period locks. That's the control, per Stripe's eight-stage breakdown.

Payment reconciliation is the financial process of matching and comparing transaction records so the payments you made or received agree with what's recorded in your accounting books (Stripe). Two ledgers, one reality, and a written explanation of every difference between them.

Three distinctions decide whether you actually understand it. Most pages skip all three.

Reconciliation Is Not the Same as Matching

Matching is pairing one transaction to one invoice or order. Granular, one to one, and it either works or it doesn't.

Reconciliation is the wider control that uses matching as a step, then explains what refused to pair, corrects the records, and certifies that the two sets of books agree in total (Stripe). You can match 900 of 1,000 transactions and still be nowhere near reconciled.

Settlement Happens First, Reconciliation Checks It Afterwards

Settlement is the processor or bank moving net funds into your account on its own cycle. Reconciliation is the accounting check that what landed equals what was owed, once fees and refunds are backed out.

The two run in sequence, never as synonyms (Stripe payout reconciliation docs; Razorpay settlement FAQs). Teams that read "the money arrived" as "the books are right" are skipping the second half.

Where the Classic Bank Reconciliation Statement Fits

The Bank Reconciliation Statement (BRS) you learned in accounting class reconciles the bank column of your own cash book against the bank's statement. It explains timing differences, unrecorded charges and errors until both balances tie out (ICAI CA Foundation notes, Chapter 3).

A BRS is one narrow case. Payment reconciliation spans gateway reports, invoices and multiple payment rails, not just the bank column. If your work is purely cash-book-versus-statement, our banking reconciliation goes deeper on that specific type.

The standard named types are bank, credit card, accounts receivable, accounts payable, intercompany, payroll and general ledger reconciliation (Stripe). Each has its own dedicated treatment; this page is the category-level answer.

Stripe documents eight stages, and they hold up across payment modes.

Source: Stripe, payment reconciliation 101.

A Worked Example: The ₹2,650 That Went Missing

Here's the opening scenario, traced to zero. It's an illustrative example built to be checkable, not a named client case.

• Invoice raised to Client A on 1 June: ₹5,00,000, thirty-day terms, due 1 July.
• Bank credit received 3 July: ₹4,97,350.
• Apparent shortfall: ₹2,650.

Stage two throws two separate flags, and they're easy to confuse. The narration shows an NEFT credit under a truncated remitter string that doesn't read as Client A's registered name. That's a name-mismatch, not a value gap, and you clear it first by pulling the UTR and checking it against the client's remittance advice.

Then the value gap. The remittance advice shows ₹2,500 deducted as TDS on professional fees under Section 194J at 10%, plus ₹150 the receiving bank debited as a service charge. ₹2,500 plus ₹150 is ₹2,650, which reconciles exactly. **

To close it, book a TDS receivable of ₹2,500 which is adjustable against your own tax liability and claimable via your Form 26AS credit. Book ₹150 to bank charges. Then mark the ₹5,00,000 invoice paid in full against the cash receipt plus the two adjusting entries. Net effect on the reconciliation: zero.

Note what happened. No money was lost, nothing was written off as unexplained, and the audit file now carries the remittance advice and both adjustment entries as evidence.

Short section, because the practical value of payment reconciliation concentrates in a few places.

• A cash position you can act on - unreconciled credits mean your reported cash is an estimate, and forecasting off an estimate compounds.
• Audit readiness - the reconciliation statement, exceptions log and adjustment support are the evidence auditors and controllers rely on to sign off the close (Numeric; Solvexia).
• Earlier fraud and error detection - a duplicate payment or an unauthorised debit shows up as an exception within days rather than at year end.
• Working internal controls - Section 134(5) of the Companies Act 2013 requires directors to state that internal financial controls were laid down and operating effectively. Reconciliation is the practical mechanism that satisfies that, not a named statutory step, so don't read it as a legal duty to reconcile.
• GST defensibility - since 1 January 2022, input tax credit claimed in GSTR-3B is restricted to what appears in GSTR-2B under CGST Rule 36(4), which makes reconciling your purchase register against GSTR-2B a practical necessity (CBIC CGST Rules).

Here's what changes when payment reconciliation moves from a spreadsheet to a rules engine, keyed to the same eight stages.

Sources: Zoho Books reconciliation help and banking enhancements for rule-based matching on date, amount and reference number; Stripe for the exception step; Optimus for frequency and scale.

Where Automation Still Fails

Be honest with yourself about this before you buy anything. Two failure modes survive every rules engine.

Genuine remitter-entity mismatches. When a marketplace payout entity or a treasury subsidiary pays on behalf of your invoiced customer, the name on the credit is legitimately a different legal entity. No matching rule resolves that; someone has to know the relationship.

Partial and short payments. A widened tolerance band will "match" the ₹4,97,350 credit above and quietly hide a ₹2,650 question. Whether that gap is TDS, a bank charge or an FX variance is a judgement call with different accounting treatment for each, and a human makes it.

Vendors market AI-driven fuzzy matching and exception handling for the first category (HighRadius). **

Most finance teams run several of these in parallel, not one.

Bank Statement Matching

Compare the general ledger against the bank statement line by line, or by rule. This catches unrecorded charges, missing deposits and duplicate debits, and it's the base layer everything else sits on.

Accounting and ERP Sync

When the accounting system pulls bank feeds and gateway data directly, stages one and two happen without an export step. Fewer manual handoffs, fewer transcription errors, and the ledger stays current between closes.

Payment Gateway Reconciliation

This is where most teams lose the most time, because gateway settlement breaks naive matching by design.

A gateway doesn't credit you per order. It credits one net amount covering many orders, after deducting merchant discount rate (MDR) fees, GST on that MDR, and any refund or chargeback adjustments falling in the same cycle (Razorpay settlement FAQs).

Match gross order value against the net bank credit and you'll show a discrepancy on every settlement.

So gateway reconciliation is a one-to-many match. Stripe frames the same work as a three-way match between the processor's balance activity, your own ledger, and the bank statement (Stripe payout reconciliation).

Two mechanics you need before you can write the rules:

• The files - the settlement report maps transactions to a settlement ID and a UTR, the refund report carries reversals, and channel-specific balance reports keep online, POS and international refunds from distorting each other's settlements (Razorpay).
• The timing - one major Indian gateway documents domestic card and UPI settlement at roughly T+2 working days, with international cycles running longer (T+7 in its documented case). Working days there exclude Sundays, second and fourth Saturdays, and bank holidays (Razorpay). Treat that as one gateway's published cycle, not an industry constant.

Chargebacks appear as adjustment lines inside those settlement and refund files rather than as a separately named document, so don't build your process around a "chargeback report" existing. **

Stripe's payout reconciliation report is a useful shape to copy: a balance summary, a breakdown of each payout against the transactions comprising it, and an ending-balance section listing what hasn't settled yet (Stripe).

The Payment Reconciliation Report Itself

The output of all this is a document, and it's what your reviewer and your auditor actually read. A usable one carries four things.

• The two balances being compared, with the period and source of each.
• The reconciling items and every adjustment booked, with the reason.
• An exceptions log of what remains unmatched and who owns each item.
• Supporting documentation for each adjustment, attached rather than referenced.

It's prepared by the accounting team and reviewed by a controller or finance manager as the final check before the books lock; material items get senior finance sign-off (Solvexia; Numeric). The report is the evidence that the control operated, not just that the balances happened to agree.

The work is identical. The conditions are not, and that's the whole answer.

One Person Owns It, and It's Not Their Only Job

An SME finance function is often two or three people, sometimes one. Hours spent tying credits to invoices are hours not spent on collections or planning, and hiring to cover it adds payroll the business can't easily absorb (Fincent). Adyen's own research points at slow cash flow and payment reconciliation specifically as drags on SME growth (Adyen).

Volume Outgrows the Spreadsheet Before the Tooling Catches Up

Ten transactions a week is genuinely fine in Excel. A hundred is painful and a thousand is impossible, and revenue growth arrives faster than most SMEs upgrade their systems (Optimus).

The Cash Position Is Always Out of Date

Run the process monthly and you're making decisions on a figure that's up to four weeks stale (Optimus). For a business managing runway week to week, that lag costs more than the reconciliation itself.

Manual Entry Introduces Its Own Errors

Mistyped invoice numbers, miscategorised transactions and missing receipts create discrepancies that never existed in the payment (SprintNXT). You then spend the next close investigating your own typing.

Generic advice ("reconcile regularly") won't help you. These are the calls that change how a B2B payment reconciliation process actually runs.

Reconcile Continuously, Not in a Month-End Batch

If your systems can match as transactions land, do that instead of queueing everything for the close (Optimus). Exceptions surface while the counterparty still remembers the payment, which is the difference between a two-minute email and a long chase.

Automate the Majority, Queue the Rest

Write matching rules for the high-volume, low-risk transactions on date, amount and reference number, then route genuine mismatches to a named exception queue (Zoho Books; Stripe). Reviewing every line by hand is what you're trying to stop doing, so don't rebuild it as a review step.

Report the Exceptions, Not the Matches

The useful management report is the ageing exceptions list with an owner against each item, not a count of successful matches. Keep the statement, the exceptions log and the adjustment support together as one pack (Numeric).

Accept That Different Payment Modes Need Different Rules

A services exporter runs three structurally different reconciliations at once: cash ledger against bank statement, net gateway settlement against gross orders, and payment against invoice with TDS and short-pay factored in.

A pure e-commerce seller mostly runs the second. The invoice reconciliation is the one B2B teams most often under-build. This comparison is our own analysis of the mechanics above rather than a single sourced claim.

Match Sign-Off Discipline to Your Size

Larger organisations add a controller review then a CFO or VP Finance sign-off on material items before close (Solvexia). A three-person team can't run two review layers, but it can still separate preparer from reviewer and record who approved what.

Almost nobody searches for this, and we're including it anyway because it's where payment reconciliation genuinely breaks for Indian exporters and no general guide covers it. If you invoice overseas clients, this is the section that will save you time.

The Gap Is Usually Two Different Things Added Together

A short USD credit is normally FX movement plus intermediary bank deductions, and those need separate accounting treatment. Work the example.

An ITES exporter invoices a US client USD 10,000 for a software services milestone, paid SHA, routed through two correspondent banks. The rates below are illustrative figures chosen to make the arithmetic checkable, not live or historical market quotes.

The ₹5,380 splits into ₹3,000 of FX timing variance, which belongs in an FX gain or loss account, and ₹2,380 of intermediary charges, which belongs in bank charges. Writing the whole ₹5,380 off as one unexplained variance is the mistake, because it hides both the rate exposure and the routing cost from anyone reading the accounts later.

Why SHA Charges Eat the Balance

Under the SWIFT message standard, field 71A carries a charge code, and which one your client picked decides what reaches you.

• OUR - the payer bears all charges, so you receive the full invoice value.
• BEN - you bear them all.
• SHA - the sender covers only their own bank's fee, while every intermediary still deducts from the money in transit. This is the most common cause of a short INR credit.

Field 71F discloses those sender charges when the code is SHA or BEN.

These field references are consistent across practitioner sources but were not verifiable against SWIFT's own subscription-gated standards (Faisal Khan LLC MT103 cheatsheet; Flywire help centre). **

The Payer Name on the Credit Won't Be Your Client's

In our example the narration reads as a correspondent bank's name with an ordering-party reference, not the US client's legal entity. That's a routing artefact of the MT103's Ordering Customer field, which records who instructed the payment. Marketplaces, PEOs and treasury centres all trigger it legitimately.

Resolve it by pulling the MT103 copy from your AD bank and checking the Ordering Customer field against the invoice. Then add the relationship to your matching rules so the same client doesn't break the match every quarter.

Cash in the Bank Isn't Compliance Closure

For an Indian exporter, payment reconciliation has a second half that domestic guides never mention.

• The FIRC - your AD Category-I bank issues a Foreign Inward Remittance Certificate, now typically an e-FIRC, as proof the remittance was received. "FIRA" is industry shorthand that fintechs including Xflow use; the FIRC is the instrument the Reserve Bank of India (RBI) and the Foreign Exchange Management Act (FEMA) recognise, and only an AD-I bank can issue it.
• The purpose code - the credit is tagged with an RBI purpose code, P0807 for off-site software exports or P0802 for software implementation and consultancy outside SOFTEX, and that tag has to agree with the underlying invoice.
• EDPMS closure - the AD bank logs an Inward Remittance Message in EDPMS and maps it to the shipping bill, SOFTEX or invoice. The export entry is only closed once matched, and unclosed entries beyond prescribed timelines carry Caution List exposure.

Xflow is a cross-border payments platform for Indian exporters, and the parts of it that touch reconciliation are narrow and specific. Worth naming honestly rather than as a feature list.

• eFIRA on every credit, within 24 hours. The FIRC-sourcing chase described above disappears, because the document is issued automatically rather than requested from the AD bank per transaction.
• Live mid-market rate and next-business-day settlement. A shorter window between invoice and settlement means less room for the rate to drift, which reduces the FX-timing component of the variance in the worked example. That's a mechanism, not a promised saving.
• Zoho Books integration. Credits post into the ledger where reconciliation already happens, so manage international payments with Xflow and Zoho Books without a manual journal entry. A Tally integration is planned, not live today.
• Regulatory standing. RBI granted Xflow final Payment Aggregator - Cross Border (PA-CB) authorisation covering both exports and imports in February 2026. Xflow is ISO 27001 and SOC 2 certified, serves 20,000+ customers across 140+ countries, and supports 25+ currencies.

None of this removes the need for a reconciliation process. It removes the document-chasing and the FX-attribution guesswork around it, which for most exporter finance teams is where the hours actually go.