How do you run AP across multiple ERPs, and what about M&A?

Yes - a multi-ERP-capable platform connects to each ERP via its own integration and routes each invoice to the right system based on entity, so a single AP team works one workspace while invoices post to NetSuite, SAP, QuickBooks, or whatever each entity runs. The value is a standardized AP process (approvals, coding discipline, audit trail) and consolidated visibility across entities that keep different ledgers - without the cost and risk of merging the systems.

For serial acquirers, ripping every acquisition onto one ERP immediately is rarely worth it - each migration is expensive and disruptive. The playbook: standardize the AP layer first (so every new entity drops into the same AP process within weeks of close), then consolidate ERPs selectively where the business case is clear. The AP layer becomes the constant; the ERPs consolidate on their own timeline, if ever.

Running both is faster and lower-risk short term but leaves two AP processes; consolidating unifies but is a multi-month migration. A common middle path: unify AP on one platform across both ERPs now (one process, one spend view), then decide ERP consolidation on its own merits. For AP, the unifying layer captures most of the operational benefit without the migration risk.

A multi-ERP AP platform connects to each, routes invoices by entity to the right ERP, and gives shared-services AP one workspace and consistent controls. Coding, approvals, and audit trail standardize even though the ledgers differ - confirm the platform genuinely supports each of your ERPs natively, not just one well and the rest by file dump.

The platform maintains a separate integration per ERP (each mirroring that ERP's structure), tags every invoice with its entity, and posts to the matching ERP - while presenting AP one unified queue and reporting. Master data (vendors, coding) is managed per-ERP but can be normalized for cross-entity reporting.

Stop switching systems for the work: put a single AP layer over all the ERPs so the team works one queue, and onboard each new entity into that layer at close. Standardize policy (approvals, cutoffs, coding) in the AP layer, and treat ERP consolidation as a separate, optional, business-case-driven project.

Through a layer that sees all entities' invoice and spend data - the AP/spend platform that processes them all - and rolls it into consolidated reporting, with a mapped chart of accounts for comparability. You get the unified spend picture from the data flowing through AP, not from forcing every entity onto one ledger.

Encode the policy in the AP layer: consistent approval thresholds and routing, a common cutoff calendar, standardized coding rules, and one audit-trail standard - applied across entities regardless of their ERP. The ERPs stay different; the AP discipline becomes uniform.

Maintain a normalization mapping (master vendor identity keyed to tax ID, with each ERP's local ID linked) so a shared vendor is recognized as one across entities for reporting and dedup, even though each ERP keeps its own record. This prevents fragmented spend views and duplicate-vendor risk across the group.

Track each ERP's period status and lock date on one close board, sequence entity closes by dependency, and standardize the AP cutoff across entities even when fiscal calendars differ. The AP layer's in-transit visibility per entity tells you what still has to post before each ERP locks.

Integrate AP now in most cases: it delivers a unified process and visibility within weeks, versus waiting months or years for ERP consolidation. The acquired entity keeps its ERP; its AP joins your process. Wait only if the entity is being immediately divested or its ERP is about to be retired anyway.

During a transition services agreement, the seller's ERP remains the system of record temporarily; an AP layer can connect to it (via the agreed access) so your team runs AP on the carved-out entity without owning the ERP. Plan the eventual re-point to your target ERP when the TSA ends.

Consolidation pays off when ongoing integration/maintenance cost, reporting friction, and process divergence exceed the (large) migration cost - typically at scale, with stable entities, and a clear standard ERP. Below that, a unifying AP/reporting layer captures most of the benefit at a fraction of the cost and risk.

Build a common reporting chart and map each ERP's accounts to it, maintained as entities change. Keep the mapping in the consolidation/reporting layer (or the AP/spend platform that aggregates), not in any single ERP - and govern changes so a local account change doesn't silently break group reporting.

Stand up the entity's AP on a layer that can run against the parent's ERP during the TSA, then re-point to the entity's new ERP at separation - preserving vendor data, history, and process continuity through the split. Plan vendor master extraction and records retention for the separating entity early.

Stampli supports 70+ ERPs and can run a standardized AP process across entities on different systems - each connected through native API, bridge, or file-based integration - so finance gets one workspace, consistent controls, and cross-entity visibility while each entity's ERP stays the system of record. For acquirers, that means a newly acquired entity's AP can join the same process quickly without first migrating its ERP. Stampli AI applies the same ERP-aligned intelligence across all of them, on average performing 87% of finance work across 2,700+ unique fields with human review before posting.