Payment reconciliation software

The money arrived. Now say what it was for.

Every payment rail can tell you an amount and a timestamp. Almost none of them can tell you which obligation the payment settled — and that gap is where finance teams spend their week. Zetu closes it, and shows its working.

Book a demo See it run

What each rail tells you about the payerIngestion settings · before any matching happens

Payment rails compared by what they reveal about the payer and whether a reference is carried.
Rail	Who paid	Reference	Matching
Card / gateway	The account that was charged	Carried automatically	Self-identifying
Standing order	Fixed, set up once	Usually consistent	Self-identifying
Direct debit / mandate	The mandate holder	Carried by the mandate	Self-identifying
Bank transfer	The sending account name	Whatever the payer typed	Needs interpretation
Mobile money wallet	A phone number and the line's registered name	Optional, and often absent	Needs interpretation
Cash / manual	Whatever was written down	Whatever was written down	Needs a human

Systems built for the top three rails treat the bottom three as edge cases. For most organizations, the bottom three are the business.

The problem

Reconciliation is easy until the payment stops identifying itself.

A card charge tells you exactly who paid, on which plan, against which invoice. A mobile money payment tells you a phone number and an amount. A bank transfer tells you whatever the payer typed into the narration field, which is frequently nothing useful at all.

Software built for the first case treats the other two as edge cases to be handled later. For a great many organizations they are not edge cases — they are most of the money, arriving every month, from people who will be billed again next month.

So the work is not matching payments. The work is everything that happens when a payment will not match, and whether the system makes that work visible or leaves it in somebody's spreadsheet.

A payment provider's job ends when the money lands. Reconciliation starts there.

The hard cases

Nine ways a payment refuses to reconcile itself.

Every one of these is ordinary. A reconciliation tool is worth having only to the extent it has an answer for them that is not 'a person looks at it'.

No reference at all
A wallet number, an amount, and nothing about what it was for.
A reference that means nothing
Payers type what they think identifies them. Often it identifies four people.
Someone else's name on the payment
A spouse, a parent, an employer, a firm. The register has none of them.
One payment, several obligations
An amount that has to be split before any of it is settled.
Part of the amount
Not an exception. A partial settlement that still moves a balance.
Paid before it was billed
There is no open item to match against. The money still belongs somewhere.
The callback never arrived
The payer holds a confirmation. Your system has no record of it.
On the statement, not in the system
Two sources disagree, and only one of them is right.
Paid twice
A duplicate is a refund or a credit, and telling which is a decision.

How it works

Propose, evidence, decide, record.

Four steps, and the third one is a person more often than vendors like to admit.

Ingest every rail into one model

Mobile money, bank transfer, direct debit, standing order, card, gateway and cash arrive as the same kind of object, carrying whatever identity their rail happened to include.

Match deterministically where the rules allow

An exact reference, a registered paying number, an amount that can only be one open obligation. These settle without anyone looking, because there is no judgment in them.

Propose where they do not

Everything else becomes a candidate with a stated confidence and the evidence behind it — payer history, amount, timing, relationships. Including the option of doing nothing.

Hold what cannot be answered

Money that belongs to nobody yet goes to suspense and is reported as its own figure, rather than being netted into revenue or posted somewhere plausible.

Record who decided, and on what

Every allocation, reversal and hold carries a name and a timestamp, and the raw provider record is kept beside Zetu's reading of it.

Payments · this morningUnfiltered · newest first

$240Needs review
pmt-4471Mobile money••• ••• ••4 11806:14
No reference. Wallet number matches Priya Raman — amount equals her annual dues.
95% confidence
$5,400Reconciled
pmt-4468Bank transferNorthbridge Design Partners07:02
Corporate membership. Allocated across 18 member accounts.
$50Unallocated
pmt-4474Mobile money••• ••• ••9 03208:37
No reference, no matching account, amount matches no obligation.

Showing 3 of 214 received today

Evidence

A match you cannot explain is not a match.

Auto-posting a probable answer moves the problem rather than solving it: the balance is now wrong somewhere else, and nobody knows why.

Where a match is inferred rather than proven, Zetu shows what it is inferring from — the paying number on file, the amount against the open obligation, the payer's history, the relationship to the account — and names its confidence in plain terms.

The alternatives are shown too, including holding the payment. That matters more than it sounds: an operator with one button labelled “accept” is being asked to rubber-stamp, not to decide.

How reconciliation works in Zetu

Payment · needs reviewReceived 06:14 · queued to youAssigned

$240pmt-447195% confidence

Rail: Mobile money
Reference: None supplied
Payer name on rail: P. RAMAN
Payer number: ••• ••• ••4 118

Why Zetu thinks so

The paying number is on Priya Raman's account as a registered contact.contact.wallet_match
The amount equals her annual dues exactly, to the cent.amount.exact
Her dues obligation is 31 days overdue and unpaid.obligation.open
She has paid from this number in each of the last three years.history.recurring

And why it is not 100%. The name on a mobile money payment is the registered owner of the wallet, not necessarily the payer. Zetu proposes; a person with authority decides.

Accepting this records who accepted it, when, and on what evidence. So does rejecting it.

Try it

Here is $240. Would you post it?

This one runs. Press the control, read the evidence, and make the call yourself — then try the other answer.

Holding the payment in suspense is a complete, correct outcome with its own audit trail. It is not a failure state, and a reconciliation tool that treats it as one will teach your team to guess.

Payment · try the decisionpmt-4471received 06:14

$240Unmatched

Rail: Mobile money
Reference: None supplied
Payer on rail: P. RAMAN
Payer number: ••• ••• ••4 118

This is what the rail actually handed over: an amount, a wallet number, and a name that belongs to whoever registered the wallet. Nothing here says what it was for.

A demo, running on fixed evidence — not a live account. The behavior is the real one: Zetu proposes a match, a person with authority decides, and the decision is written down with the evidence it was made on.

Questions

Payment reconciliation, answered plainly

What does payment reconciliation software actually do?

It compares what an organization is owed against the money that arrived, decides which obligation each payment settles, and surfaces everything it cannot decide. The comparison is the product. Recording that a payment arrived is something a payment provider already does for you; saying what the payment was for is the part that is normally done by hand.

How is this different from bank reconciliation?

Bank reconciliation compares your ledger against your bank statement — two records of the same movements, checked for agreement. Payment reconciliation asks a different question: which customer obligation did this money discharge? You can be perfectly reconciled to the bank and still be unable to say who has paid their dues. Most organizations need both, and only one of them is normally automated.

Can it handle payments with no reference or a wrong reference?

That is the case it exists for. Unreferenced payments are matched against registered paying numbers, amounts, timing, payer history and account relationships, and the evidence behind each candidate is shown to the person accepting it. Where nothing is conclusive the payment is held in suspense and reported as such, rather than being posted somewhere plausible.

Does it post matches automatically?

Deterministic matches — an exact reference, a registered paying number, an amount that can only be one obligation — reconcile without anyone looking. Probabilistic ones do not. A 95% match is still wrong about one time in twenty, and at any volume that is too often to post by itself when the decision changes someone's balance, standing or access. Zetu proposes, a person decides, and both are recorded.

Which payment methods does it reconcile?

Mobile money, bank transfer, direct debit, standing order, card, payment gateways and cash recorded by hand. The point is not the length of the list — it is that all of them land in one financial model, so a partial payment by wallet and a bank transfer against the same account are the same kind of object by the time anyone reports on them.

Do we have to change payment providers?

No. Zetu does not move money and takes no custody of it. It reads what your existing providers report, which is what makes changing provider later a configuration change rather than a migration.

Bring us one messy month.

Bring one month of obligations and one month of payments. We will show you what reconciles, what does not, and what that is costing you.

Book a demo Talk to us