Why not join all four sources at once?

Because a single join reports that the totals disagree without saying where they started to. Chaining the comparisons localises the break to a hop — recorded but not settled, settled but not banked — and that is the part a person can act on.

How are refunds handled?

They are consolidated before matching. Several refunded entries against one order are grouped and summed into a single record, first-row metadata is retained, and the record is flagged as consolidated so an auditor can still see the individual entries behind the line that was matched.

The gateway deposit never equals the settlement total. Is that a break?

No, and treating it as one would flood the exception queue. The difference is gateway charges and tax. It is derived inside the settlement-to-bank pass and reported as an explained difference, so only unexplained gaps become exceptions.

What if the bank reference is buried in free text?

The payment voucher number is extracted by pattern from the free-text field and used as the matching key. Relying on a well-structured reference field that banks do not consistently populate is why this comparison usually stays manual.

Does matching run in both directions?

Yes. An order absent from the ERP and an ERP entry with no corresponding order are both breaks, and both are reported. A one-directional reconciliation can only find missing records on one side, which is the side you already suspected.

What outcome figures can you share?

None yet. The engagement is in delivery and we do not publish figures we have not verified. The objective set with the customer was a reconciliation cycle measured in hours rather than days; we will report against it when it has been measured.

← All solutions

Solutions

Recorded, settled and banked — checked as three separate facts

The order platform, the ERP, the gateway settlement report and the bank statement compared in four chained passes, with refunds consolidated before matching and every break localised to the hop it occurred on.

Book a demo

Four chained passesRefund consolidationBi-directional matching

Receivables

RetailTechnologyN-way matchingAgentic workflowERP write-backAudit trail

The challenge

Four data sources have to agree for order-to-cash integrity to hold at a global technology manufacturer's India business: the order platform, the accounting entries in the ERP, the payment gateway settlement report and the bank statement. Nothing matched them automatically. Confirming that every sale had been recorded, settled and banked meant working across several reports by hand, which put a limit on how often anyone could ask the question. The objective set for the work was a reconciliation cycle measured in hours rather than days, and a break that names where in the chain it happened instead of reporting that the totals do not agree.

What we built

Four chained reconciliations. The order platform against the ERP payment and invoice documents, matching the payment ID to the ERP reference field. The order platform against the gateway settlement, validating the order value against the gateway gross. The ERP invoice documents against the gateway settlement, confirming invoices were closed against the right settlement. The gateway settlement against the bank statement, matching on a payment voucher number extracted by pattern from a free-text field — where the difference between net settlement and bank deposit is gateway charges and tax rather than a break. Refund consolidation runs before any matching, and all matching is bi-directional.

The result

A break is localised rather than merely detected. Recorded but not settled, settled but not banked, banked for an amount that does not match the order — each is a different exception with a different owner, and the chain says which one applies. Refunds no longer distort the comparison, because several refunded entries against one order are consolidated into a single record before matching, flagged as consolidated so the original rows remain traceable. Duplicate orders, blank keys, unmatched records on either side and captured-then-refunded lifecycles are reported by type rather than gathered into one list of differences.

Process

How it works

Four stages. The order of them matters: refunds are consolidated before anything is matched, because a comparison run against unconsolidated refund rows produces breaks that were never breaks.

01
Ingest & normalise
Order platform extracts, ERP payment and invoice documents, the gateway settlement report and the bank statement are read into one shape. Keys are normalised so a payment ID, an ERP reference and a voucher number can be compared as values rather than as the formats four systems happen to write them in.
02
Consolidate refunds
Where one order carries several refunded entries, they are grouped and summed into a single record. First-row metadata is retained and the record is flagged as consolidated, so an auditor can see both the single line that was matched and the individual entries behind it.
03
Reconcile in four passes
Order platform against ERP on the payment ID and reference field. Order platform against gateway settlement, with the order value validated against the gateway gross. ERP invoices against settlement. Settlement against bank, on a voucher number extracted by pattern from a free-text field, with charges and tax explaining the difference between net settlement and deposit.
04
Exception reporting
Everything that did not match is reported by type: duplicate orders, blank keys, records present on one side and absent on the other, amount mismatches, and orders captured then refunded. Each exception carries the pass it failed on, which is what makes it actionable rather than merely visible.

What it does

Inside the solution

Order platform against the ERP

Payment and invoice documents in the ERP are matched to orders on the payment ID against the ERP reference field. This pass answers one question only: was the sale recorded in the accounts at all.

Order platform against settlement

Orders are matched to the gateway settlement report with the order value validated against the gateway gross. A settled order whose gross does not agree with the order value is a short settlement, and it is reported as an amount mismatch rather than as a match.

ERP invoices against settlement

Invoice documents are confirmed as closed against the right settlement, not merely against some settlement. Closing an invoice against the wrong one nets out at the total level and leaves two records wrong in opposite directions.

Settlement against the bank

Matching runs on a payment voucher number extracted by pattern from a free-text field. The difference between net settlement and bank deposit is gateway charges and tax, so it is derived and explained rather than raised as a break.

Refund consolidation before matching

Several refunded entries against one order are grouped and summed into a single record, with first-row metadata retained and the record flagged as consolidated. Matching against unconsolidated rows generates breaks that never existed.

Bi-directional matching

An order with no ERP entry and an ERP entry with no order are both breaks. Matching one way finds only the first, which is how a reconciliation reports success while entries nobody ordered sit in the ledger.

Exceptions typed, not pooled

Duplicate orders, blank keys, unmatched records, amount mismatches and captured-then-refunded lifecycles are separate categories. A typed exception has an owner and a next action; a list of differences has neither.

Audit traceability end to end

Every matched record keeps the pass it matched on, the keys it matched by and the source rows behind it, including the individual entries inside a consolidated refund. The reconciliation can be re-explained months later without re-running it.

DESIGN PRINCIPLE

Why four passes and not one

A single join across four sources tells you something is wrong without telling you where. Chaining the comparisons localises the break to a specific hop — recorded but not settled, settled but not banked — which is the difference between a report and an action.

Each pass asks one question: Was it recorded, was it settled, was the right invoice closed, did the money arrive. A pass with one question has one owner and one remedy, and its result stays meaningful even when another pass is failing.
The hop names the team: A break between the order platform and the ERP belongs to a different team than a break between settlement and bank. Localising it routes the exception without anyone first having to work out whose problem it is.
Known differences are explained, not flagged: The gap between net settlement and bank deposit is gateway charges and tax. Deriving it inside the pass keeps it out of the exception queue, which is what stops a reconciliation from crying wolf on every settlement it sees.

Foundations

The VapusFin models behind it

Accounts Receivable Automation

Accounts Receivable

Apply cash the day it arrives, classify every short payment and deduction, and chase the invoices most likely to be collected first.

Details

Continuous Reconciliation

Reconciliation

Match bank, ledger, intercompany and tax accounts continuously rather than at period end, and investigate breaks with their likely cause already attached.

Details

Reporting & Intelligence

Aggregate and reconcile data across systems, apply your business rules, and produce MIS that runs from an investor and board view down to a single order, revenue or cost item — with every figure openable to the transaction beneath it.

Details

Questions

Frequently asked

Why not join all four sources at once?: Because a single join reports that the totals disagree without saying where they started to. Chaining the comparisons localises the break to a hop — recorded but not settled, settled but not banked — and that is the part a person can act on.
How are refunds handled?: They are consolidated before matching. Several refunded entries against one order are grouped and summed into a single record, first-row metadata is retained, and the record is flagged as consolidated so an auditor can still see the individual entries behind the line that was matched.
The gateway deposit never equals the settlement total. Is that a break?: No, and treating it as one would flood the exception queue. The difference is gateway charges and tax. It is derived inside the settlement-to-bank pass and reported as an explained difference, so only unexplained gaps become exceptions.
What if the bank reference is buried in free text?: The payment voucher number is extracted by pattern from the free-text field and used as the matching key. Relying on a well-structured reference field that banks do not consistently populate is why this comparison usually stays manual.
Does matching run in both directions?: Yes. An order absent from the ERP and an ERP entry with no corresponding order are both breaks, and both are reported. A one-directional reconciliation can only find missing records on one side, which is the side you already suspected.
What outcome figures can you share?: None yet. The engagement is in delivery and we do not publish figures we have not verified. The objective set with the customer was a reconciliation cycle measured in hours rather than days; we will report against it when it has been measured.

Want the same outcome?

Send us a period of orders, ERP entries, settlement reports and bank statements and we will run the four passes against your own data, and show you where the breaks actually sit.

Book a demo

Last reviewed 4 September 2026

Recorded, settled and banked — checked as three separate facts

The challenge

What we built

The result

How it works

Ingest & normalise

Consolidate refunds

Reconcile in four passes

Exception reporting