There is a slew of spreadsheet reconciliations sitting alongside almost every enterprise reconciliation platform in financial services. Operations teams know these spreadsheets are there. Technology teams know they are there. Platform vendors know they are there. And in many cases, everyone has quietly accepted these spreadsheets’ existence.
It is not there because current platforms cannot process the data. It is not there because the operations team lacks the expertise to migrate it. It is there because, when the business case is evaluated, bringing that reconciliation onto the platform often costs more in specialist resources, vendor engagement, implementation efforts, and change management than leaving it where it is.
For many firms, maintaining a tactical process outside the strategic control environment becomes an economically rational decision.
That is not fundamentally a technology problem. It is a cost model problem. And it has been embedded in reconciliation infrastructure across the financial services industry for the better part of two decades.
What the specialist tax actually is
Most reconciliation platforms in production today were built around a core assumption: that meaningful configuration requires specialist expertise.
Implementing a new reconciliation meant engaging the vendor or having readily available, enabled and dedicated support team in house. Modifying the matching logic required a formal change request. Onboarding a new data source became a project. Extending coverage to a new asset class, counterparty, or business line meant scoping sessions, implementation timelines, and incremental cost.
Viewed individually, none of these requirements were unreasonable. Afterall, reconciliation environments could be complex. The underlying data is often sensitive. Control frameworks demand a high degree of accuracy and governance. The specialist’s involvement was a logical design choice.
The cumulative effect, however, was significant. Embedded within platform architectures, service models, and implementation methodologies was a hidden cost borne by operations teams. Call it the specialist tax: the overhead created not by the complexity of the reconciliation itself, but by the effort required to configure, maintain, and evolve the technology supporting it.
Operations teams have been paying that tax for years. Most have learned to work around it through manual processes, spreadsheet-based controls, and reconciliations that never quite justified the cost of platform onboarding. The tax was real, but often difficult to measure. It appeared in headcount growth, slower delivery cycles, and the long list of reconciliation initiatives that remained permanently on the roadmap.
What it actually costs
The specialist tax rarely appears as a single budget line item. Instead, it accumulates across the reconciliation lifecycle in ways that are difficult to quantify and easy to underestimate.
-
Time to onboard. A new reconciliation control, a new counterparty, asset class, business process, or long-running spreadsheet-based reconciliation has historically taken weeks or even months to onboard onto a platform. That timeline is rarely driven by the complexity of the reconciliation itself. More often, it is driven by the implementation process: scoping, resource allocation, configuration, testing, governance, and sign-off. Much of that effort exists because specialist involvement is required at every stage.
-
Specialist dependency. Many operations teams carry a structural dependency on a small group of platform specialists with the knowledge required to configure and maintain reconciliation controls. When those resources are constrained, delivery slows. When they leave, critical expertise leaves them. When the business wants to expand coverage, requests are entered into a queue. Over time, the reconciliation platform becomes a bottleneck to operational change rather than an accelerator of it.
-
The reconciliations that never made it onto the platform. This is perhaps the most overlooked cost. Spreadsheet-based reconciliations that continue to run outside the strategic control framework. Manual processes that persist because onboarding costs cannot be justified. Each represents operational risk that the platform was intended to address, but did not, because the economics of implementation worked against adoption.
-
Control gaps. When extending coverage requires a formal project, teams inevitably make prioritization decisions. Some reconciliations are deferred. Some controls are never implemented. In those cases, the specialist tax does not simply increase cost and slow delivery; it influences which risks are controlled, which are accepted, and where gaps remain within the operating model.
I’ve worked with clients over the years who have spent in excess of €20 million annually, on their reconciliation technology stack alone, including the full complement of infrastructure and technical teams required to keep the underlying hardware and reconciliation software operational and supported. These numbers excluded all the operations resources performing the reconciliations and investigations of the breaks.
Why this was accepted for so long
The specialist tax persisted largely because it was universal. Every reconciliation platform imposed some version of it. Every operations team absorbed it. With no credible alternative available, the associated cost came to be viewed as an inherent part of operating complex reconciliation infrastructure rather than a design choice that could be challenged.
Like many structural costs, it also benefited from the inertia of the status quo. The existing model was well understood, while alternatives carried uncertainty. Organizations that had built operating processes, governance frameworks, and delivery models around specialist dependency were unlikely to disrupt them based solely on the promise of a different approach.
Today, that equation is beginning to change.
The cost structure is different now
The assumption that reconciliation platforms require specialist involvement for configuration and change is no longer universally true. The boundary between what can be managed by business users and what genuinely requires technical expertise has shifted materially and with it, the economics of reconciliation operations.
Reconciliations that once required formal projects to onboard can now be configured and deployed in days rather than months. Spreadsheet-based controls that historically remained outside the platform because the implementation effort could not be justified can now be brought into the strategic control framework without extensive vendor engagement or specialist intervention. Operations teams can extend coverage, adjust controls, and respond to changing business requirements without entering a development queue.
This is more than an incremental efficiency gain. It represents a fundamental change in the cost structure of reconciliation management. The economic barrier that once made it rational to leave reconciliations in spreadsheets or manual processes is beginning to disappear. As that barrier falls, so too does the rationale for maintaining controls outside the platform.
This does not eliminate the need for specialists. Complex reconciliation challenges, large-scale intersystem reconciliations, sophisticated matching scenarios, and highly bespoke control requirements will continue to benefit from deep technical expertise. What changes is that specialist resources are focused where they add the most value, rather than being consumed by routine configuration and maintenance activities.
The result is a reconciliation operating model that scales more effectively, adapts more quickly to business change, and enables operations teams to move at the pace of the business rather than the pace of the implementation queue.
The infrastructure question that comes next
Much of the conversation around financial operations is now focused on AI. But before AI can deliver meaningful value, a more fundamental challenge must be addressed: the quality and accessibility of the underlying data.
In post-trade operations, AI is only as effective as the control environment beneath it. Clean, reconciled, auditable data is not a future aspiration; it is a prerequisite. Almost every credible AI initiative ultimately encounters the same reality; the reconciliation problem must be solved before the AI problem can be.
That requires more accurate matching. It requires reconciliation infrastructure that can be continuously adapted as data sources, products, counterparties, and operational requirements evolve. If extending coverage remains dependent on specialist resources, implementation of projects, and lengthy delivery cycles, the data foundation remains incomplete.
Viewed through that lens, the specialist tax is more than an operational inefficiency. It is a constraint on an organization's ability to build the trusted, governed data environment that next-generation operational capabilities depend on. Reducing that dependency does not simply improve efficiency; it accelerates the creation of a more complete and reliable control framework.
Removing the specialist tax matters in its own right. It also happens to be a prerequisite for what comes next.
The spreadsheet is a symptom
The spreadsheet reconciliation sitting beside the platform is not the problem. It is the symptom, and it exists because, for years, the economics of reconciliation favored leaving certain controls outside the strategic platform. The technology was available. The business case often was not. When onboarding a reconciliation required specialist resources, vendor engagement, and months of effort, leaving it in a spreadsheet became the rational choice, even when it was not the right one.
That reality was shaped by two decades of platform design built around specialist dependency. The result was reconciliation infrastructure that became increasingly expensive to extend, slower to adapt, and less comprehensive than firms intended.
Today, the economy is changing. The cost of bringing reconciliations into the control framework is falling, and with it, the justification for maintaining manual and spreadsheet-based processes alongside strategic platforms.
The firms that recognize this shift early will not simply reduce operational overhead. They will build more complete control environments, accelerate change, and establish the trusted data foundation that future operating models depend on.
For 30 years, Gresham has been delivering reconciliation solutions across complex financial services environments, supporting 315 clients in 30 countries. If you're evaluating where specialist dependency is creating cost, complexity, or control gaps within your reconciliation estate, we'd welcome the conversation.
Connect with one of our experts today Contact Us | Gresham
June 18, 2026
Julian Trostinsky - Global Director - Solutions Engineering
Julian Trostinsky is a Global Director of Solutions Eng..
Learn more
Our Editorial Process