Does it post to the ledger by itself?

Only where you configure it to, and always under your approval controls. The default position is that it proposes: the match, the adjustment and the likely cause are presented, and a person accepts them. Every acceptance is recorded against the entry.

How does it handle references the bank mangles?

Patterns are extracted from the free-text narrative and used as matching keys, because that is where the usable reference generally sits. Relying on a structured reference field that banks populate inconsistently is why this reconciliation usually stays manual.

What does a proposed cause actually mean?

It is a hypothesis with its evidence attached — a payment of the same amount two days later, a charge line with no ledger counterpart, a reference that differs by one character. It is offered for a reviewer to accept or reject, and rejecting it costs nothing.

Can we keep our own reconciliation rules?

Yes. Rules for recurring items are configuration owned by your team, and each rule records the entries it matched, so a change in behaviour can always be traced to the rule change behind it.

How are multiple entities kept apart?

Entity scoping is enforced through the matching, so one company's statement never matches against another's ledger, and access follows the same boundary. Inter-company transfers are handled as a recognised recurring pattern rather than as an accidental match.

Has this been delivered for a customer?

Not as a standalone engagement. The matching engine, the rule configuration and the exception typing behind it run today in delivered cash and receivables reconciliation work, and bank reconciliation is that same engine pointed at statements and the ledger.

← All solutions

Solutions

A break with a likely cause beats a difference with a number

Statements matched to the ledger across every account and entity as the transactions land, with recurring items handled by rule, and each remaining break presented with the records that produced it and the explanation that most likely fits.

Book a demo

Continuous, not monthlyRules for recurring itemsBreaks with a proposed cause

Cash & bank

RetailManufacturingLogisticsN-way matchingAgentic workflowERP write-backAudit trail

The problem

Bank reconciliation is usually a month-end exercise across dozens of accounts and several entities, done in spreadsheets, and it is mostly re-doing work that was already done last month. Standing orders, bank charges, interest, sweeps and inter-company transfers reappear every cycle and are re-identified by hand every cycle. What is left over is a list of differences with amounts and dates and nothing else, so the first hour of every investigation is spent working out what each line probably is. By the time the reconciliation is finished, the cash position it describes is already weeks old.

What the platform does

Statements are read as they arrive, across accounts, currencies and entities, and matched against the ledger continuously rather than at month end. Recurring items are handled by rule: standing orders, charges, interest, sweeps and inter-company transfers are recognised by their pattern and matched without a person confirming the same transfer again. What remains is investigated rather than simply listed. A break is presented with the records that produced it and a proposed cause — timing, a partial receipt, a charge not posted, a reference that does not agree — with the evidence for that suggestion shown alongside it.

What you get

The cash position is current instead of reconstructed. Recurring items stop consuming the effort they consume today, which leaves the exceptions with enough attention to be resolved rather than carried forward. Each break arrives with a starting hypothesis and the underlying records, so an investigation begins at the question rather than at the identification. Because matching runs continuously, a break is raised while the counterparty, the payment and the person who initiated it are all still easy to reach, and month end becomes a review of what is outstanding rather than a reconstruction of what happened.

Process

How it works

Four stages that run whenever a statement arrives rather than on a monthly calendar, across every account and entity in scope.

01
Collect statements
Statements are read from every account, in whatever format the bank provides, across currencies and entities. Each file is logged against the account and period it covers, so a missing statement is a visible gap instead of a silently incomplete reconciliation.
02
Apply the rules
Recurring items — standing orders, bank charges, interest, sweeps and inter-company transfers — are recognised by pattern and matched by rule. These are the lines that make manual reconciliation repetitive, and they are the ones that a rule handles identically every cycle.
03
Match to the ledger
Remaining transactions are matched against ledger entries on amount, date, counterparty and reference, including references buried in free-text fields, and in both directions — a statement line with no ledger entry and a ledger entry with no statement line are both breaks.
04
Investigate the variance
Each break is presented with the records behind it and a proposed cause: a timing difference, a partial receipt, a charge not yet posted, a reference that does not agree. The suggestion is evidence for a reviewer to accept or reject, never a posting made on their behalf.

What it does

Inside the solution

Continuous rather than monthly

Matching runs as statements arrive, so the cash position reflects the last transaction rather than the last close, and a break surfaces while the people who can explain it still remember the payment.

Accounts, currencies and entities

Many accounts across several entities and currencies run in one flow, with the entity scoping preserved so a reconciliation for one company never quietly matches against another's ledger.

Rules for recurring items

Standing orders, bank charges, interest, sweeps and inter-company transfers are recognised by pattern and matched by rule. Rules are configuration owned by the finance team, and each is recorded against the entries it matched.

Matching on references in free text

Bank narratives carry the reference that identifies a payment more often than the reference field does. Patterns are extracted from the narrative and used as matching keys, which is what keeps this comparison from staying manual.

Bi-directional matching

A statement line with no ledger entry and a ledger entry with no statement line are both breaks and both are reported. Matching one way only finds the direction you already suspected.

A proposed cause on every break

Timing, partial receipt, unposted charge or mismatched reference, with the evidence for the suggestion attached. The reviewer starts at a hypothesis to confirm or reject rather than at an unlabelled amount.

Breaks that persist are tracked

An item that has not cleared is carried with its age and its history rather than reappearing as new each cycle, so an ageing break is visible as one that keeps returning instead of one that keeps arriving.

Write-back and audit trail

Confirmed matches and adjustments can be written back to the ledger under your approval controls, and each carries the statement line, the ledger entry, the rule applied and the person who accepted it.

Foundations

The VapusFin models behind it

Cash Position & Forecasting

Cash Ledger

Live balances across every account and entity, continuously reconciled to bank feeds and the general ledger, with a forward view built from what is actually scheduled.

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

Does it post to the ledger by itself?: Only where you configure it to, and always under your approval controls. The default position is that it proposes: the match, the adjustment and the likely cause are presented, and a person accepts them. Every acceptance is recorded against the entry.
How does it handle references the bank mangles?: Patterns are extracted from the free-text narrative and used as matching keys, because that is where the usable reference generally sits. Relying on a structured reference field that banks populate inconsistently is why this reconciliation usually stays manual.
What does a proposed cause actually mean?: It is a hypothesis with its evidence attached — a payment of the same amount two days later, a charge line with no ledger counterpart, a reference that differs by one character. It is offered for a reviewer to accept or reject, and rejecting it costs nothing.
Can we keep our own reconciliation rules?: Yes. Rules for recurring items are configuration owned by your team, and each rule records the entries it matched, so a change in behaviour can always be traced to the rule change behind it.
How are multiple entities kept apart?: Entity scoping is enforced through the matching, so one company's statement never matches against another's ledger, and access follows the same boundary. Inter-company transfers are handled as a recognised recurring pattern rather than as an accidental match.
Has this been delivered for a customer?: Not as a standalone engagement. The matching engine, the rule configuration and the exception typing behind it run today in delivered cash and receivables reconciliation work, and bank reconciliation is that same engine pointed at statements and the ledger.

See it against your own statements

Send us a month of statements and the matching ledger extract and we will show you what reconciles by rule, what matches, and what is left with a proposed cause against it.

Book a demo

Last reviewed 4 September 2026

A break with a likely cause beats a difference with a number

The problem

What the platform does

What you get

How it works

Collect statements

Apply the rules

Match to the ledger

Investigate the variance