The ERP Is Still There. It Is Just No Longer Alone.
How finance moved from integrated suites to specialist applications—and why the real challenge is now integration, governance, and control.
When I began working in accounting nearly two decades ago, the finance system was often the workplace.
Tally, Oracle, SAP, and similar enterprise platforms were expected to carry a broad range of processes: procurement, Accounts Payable, Accounts Receivable, General Ledger, Fixed Assets, inventory, reporting, and sometimes payroll.
The system may not always have been elegant. Some processes were cumbersome, screens were dense, and customisation could be slow. But the architecture was comparatively easy to understand.
Most roads led into one system.
Today, the picture looks very different.
A modern finance team may use several applications simultaneously: one for procurement intake, another for contracts, another for invoice processing and payments, another for corporate cards, another for billing, another for revenue operations, another for reconciliations, and yet another for planning and reporting.
Eventually, much of that activity still flows into NetSuite, SAP, Oracle, or another ERP.
The ERP has not disappeared.
It is simply no longer alone.
From one suite to an ecosystem
The earlier ERP model was based on integration within a broad enterprise suite. A company could use different modules, but those modules were typically designed to operate within the same underlying environment. Vendor records, journal entries, asset registers, invoice balances, and accounting periods lived within a common system architecture.
The newer model is increasingly composable. Specialist software providers focus on solving particular business problems:
- procurement intake and approvals
- contract lifecycle management
- invoice processing
- payment automation
- spend and corporate cards
- subscription billing
- revenue operations
- payroll
- treasury
- close management
- planning and forecasting
The ERP increasingly acts as the controlled accounting core, while specialist tools handle the workflow surrounding it.
This reflects a structural shift, not an isolated trend. The language of composable finance architecture has moved from analyst commentary into the working vocabulary of ERP vendors, finance technology providers, and the finance teams that use them.
Why specialist applications became attractive
The growth of specialist tools did not occur because companies suddenly stopped valuing integration. It occurred because many teams concluded that the standard ERP module was adequate—but not always excellent—for the process they were trying to improve.
A specialist application can focus intensely on one workflow. An AP platform may provide easier invoice intake, automated reminders, cleaner approval routing, vendor onboarding, payment execution, corporate-card integration, exception reporting, and AI-assisted coding. A procurement platform may offer a more intuitive experience for employees who would otherwise never want to enter the ERP. A billing platform may handle subscription changes, usage-based pricing, amendments, and renewals more naturally than a traditional accounting module.
Specialist applications can deliver:
- deeper process functionality
- improved user experience
- faster implementation
- more frequent product innovation
- less dependence on ERP customisation
- the ability to replace one capability without replacing the whole finance system
The attraction is understandable. Specialist and best-of-breed platforms can provide broader or deeper coverage within specific finance processes. The business case for fragmentation begins with specialisation. But the story does not end there.
The complexity has not disappeared. It has moved.
A specialist tool may simplify the user experience inside one process. At the enterprise level, however, it creates another connection that must be designed, governed, monitored, reconciled, secured, and maintained. The organisation may no longer struggle with one heavily customised ERP module. Instead, it may struggle with several clean-looking applications that do not always agree with each other.
That distinction matters.
Multiple versions of the transaction
Consider a single vendor invoice. Information related to it may exist across several systems simultaneously.
Each system may hold a different part of the truth: purchase approval, contract value, invoice image, coding, payment status, accounting entry, cash settlement.
The problem is not that the data is missing. The problem is that the complete truth is distributed across systems, owners, and timestamps.
The question is no longer merely, “Where is the invoice?”
The question becomes: Which system is authoritative for which part of the invoice lifecycle?
Without a clear answer, users begin comparing screenshots, exports, email trails, and system statuses to reconstruct what happened.
When integration issues become accounting issues
An integration failure is often described as a technology problem. In finance, it quickly becomes an accounting problem. A failed or incomplete integration can produce:
- invoices missing from the ERP
- duplicate postings
- incorrect vendor balances
- delayed payments
- missing approval evidence
- incomplete accruals
- mismatched payment statuses
- reconciliation differences
- close delays
- audit-trail gaps
PwC’s 2025 Digital Trends in Operations Survey (610 respondents) found that integration complexity—selected by 47% of operations and supply chain leaders—was the most common reason that technology investments had not fully delivered expected results. Data issues ranked second at 44%. An overwhelming 92% of respondents cited at least one barrier to expected value.
KPMG has described how the adoption of multiple best-of-breed and cloud-based systems creates more workflows, integration points, and mitigating controls that must all work together across many applications. Where monitoring for processes spanning multiple applications is conducted manually, missed links and unrealised exposures can increase risk.
This is where the practitioner’s perspective becomes important. The procurement tool may be working. The AP tool may be working. The ERP may be working. And yet the overall process may still fail between them.
“The weakness of a modern finance stack is often not inside any single application. It is in the hand-offs.”
The hidden cost of a best-of-breed stack
Each new application is usually justified through its individual business case. That business case may include time saved, better approvals, fewer manual tasks, improved visibility, reduced errors, and enhanced employee experience. But application-by-application evaluation can overlook the cost of the combined architecture.
The real cost may include:
- implementation consultants
- integration development
- connector licences
- administrator time
- user training
- troubleshooting
- access reviews
- control testing
- reconciliation work
- data migration
- renewals
- overlapping functionality
There is also the human cost of tool fatigue. An employee may initiate a request in one platform, approve it in another, review the contract somewhere else, check payment status in an AP tool, and finally look at the accounting result in the ERP. The architecture may be technically modern while the operating experience becomes fragmented.
This does not mean specialist applications are a mistake. It means their full cost is rarely limited to the subscription invoice.
The cost observations above reflect professional experience and are illustrative. The specific cost profile of any finance application investment depends on organisational scale, process complexity, and technical architecture. Entity-specific analysis is required before drawing commercial conclusions.
The ERP’s role is changing—not vanishing
The most useful way to understand the modern finance stack is not as a battle between old ERP and new SaaS. It is a hub-and-spoke model.
The ERP remains the centre because it provides:
- the General Ledger
- controlled accounting periods
- financial-statement structure
- consolidation
- core master data
- audit history
- statutory reporting foundations
- the final accounting record
The surrounding applications provide workflow, automation, specialised calculation, intake, collaboration, user experience, and process analytics.
SAP’s clean core philosophy reflects this direction: keep the central ERP standardised and upgrade-stable, while innovation and differentiation occur around the core through APIs, side-by-side extensions, and modular capabilities. SAP defines a clean core as a system that remains “as close to standard as possible, while running cloud-compliant extensions and integrations.”
As finance architectures become more composable, the ERP may become less dominant as the day-to-day interface for every workflow while remaining central as the controlled accounting system of record. Its role shifts from universal workplace to financial anchor.
Consolidation versus fragmentation is the wrong binary
The choice is often framed as: one integrated suite, or many best-of-breed tools. In reality, neither extreme is automatically superior.
A heavily consolidated ERP may create poor user experience, slow innovation, expensive customisation, dependence on one vendor, and workarounds outside the system. An uncontrolled specialist stack may create vendor sprawl, duplicated capabilities, unclear ownership, inconsistent data, broken integrations, excessive reconciliation, and weak governance.
The mature answer is not maximum consolidation or maximum fragmentation.
It is intentional composability.
That means every proposed application should answer a disciplined set of questions.
A practical decision framework
Before adding a specialist tool, finance and technology leaders should ask:
- Is the current ERP capability genuinely insufficient?
Not inconvenient. Not unfashionable. Materially insufficient.
- Is the process strategically differentiated?
A unique billing model or complex procurement environment may justify specialist capability more than a routine accounting process.
- Is the expected process improvement greater than the integration burden?
The tool may save five hours inside one team while creating ten hours of support, reconciliation, and administration elsewhere.
- What remains the system of record?
The authoritative source must be defined for: vendor data, contract data, invoice status, payment status, accounting classification, and reporting.
- Who owns the integration?
Not only who builds it—but who monitors it, investigates failures, and certifies completeness.
- How will the process reconcile?
Every important upstream-to-ERP flow needs a measurable completeness and accuracy control.
- What happens when the tool is unavailable?
A resilient process requires exception handling and business-continuity planning.
- Does the application create or reduce control risk?
Access, approvals, segregation of duties, change management, and audit evidence must be considered before—not after—implementation.
Decision factors
- Existing ERP capability: ERP module may be preferable when capability is adequate; specialist application may be preferable when capability is materially weak.
- Process complexity: ERP module may be preferable for standard processes; specialist application may be preferable for highly specialised processes.
- User population: ERP module may be preferable when users are mostly finance users; specialist application may be preferable when users are broad cross-functional users.
- Need for innovation: ERP module may be preferable when the need is moderate; specialist application may be preferable when the need is high.
- Integration tolerance: ERP module may be preferable when tolerance is low; specialist application may be preferable when integration burden is manageable.
- Data sensitivity: ERP module may be preferable when data sensitivity is very high; specialist application may be preferable when sensitivity is governable.
- Replacement flexibility: ERP module may be preferable when replacement flexibility is a low priority; specialist application may be preferable when replacement flexibility is important.
- Process differentiation: ERP module may be preferable when differentiation is limited; specialist application may be preferable when differentiation is significant.
This is not a formula that produces an automatic answer. It is a way to ensure the decision is architectural rather than fashionable.
A counterargument worth taking seriously
Integration middleware such as MuleSoft, Boomi, or Azure Integration Services can reduce hand-off risk by orchestrating data flows, applying transformation rules, and centralising error monitoring between specialist applications and the ERP.
But middleware does not remove the governance problem: finance must still define who owns the integration, monitors failures, and certifies completeness and accuracy.
A final thought
Finance technology has undoubtedly improved. Modern tools can automate repetitive work, simplify approvals, improve usability, and solve problems that older ERP modules handled poorly.
But every improvement creates a new responsibility.
The organisation that adopts specialist tools without integration discipline may gain better applications and still end up with a worse finance process.
The future is unlikely to belong entirely to the single suite or entirely to the specialist ecosystem.
It will belong to organisations that know:
- what belongs in the core
- what belongs around it
- where data ownership sits
- how every hand-off is controlled
- when another application creates value
- and when it merely creates another reconciliation
The ERP is still there.
It is just no longer alone.
Sharpen the Thought
If my thoughts are the sword, other people’s opinions are the stones that sharpen it.
- Has your finance organisation gained more from specialist tools than it has lost through integration complexity?
- In your experience, which information should always remain authoritative in the ERP?
- At what point does a best-of-breed finance stack become best-of-chaos?
- Has a middleware or iPaaS layer changed the answer for your organisation?
References
[1] PwC, “2025 Digital Trends in Operations Survey,” 610 respondents. Integration complexity (47%) and data issues (44%) were the most common reasons technology investments had not fully delivered expected results. 92% cited at least one barrier.
[2] KPMG, “SOD 3.0: Next-generation separation of duties for the modern ERP,” 2023. Big Four professional guidance describing how best-of-breed and cloud application proliferation creates more integration points and mitigating controls, with cross-application SOD monitoring often conducted manually.
https://kpmg.com/us/en/articles/2023/separation-of-duties-3-point-0.html
[3] SAP, “RISE with SAP: Clean Core Methodology.” SAP defines the clean core as a system that is as close to standard as possible, while running cloud-compliant extensions and integrations.
https://www.sap.com/products/erp/rise/methodology/clean-core.html
Note
This article is intended for educational discussion and reflects the author’s research and professional experience. It is not a substitute for entity-specific accounting, technology, legal, tax, or audit advice.
The views expressed are the author’s own and do not represent any current or former employer.
Version 1.2 — Last reviewed: June 2026
For Dityaa — the little light behind every brave beginning.