Reconciliation Is Where Payment Margin Quietly Disappears
Most organisations measure their payments capability at the front of the transaction. Approval rates, checkout conversion, gateway uptime, cost per acceptance. Those numbers reach the board. What happens after authorisation almost never does.
Yet that is where the money goes. Once a payment is approved, it still has to be captured, batched, settled, funded, fee-adjusted, matched to an invoice or order, and posted to the ledger. Every one of those steps can fail quietly. When they do, the result is not a declined transaction that someone notices. It is an unmatched line in a settlement file that a finance analyst will spend forty minutes on next Tuesday, and again the Tuesday after that.
This article is about that second half of the payment. It looks at why the payments reconciliation process breaks down, what unmatched transactions and manual exception handling actually cost, and why reconciliation quality is better understood as an operating margin question than a bookkeeping one.
The part of the payment nobody budgets for
Payments operations is the work of keeping the money movement layer accurate, complete and explainable after the customer has already been charged. It covers settlement reconciliation, exception handling, chargeback and dispute reconciliation, fee validation, funding timelines, and the reporting that feeds the finance close.
It is almost never a line item. Acceptance costs are, because they arrive as an invoice. Platform costs are, because someone signed a contract. Reconciliation cost is distributed across four or five people's calendars, a shared inbox, a set of spreadsheets nobody owns, and the last three days of every month. It survives budget scrutiny precisely because it never appears in a budget.
The scale of the manual effort involved is well documented. Kani Payments surveyed 250 UK-based issuers, acquirers, processors, neobanks and e-money institutions for its 2025 Reconciliation and Reporting Survey and found that 56% still rely on spreadsheets for reconciliation. The same research found that managing data and handling exceptions consume the largest share of the time available, and that the average firm spends around three hours simply preparing data before any matching begins.
Read that last figure carefully. Three hours of work before the first transaction is compared to the first settlement record. That is not reconciliation. That is the preparation tax an organisation pays because its payments data quality is inconsistent across the systems the data arrives from.
What actually happens after the authorisation
To understand where matching fails, it helps to be specific about the chain a single card payment travels through.
The customer is authorised. That authorisation is captured, usually later, sometimes days later for goods that ship. Captures are batched and submitted for clearing. The acquirer settles funds, typically net of interchange, scheme fees and acquirer margin, on a settlement cycle that may or may not align with the capture batch. A settlement file lands. The bank statement shows a single aggregated deposit. Meanwhile the order management system holds the original order value, the ERP holds an invoice, and neither of them knows anything about the fee deduction that made the deposit smaller than the sale.
Now add reality. Partial refunds. Multi-currency conversion. A payment made through one channel and refunded through another. A chargeback was raised sixty days later and represented forty days after that. An instalment or subscription plan where one payment fails and retries successfully on a different date. A marketplace payout that aggregates hundreds of underlying transactions across several merchants.
Each of these is normal. None of them is exceptional. But every one of them creates a mismatch between three record sets that were never designed to agree with each other: what the business sold, what the payment provider processed, and what the bank actually deposited.
Straight-through processing is the term for the proportion of these that resolve automatically with no manual intervention. It is the single most useful metric in payments operations, and most organisations cannot state theirs.
Why the payments reconciliation process breaks down
Across most finance and payment operations functions, the failure has four structural causes rather than one.
The first is data asymmetry. The identifier the business uses to track an order is rarely the identifier the payment provider uses to track a transaction, which is rarely the reference that appears on the bank statement. Matching therefore depends on inference: amount plus date plus a partial reference string. Inference works until volume rises or timing shifts, at which point it produces a growing tail of unmatched transactions.
The second is timing. Authorisation, capture, settlement and funding all happen on different clocks. A payment captured on the 31st and settled on the 2nd belongs to one month commercially and another month in the bank. Every month-end produces a cohort of transactions that are not errors at all, only in transit and manual processes cannot easily distinguish those from genuine breaks.
The third is fragmentation. Most organisations of any size run more than one acquirer, more than one payment method, and often more than one entity or currency. Each provider issues settlement files in its own format, on its own schedule, with its own fee presentation. Consolidating them is a data engineering problem being solved by finance staff in spreadsheets.
The fourth is ownership. Reconciliation sits at the boundary between finance, operations and technology, and boundaries are where accountability thins out. Finance owns the ledger. Technology owns the integration. Operations own the customer outcome. Nobody owns the match rate.
Exception handling is the real cost centre
An unmatched transaction is not expensive. An exception process is.
When a break appears, someone has to classify it, investigate it, find the counterpart record, decide whether it is a timing difference, a fee variance, a duplicate, a missing capture, a refund posted against the wrong original, or genuine loss. That investigation requires access to at least two systems, often three, and usually a portal login that one person on the team has.
The cost compounds in four directions.
It consumes qualified finance headcount on mechanical work. The people best equipped to investigate a payment break are typically the same people you would rather have doing analysis, forecasting or controls design.
It delays the finance close. Reconciliation is a gate. Nothing downstream, management reporting, revenue recognition, cash forecasting, can be finalised while the payment position is uncertain, so the whole close waits on the slowest break.
It conceals revenue leakage. This is the part that turns a back-office issue into a margin issue. Fee variances that are individually trivial are invisible individually. An acquirer applying a slightly different rate than contracted, a downgrade to a more expensive interchange category because a data field was not populated, an FX margin applied twice, a refund processed without the corresponding fee refund, none of these announce themselves. They are only visible when settlement is reconciled at transaction level against expected fees, which is precisely what manual processes cannot do at volume. Organisations that never reconcile to that depth do not discover leakage. They simply never see it.
And it degrades dispute reconciliation. Chargebacks arrive with their own lifecycle, their own deadlines and their own financial adjustments. Where the underlying transaction cannot be matched cleanly, representation becomes slower and weaker, and losses that were defensible become written off because nobody could assemble the evidence in time.
The finance close is where the damage becomes visible
Most finance leaders first encounter the reconciliation problem as a timing problem. The close takes too long. The cash position is unreliable until day six. The audit request for transaction-level support turns into a three-day archaeology exercise.
What is actually being observed is the accumulated cost of a low straight-through processing rate. Every percentage point of transactions that fails to match automatically becomes manual work, and manual work has to happen somewhere in the calendar. It happens at close.
The useful reframe for a controller or CFO is this: the number of days your close takes is partly a function of your match rate. Improving the match rate does not just reduce headcount pressure, it moves the date on which the organisation can trust its own numbers. In a business where working capital decisions, supplier payments and forecasting all depend on that date, faster and more reliable settlement reconciliation has a direct commercial value that has nothing to do with accounting tidiness.
Why acceptance economics change in Australia from October 2026
There is a specific Australian reason this is moving up the agenda now.
On 31 March 2026 the Reserve Bank of Australia published the Conclusions Paper for its Review of Merchant Card Payment Costs and Surcharging. The Payments System Board decided to remove surcharging on debit, prepaid and credit cards across the designated eftpos, Mastercard and Visa networks, to lower the caps on interchange fees paid by Australian businesses, and to increase transparency over the fees charged by card networks and payment service providers. Most of these changes, including the removal of surcharging and the reduced domestic interchange caps, take effect on 1 October 2026, with an interchange cap on foreign cards and some transparency changes following on 1 April 2027.
The interchange reductions are helpful. The surcharging change is structural. For any merchant that has been passing acceptance costs to customers, those costs stop being a pass-through and become an absorbed cost of doing business, sitting directly in the margin line.
That single change alters what reconciliation is worth. When acceptance cost is recovered at the point of sale, a fee variance is an inconvenience. When it is absorbed, a fee variance is margin. An organisation that cannot verify, at transaction level, that it was charged what it agreed to be charged is now carrying an unmeasured cost in its gross margin rather than in a surcharge line.
The transparency measures cut the same way. Better published fee data is only useful to a business that can compare it to what it actually paid. That comparison is a reconciliation capability. The RBA has also signalled a further public consultation from mid-2026 covering areas not addressed in this review, including mobile wallets, three-party card networks, buy-now-pay-later services and e-commerce platforms, which suggests the fee and data landscape will keep moving rather than settle.
ISO 20022 and the quiet improvement in payments data quality
The second structural shift is in the data itself.
The coexistence period for SWIFT's migration to ISO 20022 ended on 22 November 2025, after which cross-border payments and associated cash-management messages moved to structured XML formats rather than the legacy fixed-length MT messages. The point of the standard, from an operations perspective, is that it carries richer, more structured and more granular data: clearly defined fields for parties, addresses, references and remittance information instead of free-text lines that had to be parsed by convention.
Better structured remittance data is exactly what an automated matching engine needs. It replaces inference with identity. Where a matching rule previously had to guess that a payment for a certain amount, on a certain date, with a partial reference in a free-text field, corresponded to a particular invoice, structured remittance information can carry the reference explicitly.
This is why the standard is consistently associated with higher straight-through processing and fewer manual investigations. The important qualification is that the standard makes better matching possible; it does not make it happen. An organisation that receives ISO 20022 messages and immediately flattens them into the same legacy fields its ERP has always used will capture none of the benefit. The data quality improvement has to be carried through the whole chain, from message ingestion to matching rules to what is stored against the ledger entry.
The rise of payments operations as a discipline
Step back from any single reform and a clear direction emerges. Payments operations is separating out from general finance operations and becoming a discipline in its own right, with its own metrics, tooling and ownership.
The pattern looks familiar to anyone who watched IT operations mature. Work that was once distributed across several teams as an unglamorous overhead gets consolidated, measured and automated once the cost of not doing so becomes visible. In payments, that consolidation is being driven by four pressures at once: transaction volumes rising faster than finance headcount, payment methods and providers proliferating, absorbed acceptance costs replacing recovered ones, and regulators expecting demonstrable control over financial operations.
The operating model that results has a recognisable shape. Reconciliation is continuous rather than periodic, because files can be ingested and matched as they arrive rather than compiled at month-end. Matching is rule-driven and tiered, so that the ninety-odd percent of transactions that are unambiguous never touch a human. Exceptions are treated as a managed workflow, classified, routed to an owner, aged, escalated and reported on, rather than as an undifferentiated inbox. Fee validation is automated against contracted rates rather than assumed. And the match rate itself becomes a reported operational metric, tracked over time and by provider, in the same way an IT function tracks incident volumes.
What that model buys is not primarily accuracy. Manual reconciliation, done by careful people, is usually accurate in the end. What it buys is capacity, speed and evidence: fewer hours consumed, a shorter close, and a defensible record of what was reconciled, by whom, and when.
It is worth naming what this is not. It is not simply buying reconciliation software. Automated matching applied to poor reference data produces automated mismatches at greater speed. The sequence that works is unglamorous: fix the reference data that flows into the payment first, then define the matching rules, then automate the exceptions workflow, and only then consider whether the tooling needs to change. Back-office automation applied on top of an unexamined process tends to industrialise the process's existing flaws.
The governance dimension
There is also a control argument that has become harder to ignore in Australia.
APRA's Prudential Standard CPS 230 has, since 1 July 2025, required regulated banks, insurers and superannuation funds to manage operational risk and maintain critical operations through disruption, with clear accountability and evidence. Payment processing and settlement sit squarely inside that expectation for any regulated entity.
An organisation that reconciles manually can usually demonstrate that its numbers are right. It often cannot demonstrate how they became right, which controls ran, which exceptions were identified, who cleared them, and on what basis. An automated reconciliation process produces that evidence as a by-product of the work rather than as a reconstruction afterwards. For regulated entities, and increasingly for anyone facing a rigorous external audit, that difference is the difference between an assertion and a control.
What Australian finance and payments leaders should take from this
The specific platform matters far less than the diagnostic questions, and they are the same regardless of what you run today.
What is your straight-through match rate, by provider and by payment method, and is it moving? If nobody can answer that, that is itself the finding.
How many hours per month go into exception handling, and what is the ageing profile of open exceptions? Exceptions that are consistently cleared within days are a working process. Exceptions that sit for weeks are unrecognised losses waiting to be written off.
Do you verify fees at transaction level against contracted rates, or do you accept the net settlement figure as given? From October 2026, for merchants that previously surcharged, this question moves from procurement hygiene to margin protection.
Can you produce, without a special project, the full lifecycle of a single payment, authorisation, capture, settlement, fee, ledger entry, and any dispute, for an auditor or a regulator?
And when a break is resolved, does anything change upstream so that the same category of break stops recurring, or does the same exception type reappear next month?
Getting payments operations right
The outcomes worth aiming for here are commercial before they are technical: a shorter and more predictable finance close, finance capacity returned to analysis rather than matching, recovered margin from fee and settlement variances that were previously invisible, faster and better-evidenced dispute reconciliation, and a control environment that can be demonstrated rather than asserted.
Getting there is largely an implementation problem. Matching rules that are too loose create false matches, which are considerably worse than exceptions because they hide rather than flag. Rules that are too tight generate exception volumes that overwhelm the team they were meant to help. The right thresholds depend on your payment mix, your providers, your settlement timings and your tolerance for manual review, which is why this is designed around an organisation rather than switched on from a template.
This is where implementation experience counts. Conexxia provides payments operations consulting to Australian banks, insurers, telcos and travel businesses, connecting payment platforms, core banking systems and ERP tooling so that matching, exception handling and settlement reporting run as one dependable process rather than a monthly scramble. It is the same approach we bring across payments consulting, from payments orchestration and payments infrastructure modernisation through to cross-border payments and payments compliance and risk.
None of this requires replacing what already works. Most organisations get there by measuring the match rate first, cleaning the reference data that flows into the payment second, and only then deciding whether the existing tooling can support a genuinely automated reconciliation process.
If your settlement files and your ledger are still telling two different stories at month-end, that gap is the place to start.
Aftab Khan
Head of Payments Consulting
On a mission to help change the world, one experience at a time
I collaborate with progressive businesses to deliver successful business outcomes in 4 key areas: Increasing Revenues, Improving Operational Efficiencies, Regulatory Compliance and Elevating Customer Experience, leading to sustainable business growth.
Comments