The Question That Wouldn’t Go Away

A few months ago, I participated in an ARM industry webinar focused on a topic that most people outside of finance rarely think about: how to properly maintain and reconcile multiple trust bank accounts across multiple clients, with payments flowing through multiple third-party processors.We discussed internal controls, segregation of funds, and the mechanics of ensuring that client trust balances were complete and accurate – regardless of whether a payment arrived via a primary processor, a secondary processor, a direct wire transfer, or even a daily deposit of paper checks received in the mail. Those checks, despite every prediction to the contrary, still persist.

I followed that discussion with a blog post outlining a tiered trust account structure designed to make the route a payment takes visible: processor-based settlement versus direct bank receipt, electronic versus physical, aggregated versus individual. The goal was pragmatic – to make reconciliation manageable and defensible in a high-volume, regulated environment.

That work reflected a deeply ingrained assumption in the ARM industry: reconciliation is unavoidable. We accept that maintaining trust accounts means reconciling bank activity – daily, weekly, monthly – because that is simply “how it works.”

But the more time I spent designing controls and reconciliation structures, the more a different question surfaced – one that extends far beyond collections.

Why is this necessary at all?

What business doesn’t reconcile bank accounts? From the smallest family-owned operation to the largest global manufacturer, reconciliation is treated as a universal fact of life. It consumes hours of staff time every month. It generates spreadsheets, manual checks, exception lists, and review sign-offs.

And yet, we now operate in a world of highly sophisticated payment systems. We have real-time authorization, rich transaction metadata, global settlement networks, digital wallets, AI-driven tooling, and entire fintech ecosystems devoted to optimizing how money moves.

So why – after all of this innovation – do accounting teams still spend so much time reconstructing what already happened?

That question sits at the heart of this discussion. The persistence of reconciliation is not evidence of poor discipline or outdated practices. It is evidence of something more fundamental: modern payment systems still do not preserve the identity of money all the way through settlement and funding. Until they do, reconciliation – human or automated – remains a necessary workaround rather than a solved problem.

Back to Basics  –  and the Control That Still Breaks

Around the same time, I wrote another piece arguing for something decidedly unglamorous: getting back to basics with internal controls. Not new frameworks. Not new technology. Just the fundamentals – mapping a process end to end, identifying each handoff, and understanding what data enters and exits at every stage.

When you do that exercise honestly, the soft spots reveal themselves quickly. You see where assumptions are made, where ownership blurs, and where information degrades as it moves from one system to another.

The tools for addressing those risks are well established. Input controls to ensure accuracy and completeness at the point of entry. Processing controls to ensure data is transformed correctly. Output controls to ensure results are complete, accurate, and delivered to the right place. These concepts are not novel, and they are not industry-specific. They apply equally in manufacturing, financial services, healthcare, technology, and government.

Internal control design is, by nature, never finished. Processes evolve. Volumes change. Systems are replaced. The discipline of mapping, testing, and refining controls is ongoing.

Which brings us back – again – to bank reconciliation.

If one were to step back and apply classic control thinking to the reconciliation process, the question becomes uncomfortable: what is the reconciliation actually compensating for?

In theory, a bank reconciliation is an output control. It exists to ensure that what the organization believes happened with cash matches what actually happened at the bank. But output controls are supposed to validate outcomes, not reconstruct them. When reconciliation requires significant manual effort – when it depends on timing assumptions, aggregation logic, and human judgment – it is no longer validating a controlled process. It is compensating for a break in the control chain upstream.

If we were mapping any other process and found that the final control required extensive manual reconstruction to prove completeness and accuracy, we would not conclude that the control was sufficient. We would conclude that something earlier in the process was missing or poorly designed.

Yet bank reconciliation has been normalized as an exception to that logic. We treat it as inherently manual, inherently messy, and inherently unavoidable.

What if the most basic control we are missing is not a better reconciliation, but the preservation of identity across the cash process?

If payments enter the system with unique identifiers, pass through multiple intermediaries, and ultimately land in a bank account without a traceable link back to those identifiers, then the system has failed a fundamental control objective: maintaining data integrity across handoffs. No amount of downstream review can fully compensate for that.

Seen through this lens, the reconciliation problem stops looking like a necessary administrative task and starts looking like a symptom. A symptom of processes that were never designed to preserve the identity of money end to end – despite every other aspect of the system being engineered for scale, speed, and sophistication.

That realization reframes the discussion entirely. The persistence of reconciliation is not a failure of discipline or effort. It is the predictable outcome of a foundational control gap that has been accepted for so long that it no longer feels like a gap at all.

Why Reconciliation Still Breaks at Scale

To understand why, it helps to trace the payment process end to end.  Every electronic payment has an identity at the moment it is taken. When a customer pays by credit card, debit card, ACH, or wallet, the system assigns an identifier. The payment processor confirms the transaction. The accounting system records the amount, the customer, and the date.

Days later, though, when the money actually arrives in the bank that identity is often gone. What remains is a single aggregated deposit, disconnected from the individual payments that created it.

Finance teams are left to reconstruct what happened after the fact, using timing assumptions, batch totals, and manual work. Over time, this reconciliation effort becomes permanent. It is accepted as “the cost of doing business.”

But are we really just living with a deeper design issue in how modern payment systems handle the identity of money?

Scale Has Outpaced Design

Electronic payments now dominate business activity across industries. Cards, ACH, digital wallets, and cross-border rails process billions of transactions per quarter. In the ARM industry we are rapidly and proudly multiplying those transactions. At the same time, the payments value chain has become increasingly fragmented: gateways, processors, networks, settlement agents, sponsoring banks, wallets, and correspondents all participate in moving value from payer to payee.

These systems are highly optimized for throughput, reliability, fraud mitigation, and consumer experience. They are far less optimized for what happens downstream, once the money leaves the payment stack and enters the accounting system.

As payment volume grows, reconciliation effort scales linearly with transaction count, not transaction value. A business processing ten payments per day can reconcile informally. A business processing thousands per day cannot. At scale, missing links in the process flow are no longer an inconvenience, but an operational and control problem.

The Assumption Nobody Questions

Modern payment systems are built around this quiet assumption: aggregation is sufficient.

Transactions are authorized individually but settled in batches. Settlement batches are grouped into payouts. Payouts become bank deposits. That is efficient in processing.  And at each step, identifiers do exist, but they are rarely preserved across the flow. That makes it difficult for an accounting system to deterministically link an individual payment to the deposit that funded it.

The implicit assumption is that differences are tolerable, attributable to timing or other variances that can be explained.

This assumption works reasonably well in low-volume or low-risk contexts. It fails as volume increases, complexity grows, or fiduciary responsibility enters the picture.  Try telling the one customer whose payment you can’t find that your system is efficient, just not as effective as we’d like – please try again.

The Lifecycle of a Payment and Where Identity Is Lost

A simplified but accurate payment lifecycle looks like this:

1. Payment capture
   The business system assigns an internal payment ID and sends the transaction to a processor.
2. Processor confirmation
   The processor returns a confirmation or transaction number.
3. Settlement
   Transactions are cleared and grouped internally by the processor into settlement batches, often by rail, cutoff time, or risk profile.
4. Funding
   One or more settlement batches are aggregated into a payout that is deposited into the business’s bank account.

At no point is the payment “lost.” But the identity of the payment – the ability to say this specific transaction funded this specific deposit – often is.

By the time funds reach the bank, the deposit carries a payout reference, not the transaction-level identifiers that accounting systems use. Supporting reports may summarize activity, but frequently omit the join keys required for deterministic reconciliation.

The identity of the payment disappears at funding. 

Why This Creates Manual Work That Never Goes Away

Once identity is lost, reconciliation becomes inferential.

Deposits rarely align cleanly with transaction dates. Batches may include multiple days, multiple payment methods, or multiple business units. Timing cutoffs, weekends, holidays, and processor holds further blur the picture.

Finance teams compensate by summing activity, comparing totals, applying timing assumptions, and manually resolving differences.

This effort exists not because teams are inefficient, but because the system withholds the linkage required to automate the process. As payment volume increases, the reconciliation effort becomes a permanent tax on finance operations.

Why Trust and Fiduciary Accounting Expose the Gap

In Collections – fiduciary environments with trust accounts, client funds, and regulatory oversight – the identity gap becomes impossible to ignore.

In Trusts, funds are not owned by the business. Fees are segregated by design. Completeness and traceability matter more than speed. When deposits arrive without transaction lineage, the result is not just extra work but elevated control risk.

Collection agencies experience this problem acutely, but they are not unique. They simply operate at the intersection of high volume, regulation, and trust – where the consequences of missing identity are most visible.

Wallets and “Modern Payments”: Experience Improved, Reconciliation Unchanged

Digital wallets are often assumed to represent progress in payment infrastructure. From a reconciliation perspective, they largely are not.

Apple Pay and Google Pay are best understood as tokenization and user-experience layers.

Under the hood, they rely on existing card networks and standard processor settlement models. Payments initiated via these wallets are still authorized individually, settled in batches, and funded via aggregated deposits. The identity gap remains unchanged.

Venmo and similar wallets are more nuanced. Internally, they maintain clean transaction lineage. Every transfer has a unique identifier, balances update immediately, and reconciliation inside the wallet ecosystem is trivial.

But when funds exit the wallet and move into the traditional banking system, they do so via aggregated ACH or card settlement. The internal identity does not survive the final boundary.

The same reconciliation problem reappears downstream.

These systems demonstrate something important: we do know how to preserve transaction identity. We simply do not carry that identity across the boundary where accounting depends on it.

AI, Reporting, and the Persistent Misdiagnosis of the Reconciliation Problem

In fintech circles – particularly those focused on customer experience – payments are often framed as a behavioral problem. How frictionless is the interaction? How intuitive is the interface? How likely is a user to complete a payment if the experience “feels right”?

Apple Pay, Venmo, and similar products represent the success of this framing. They have dramatically improved how people initiate payments by reducing cognitive load, minimizing steps, and embedding trust signals. Much of modern fintech innovation rightly focuses here.

At the same time, there is a growing assumption – often implicit – that downstream operational problems like reconciliation are easily solvable with artificial intelligence. If humans can manually reconcile fuzzy deposits to transaction activity, then AI should be able to do it faster, cheaper, and at scale, right?

This assumption overlooks the nature of the problem.

AI can accelerate manual reconciliation, but it cannot eliminate it if the underlying identity gap remains. When transaction-level identity is lost at settlement, there is no definitive data to recover and match. What remains are patterns, timing correlations, and probabilistic matches. AI can and does improve the efficiency of inference, but inference is not the same as traceability.

In other words, AI can be very good at guessing – but it cannot create missing facts. And let’s not get into the early adoption phase hallucination challenges with AI.

At this point, fintech providers often raise a familiar objection: “We provide reporting that helps trace payments.” This is usually true – and beside the point.

Most reporting offered in this context consists of settlement summaries, payout reports, date-based transaction listings, or filtered views that allow humans to manually bridge transactions to deposits. These tools can reduce friction and speed up reconciliation work. But they do not restore the missing identity of the payment.

They preserve the definitive matching problem, rather than eliminating it.

From a systems perspective, this distinction is critical. Reporting that requires a human – or an AI model – to interpret, correlate, and infer relationships is fundamentally different from data that preserves a deterministic join key. The former accelerates reconciliation effort; the latter removes it.

When a processor says “we provide reporting,” what they are often providing is a better lens into the same ambiguity. Individual payments are still aggregated at funding without a transaction-level mapping that ties each payment to the specific deposit that funded it. The burden of reconstruction – whether done by a human analyst, a spreadsheet, or an AI model – remains.

In practice, this is why reconciliation persists as a labor-intensive function even in highly modern payment stacks. Over time the industry has become very good at producing reports that explain what might have happened, without producing data that proves what did happen. So the “back office” behind the curtain persists.

There is also a subtle organizational consequence. No one wants to see the sausage making. Because reconciliation is perceived as a back-office function with low customer visibility, it is often deprioritized relative to front-end innovation. The belief that AI and better reporting will eventually “handle it” reinforces this tendency. The issue is quietly pushed aside, treated as a low-return operational concern rather than a flaw in the financial foundation.

Reconciliation, however, is not clerical work. In regulated, fiduciary, or high-volume environments, it is a core control function. When reconciliation relies on probabilistic logic – human or machine – it introduces risk that no amount of speed can fully offset.

The solution is architectural, not analytical. It requires restoring transaction-level linkage across settlement, not accelerating the reconstruction of what the system failed to retain.

Crypto as a Structural Contrast

It’s fair to ask whether cryptocurrency has already solved this identity problem. Cryptocurrency systems take a fundamentally different approach.

Every transaction has a permanent, immutable identifier. Settlement and funding are the same event. Balances are always provable, derived from transaction history. There is no equivalent of a batch deposit that arrives without lineage.

As a result, reconciliation in crypto systems is largely a matter of verification, not reconstruction.

You check that internal records match the chain. You do not infer how money moved. You know.

But this does not make crypto categorically better. Crypto introduces real tradeoffs in privacy, reversibility, governance, and risk management. Traditional financial systems deliberately avoid these tradeoffs in favor of consumer protection and operational flexibility.

The key lesson from crypto systems: preserving the identity of money end to end is technically possible. The reconciliation burden in traditional finance is not a law of nature. It is the result of design choices.

The Minimal Fix – Not a New Platform

Before going further, it’s worth being explicit about what I am not arguing. I am not suggesting that reconciliation should disappear entirely, or that there will never be exceptions requiring judgment. I am not arguing that payment processors are negligent or acting in bad faith. And I am certainly not arguing that traditional finance should be replaced by cryptocurrency.

The point is simpler, and more fundamental: we have normalized a break in identity across the payment lifecycle and then spent decades building human and technical workarounds to compensate for it. Questioning that design choice is not radical. It is overdue.

Solving this problem does not require radical new design – new payment rails, one deposit per transaction, or full transparency. It only requires one missing bridge. Specifically: a transaction-level mapping that shows which individual payments funded which bank deposit.

This mapping already exists inside processors. It is implicit in their settlement and payout logic. Exposing it would allow accounting systems to deterministically clear pending cash, leaving humans to focus on true exceptions such as NSFs, chargebacks, and holds.

Most reconciliation work could disappear without changing how payments are initiated or settled.

This Is Not a Collections Problem

While collections provides a clear lens, this issue affects businesses of every size and industry.

Small businesses manually reconcile daily card deposits. This is where bookkeepers spend much of their effort at businesses of all sizes. Retailers manage omnichannel settlement across stores, e-commerce, and wallets. Manufacturers reconcile customer ACH receipts. Global enterprises navigate multi-currency funding across correspondent banks, another whole dimension in complexity and translation.

Wherever payments are high volume, electronically settled, and batched at funding, the same identity gap appears. Collections simply sits where the consequences are most visible.

Why This Is a Financial Foundations Issue

At its core, this is not a payments problem. It is a foundational accounting problem.

It concerns identity of value, ledger integrity, stewardship, and system design over heroics. Again, we are dealing with real people’s money and cannot “lose” that perspective. Reconciliation should be deterministic, exception-driven, and boring. The sign of a great process – it seems invisible. If it requires daily reconstruction and teams of bookkeepers or AI interpreters – the foundational process is suboptimal.

A Call to the Ecosystem

You want innovation?  Start with solving a universal pain point. Payment processors can expose the missing linkage. Software vendors can demand it. Finance leaders can stop accepting manual reconciliation as inevitable.

The manual reconciliation tax is not an inherent cost of doing business. It is the cost of ignoring the identity of money. Until payment identity survives settlement, reconciliation will remain a human workaround for a system design failure.