Payables orchestration for multi-ERP enterprises

Most large enterprises do not run payables on one system. Acquisitions arrive with their own ERP. Regional subsidiaries run local platforms for tax and language requirements. Business units pick software that fits their operations. APQC benchmarking data, reported by CFO.com, shows the median enterprise runs two ERPs across its finance shared services organisation, and organisations at the 75th percentile run four or more.

The payables policy is usually identical across the group. The systems that capture invoices, match them, approve them, and pay them are configured differently in every entity. The same supplier is set up three times, with three vendor IDs and three sets of bank details. The same three-way match runs under different tolerances in each instance. The duplicate-payment check in one ERP cannot see an invoice that entered through another, and work that should happen once happens once per system.

In the long run, this fragmentation is expensive. Ardent Partners’ State of ePayables research describes legacy AP where a single invoice could cost more than $20 to process and take over 20 days to clear, figures that two decades of automation have cut to less than half. Across a multi-ERP enterprise, the least automated entities pull the group’s numbers back toward that high end.

This article covers why one payables process breaks across multiple ERPs, what the split costs, why consolidation and integration fall short, and what a single orchestration layer above the ERPs changes.

Multi-ERP environments are not a design choice. They accumulate from decisions that had nothing to do with accounts payable, and the most common cause is mergers and acquisitions.

An acquired business brings its ERP with it, with a chart of accounts, a vendor master, tax configuration, and an approval hierarchy. A full migration onto the group standard takes well over a year and costs too much, so most groups defer it. The acquired system becomes permanent.

Regional requirements add more. A UAE subsidiary needs Arabic support and 5% VAT handling; an Australian entity needs GST and FBT treatment; a New Zealand entity needs its own GST configuration. When the parent platform does not handle these natively, the subsidiary runs a local instance. Business-unit autonomy adds the rest, with separate systems chosen for project accounting, supply chain, or consolidated reporting.

For payables specifically, each additional ERP fractures the invoice-to-pay chain at every step. The supplier master splits, so the same vendor exists under different IDs with no shared view of total exposure. Invoice intake splits, so an email PDF is keyed by hand in one entity and arrives structured in another. Matching splits, so tolerances and approval thresholds drift apart. Payment runs split, so the same supplier is paid on different cycles from different systems.

(For the same problem applied to employee spend, see our article on managing expenses across multiple ERPs.)

The cost shows up first in unit economics. Manual invoice processing still runs about $15 to $16 each, against as little as $3 fully automated. In a multi-ERP environment, the group inherits the economics of its least automated system across every entity that shares suppliers with it, so the entity that still keys invoices by hand sets the cost base for the vendors it has in common with the rest of the group.

The second cost is control. Duplicate-payment detection, supplier bank verification, and fraud screening all run inside the boundary of a single ERP. When the same supplier and the same invoice can exist in more than one system, a control that works perfectly in each instance still has a blind spot between them.

An invoice paid in one entity is not visible to the duplicate check in the next. This matters against a real threat: the FBI’s Internet Crime Complaint Center recorded nearly $2.8 billion in business email compromise losses in 2024, and redirected supplier payments are a leading factor.

The third cost is visibility. Consolidated payables reporting requires someone to extract data from each ERP, map differing chart-of-accounts structures to a common taxonomy, and assemble the result by hand. That work lands during the close, so the CFO sees group-level payables and cash position after the period ends, assembled from systems that each structure the data differently. The figures are accurate but arrive after the period has closed.

83 countries already mandate real-time tax reporting, each on its own format, clearance model, and timeline. An enterprise operating across several countries faces a different mandate in each, and no single ERP upgrade satisfies all of them at once.

In the UAE, the mandate runs through a voluntary pilot from July 2026, with businesses at AED 50 million or more in revenue required to issue structured e-invoices from 1 January 2027 under the PINT AE format and the five-corner model. Currently published guidance may evolve. In Europe, the ViDA programme has its own timelines on its own formats, and the format is different for each country.

When invoice data posts to several ERPs with different compliance configurations, readiness becomes per-system work. Each ERP needs its own validation rules, its own format mapping, and its own connection to the relevant network or tax authority. The effort multiplies by the number of systems, and each one is a separate point of failure at audit.

The instinctive fix for many enterprises is to collapse everything into one ERP. In practice, consolidation programmes run for years, cost heavily, and are overtaken by the next acquisition before they finish.

Gartner describes postmodern ERP as a strategy that links finance and operational capabilities “with appropriate levels of integration that balance the benefits of vendor-delivered integration against business flexibility and agility.” Many groups keep multiple systems on purpose. Waiting for consolidation means waiting for payables value that keeps receding.

The second instinct is integration, connecting the systems and syncing the data. That addresses where the data sits without addressing how it is governed. Middleware connections are fragile: each one carries roughly a 20% chance of breaking whenever a connected system updates, and an organisation running three ERPs maintains three pipelines as standing obligations. More fundamentally, syncing data between systems does not make a supplier master consistent, apply one matching tolerance, or enforce one approval policy.

Payables orchestration coordinates suppliers, invoices, approvals, controls, payments, and reporting across multiple systems through one control layer. The orchestration platform sits above the ERPs. It ingests from each system, applies one consistent set of rules, and posts each transaction back to the correct ERP as the system of record. No ERP is replaced.

The architecture does what no individual ERP can do in a multi-ERP enterprise. One supplier master spans every entity, so a vendor and its verified bank details are governed once. One capture engine takes invoices across every channel and applies the same extraction and duplicate detection to all of them. One matching and exception model runs the same tolerances and approval logic regardless of which ERP the invoice will post to. One payment model routes settlement across the right methods on a consistent schedule. One compliance engine validates every invoice against the applicable mandate before it lands anywhere. Consolidated reporting then reads from a single governed dataset.

Gartner predicts that finance functions using cloud ERP with embedded AI will achieve a 30% faster financial close by 2028, and in a multi-ERP environment that outcome rests on a layer above the systems that delivers pre-validated, pre-consolidated data. Without that layer, the close waits for the slowest ERP and the last manual mapping pass. The layer is what lets the group run payables as a single governed operation across all of its ERPs.

SpendConsole’s payables orchestration platform is built for this position. It connects to SAP, Oracle, Dynamics 365, NetSuite, Workday, and Ariba, ingests from any of them, and posts back without ERP customisation. Its modules map directly to the points where multi-ERP payables break.

Connect establishes one supplier control layer across all entities and ERPs, with structured onboarding, identity verification, and unified vendor master management, the single view of a supplier that no individual system holds.

Capture takes invoices across eight channels, including email, supplier portal, e-invoicing, EDI, API, file upload, scan, and mobile, with AI extraction, validation, and duplicate detection applied uniformly at the point of receipt.

Resolve runs coding, matching, and exception handling under one set of rules aligned to each entity’s delegation of authority, with contract-price validation and continuous risk screening layered across every supplier, invoice, and payment.

Settle moves from approved invoice to payment with reconciliation and multi-entity support, routing each payment across the right rail.

Insights delivers consolidated, real-time visibility across invoices, cash flow, and liabilities, and Oli, the platform’s natural-language agent, lets AP teams and CFOs query payables across every entity without building a report.

Underneath, integrations are maintained as first-party capabilities, including certified bi-directional SAP posting via ABAP transport for ECC and S/4HANA, so each transaction posts to the correct entity with the correct GL account, tax code, and cost centre.

Why do enterprises run payables on multiple ERPs?

The most common cause is mergers and acquisitions, where each acquired entity brings its own ERP. Regional subsidiaries often run local platforms for tax and language requirements, and business units sometimes select their own systems for operational fit. APQC benchmarking shows the median enterprise runs two ERPs and organisations at the 75th percentile run four or more.

Can payables be unified without replacing the existing ERPs?

Yes. A payables orchestration platform sits above the ERPs as a processing and governance layer. It captures, validates, matches, approves, and pays using one supplier master and one rule set, then posts each transaction to the correct ERP with its native GL mapping and tax treatment. The ERPs continue as the systems of record.

Why doesn’t integration between ERPs solve the problem?

Integration moves data between systems; it does not standardise how that data is created, classified, or governed. Middleware connections carry roughly a 20% chance of breaking on every software update, each is a standing maintenance obligation, and syncing differently structured data produces stacked datasets. Consistency has to be applied before data reaches any ERP, by one engine that governs the whole workflow.

What is the difference between payables orchestration and AP automation?

AP automation usually speeds up a step or a system — extracting invoices or routing approvals inside one ERP. Payables orchestration coordinates the full invoice-to-pay cycle across multiple systems, including supplier management, matching, payment, compliance, and reporting, under one control layer that posts back to each ERP.

How does multi-ERP fragmentation affect fraud and duplicate payments?

Duplicate-payment checks and bank-account verification run inside a single ERP. When the same supplier and invoice can exist in more than one system, a control that works in each instance still has a blind spot between them. The FBI’s IC3 recorded $2.77 billion in business email compromise losses in 2024, much of it through redirected supplier payments, a risk that grows when no system holds the complete view.

How does multi-ERP complexity affect e-invoicing compliance?

Each ERP needs its own validation rules, format mapping, and connection to the relevant network or tax authority, so readiness multiplies by the number of systems. In the UAE, structured e-invoicing becomes mandatory for businesses at AED 50 million or more in revenue from 1 January 2027, following a voluntary pilot in 2026 (currently published guidance may evolve). A single compliance engine that validates every invoice before it reaches any ERP removes the per-system effort.

How does this apply to employee expenses across multiple ERPs?

Employee spend faces the same fragmentation as supplier invoices, different GL codes, tax treatment, and approval workflows in each system. The fix is the same unified layer applied to a different transaction stream. See managing expenses across multiple ERPs without losing visibility for the detail.