Reconciliation Is Becoming an Engineering Function, Not a Finance One

The framing is wrong. The industry has been debating whether reconciliation tooling belongs in the CFO's software budget or the payments platform roadmap, as if it's a procurement question. It isn't. The question is architectural: whether reconciliation is treated as a reporting layer sitting on top of a payments stack, or as a data consistency guarantee built into the stack itself. The teams who understand the difference are building very different infrastructure from the ones who don't.

The catalyst for this shift is not transaction volume. High-volume merchants have always had complex reconciliation workflows. The catalyst is payment method fragmentation, and specifically what fragmentation does to settlement behavior across a modern multi-channel, multi-PSP stack. When a merchant operates across cards, BNPL, local bank transfers, real-time payments, wallets, and in-store POS, they are not simply adding more columns to the same spreadsheet. They are inheriting fundamentally different settlement timing models, data schemas, lifecycle event sequences, and FX exposure windows, each with its own failure modes. Spreadsheets don't fail at that problem because they're insufficiently powerful. They fail because the problem is not a calculation problem. It's a data consistency problem.

‍

Why Does Settlement Complexity Scale Non-Linearly?

Card payments settle on a D+1 or D+2 basis through acquiring. Instant payment rails settle in seconds but batch their reporting differently by scheme. BNPL providers settle net of financing costs on schedules negotiated per merchant. Local bank transfers in markets like the Netherlands' iDEAL, the eurozone's SEPA Instant, or the UK's Faster Payments each carry their own notification timing, reversal mechanics, and intermediate state representations. Chargebacks on cards have a 120-day lifecycle. Refunds on digital wallets may hold intermediate states that PSPs communicate inconsistently.

Now layer omnichannel on top. A POS terminal at a physical retail location typically batches settlements end-of-day. An e-commerce checkout connected to the same acquirer may settle individually per transaction. If a single customer transaction is initiated in-store but completed through a mobile app (click-and-collect, BNPL flow, pay-later QR), the originating system and the settlement system may not agree on which channel owns the event. The same acquirer, same card network, same merchant, but the settlement file maps to a different internal cost center, lands in a different currency, and arrives on a different schedule.

The operational consequence is that each added payment method multiplies the number of event types that need to be tracked, the number of terminal states a transaction can occupy, and the number of schema variants that have to be normalized before any matching can happen. Finance teams encounter this as an expanding manual workload at month-end. What's actually happening is that the reconciliation surface area is growing combinatorially while the underlying tooling remains linear.

‍

The Spreadsheet Failure Mode Is Structural, Not Operational

The standard diagnosis for reconciliation failure is volume: too many transactions for manual processes to absorb. That's accurate as far as it goes, but it misses the structural failure, which is that spreadsheet-based reconciliation assumes a static, synchronous view of payment state. A transaction either happened or it didn't. Settlement either arrived or it didn't.

A modern payment stack doesn't look like that. Payment lifecycles are asynchronous. A payment that is authorized is not necessarily captured. A payment that is captured is not necessarily settled. A settlement that arrives is not necessarily reconcilable against the original transaction without a chain of intermediate events: some delivered by webhook, some by batch file, some by API poll, some arriving out of order. The PSP's settlement file and the card scheme's interchange file represent the same transaction from different perspectives, on different schedules, with different identifiers.

This is the engineering problem that finance teams are running into when their spreadsheets break. The problem isn't that the spreadsheet is the wrong size. It's that the data model behind it can't represent the actual state of a payment at a point in time. A row in a spreadsheet is a snapshot. A payment is a state machine. Reconciliation is the process of confirming that all the state transitions that should have happened, did happen, in the right order, against the right amounts.

That is a software engineering problem. It requires event tracking, state management, schema normalization across heterogeneous sources, idempotency guarantees on webhook ingestion, and a canonical data model that survives the underlying settlement rails changing underneath it.

‍

PSP Schema Fragmentation Is the Invisible Tax

Every PSP that a merchant integrates sends settlement data in its own schema. Transaction identifiers don't cross PSP boundaries. Refund events are represented differently: some PSPs send a separate refund event, others modify the original transaction record, others send both and expect the merchant to deduplicate. Chargeback lifecycle events are even more inconsistent: the number of states, the naming conventions, and the timing of dispute-window notifications vary by PSP, by card scheme, and by region.

When a merchant runs three PSPs, they are maintaining three independent representations of payment reality. Without a normalization layer that precedes reconciliation logic, matching is done heuristically: approximate identifiers, fuzzy timestamp matching, manual exception queues. The match rate sounds acceptable until the CFO asks why the FX gain/loss variance can't be attributed at the transaction level, or until a dispute response deadline is missed because the chargeback event landed in a settlement file format that the finance team's tooling doesn't parse cleanly.

The solution that's emerging is an orchestration-layer event model: a canonical internal representation of payment events that normalizes across PSP schemas before anything touches finance systems. The reconciliation products now being packaged inside unified payment infrastructure are built on exactly this premise: pull settlement data from PSPs, normalize it into a single ledger, and surface discrepancies before they become month-end problems. The reconciliation function becomes reliable not because the finance tooling is better, but because the event data flowing into it has been standardized upstream.

‍

What Does Reconciliation-as-Infrastructure Actually Require?

The organizational shift toward engineering ownership of reconciliation is not primarily a structural decision about who owns which budget line. It is a consequence of what modern reconciliation actually requires: a real-time, event-driven data layer that captures every state transition in a payment's lifecycle, enriched with the data needed to match it downstream.

That is infrastructure. It requires the same engineering disciplines as any other reliability-critical system: idempotent event ingestion (so that a webhook delivered twice doesn't double-count a settlement), deterministic state machines (so that a transaction in “pending settlement” can be unambiguously distinguished from one in “settled with pending chargeback”), and durable storage that preserves the full event history rather than a collapsed current state.

This is not a cheap position to adopt. Building a canonical event layer is heavier upfront engineering than licensing a reporting tool that reads PSP settlement files, and it is slower to show results: the reporting tool demos in a week, the event model takes a quarter. The reason the math has flipped is that the reporting tool's cost compounds. Every new payment method, every new PSP, every new settlement schedule adds another manual reconciliation path that someone maintains by hand, and that maintenance burden grows combinatorially while the event-model investment is paid once and amortized across every rail added afterward.

None of this can be bolted onto a PSP's settlement file export. It has to be designed into the payment platform from the point where events are first observed. A payment that settles through a stablecoin bridge after originating on a domestic instant rail and being captured by a card acquirer (a settlement path that is not speculative in 2026) produces events across three different systems, in three different schemas, with three different latencies. The reconciliation model has to treat that as a single transaction with annotated rail-level events, not as three separate settlement records that a finance analyst manually assembles into one row.

Recent industry work on multichannel reconciliation makes the same point from the omnichannel angle: the challenge of unifying POS, e-commerce, and app payments isn't primarily about connecting to more PSPs. It's about creating a single normalized event layer that sits above channel-specific settlement behaviors and makes them legible as one operation. The insight is the same whether you approach it from orchestration infrastructure or from omnichannel finance tooling. The abstraction layer has to exist at the event level, not at the reporting level.

‍

What Does This Mean for Treasury and Working Capital?

The consequences of getting this right or wrong are not confined to month-end close accuracy. Reconciliation that runs on reliable event infrastructure changes what finance operations can actually see.

Real-time settlement state visibility changes treasury decisions. If a merchant knows that $2.4 million in e-commerce settlements are confirmed and in transit while $600,000 in POS settlements are still in a batched D+1 window, those are different liquidity positions. The working capital implication of knowing, versus approximating, is significant at scale. The figure from J.P. Morgan's Payments Outlook 2026, that only 39% of treasury organizations describe their systems as mostly or fully automated against 87% claiming some automation, is a measure of the gap between having data and having data that is reliable enough to act on without a manual confirmation step.

FX exposure management has the same dependency. When a settlement arrives from a European PSP in euros, converted at a rate the PSP chose at a moment the merchant didn't control, the exposure gap is not visible until the settlement file arrives, often days after the transaction. A merchant with an event-driven reconciliation layer can observe the FX conversion event in near real-time, attribute the exposure at the transaction level, and make hedging decisions against actual settlement data rather than estimates. That is a treasury capability, not a reporting capability, and it only exists if the infrastructure underneath it captures FX events at the right granularity.

Dispute response timelines are directly affected too. The window to respond to a chargeback is measured in days or weeks depending on the card scheme and the reason code. A reconciliation system that ingests dispute events in real-time and surfaces them with the original transaction context routes disputes to resolution faster than one that surfaces them in a weekly batch export. At sufficient volume, the revenue impact is material.

‍

The Organizational Transition That's Already Happening

The productization signal from the orchestration vendors now packaging reconciliation as infrastructure rather than reporting reflects something that enterprise payments teams are reporting from the operational side: reconciliation workflows have crossed a complexity threshold that finance operations alone cannot own. The tooling investment is following where the operational load has already migrated.

What that looks like in practice is that platform engineering teams increasingly own the ledger integrity guarantees (the event model, the normalization layer, the idempotency infrastructure) while finance teams own the policies that sit above it: exemption logic, FX strategy, dispute escalation criteria. The boundary between them is the canonical event stream. Engineering guarantees its reliability. Finance consumes it.

The teams that have deferred this architectural decision are not avoiding it. They are making it by default, in the direction of manual exception handling, growing reconciliation backlogs, and a month-end process that consumes more hours as volume grows rather than fewer. The infrastructure choice underneath reconciliation is the same class of decision as the smart routing architecture choice described in the orchestration layer discussions that have dominated enterprise payments conversations this year. Both are about whether the abstraction layer gets built deliberately or inherited piecemeal.

Reconciliation is not becoming an engineering function because engineers want to own more of the stack. It is becoming one because the stack now generates a class of data consistency problem that only engineering can solve. The finance team's role doesn't diminish. But their effectiveness now depends on whether the payment infrastructure upstream of them was designed to give them reliable data, or left to give them whatever each PSP decided to send.

That design decision is already being made, across every payments platform in production. The question is whether it's being made consciously.

‍