ERPs are the right tool for the system of record. They were never the right tool for the network of record. The two have been conflated in most enterprise architectures because the ERP was the most powerful piece of software in the building, and everything tended to be forced through it. Network-level signals do not fit the model. The cleaner architecture is to keep the ERP doing what it does well and let a network layer sit above it.
What ERPs were designed for
ERPs were designed to be the canonical system of record for a single business. Transactions, master data, journal entries and reporting all flow through them. The architecture assumes the business is the centre of the picture and the world outside the business is represented inside the business's records, on the business's terms.
That works for the closing cycle. It works for tax reporting. It works for statutory accounts. It does not work for data that originates outside the business and changes outside the business: supplier identity, beneficial ownership, behavioural baselines, network-level fraud signals. This is the same constraint that the network effect in accounts payable identifies at the category level.
The cost of forcing the network into the ERP
Three patterns appear when enterprise architectures try to land network-level capability inside the ERP.
Brittle integrations. The ERP's data model is rigid by design. External data forced into it requires extension fields, custom tables and bespoke import logic. Each upgrade of the ERP breaks the customisations. The maintenance cost compounds.
Capped visibility. The ERP can only display what its data model accommodates. Network-level signals (behavioural delta, exception clustering, cross-buyer pattern) do not fit cleanly into a flat field structure. The user sees a thin representation of a rich underlying dataset.
Latent risk. Where the ERP holds a stale copy of network-level data (a supplier identity that has since been updated, a bank detail that has since changed), the operational decision runs on the stale copy. The fresher view in the network is invisible to the user inside the ERP.
Each of these is operationally costly. The combination is what makes the ERP-centric approach unsustainable for network capability.
The case for the network layer above the ERP
A network layer that sits above the ERP keeps both systems doing what they do well.
The ERP holds the business's records. Transactions, journal entries, master data, statutory reporting. The data model stays clean. Upgrades stay manageable.
The network layer holds supplier identity, behavioural data, exception workflow and cross-buyer signal sharing. The data model is shaped for the network use case, not constrained by the ERP's assumptions.
The integration is bounded. The ERP reads from the network layer at defined points (payment trigger, master data refresh, exception review) and writes back when needed (transaction completion, period close). The integration is bounded, well-tested and ERP-agnostic. This is the architectural counterpart to continuous AP, which the ERP cannot deliver on its own.
What this means for finance transformation programmes
Most mid-market finance transformation programmes in 2026 carry a multi-year ERP implementation at their centre. The temptation is to fold network capability into the ERP scope, which extends the programme, complicates the integration and concentrates the risk.
The cleaner approach is to keep the network layer independent of the ERP scope. The ERP programme delivers the system of record. The network layer is added on top, with its own timeline and its own change management. Each can move at its own pace. The dependency between them is bounded and well-defined.
Three integration patterns
API-driven. The network exposes a defined API. The ERP consumes the API at the relevant points. Cleanest pattern. Suitable for ERPs with modern API support and finance teams comfortable with the integration model.
Middleware-mediated. An iPaaS or middleware layer sits between the ERP and the network. The middleware translates the data model and handles the integration logic. Useful for ERPs with constrained API surface or for businesses running multiple ERPs across business units.
Embedded extension. The network's capability is delivered as an extension or app inside the ERP's own marketplace. The user sees the network capability inside the ERP UI but the data and logic run on the network. Useful for businesses that want the user experience consolidated inside one tool. Embedded AP goes deeper into this pattern.
Each pattern fits a different starting position. The choice should be driven by the ERP's surface area and the business's appetite for integration complexity.
What this means for buyers selecting AP tools
The diagnostic question for any AP vendor is where the data model sits. Vendors who build inside the ERP's data model inherit the ERP's constraints. Vendors who build above it, with a clean integration boundary, retain the flexibility that network capability requires. The wider visibility argument that the network layer supports is set out in procure-to-pay visibility.
Buyers locked into a long ERP roadmap should not feel obliged to wait for the ERP to add network capability. The architectural pattern that holds up best in practice keeps the two separate, with a bounded integration between them.
