Finance Index
We're migrating ERPs - should we automate AP before, during, or after the migration?
Reference guide to ERP migration system change moments, including invoice workflow, coding, approvals, ERP impact, and AP controls.
The defensible sequence is usually to automate AP independently of the ERP migration, with timing driven by which pain is bleeding more. An AP layer that sits above the ERP and integrates with both your current and future system lets invoice processing continue uninterrupted through cutover, decouples two hard projects so they don't compound, and means the migration changes where invoices post - not how AP works. Bolting AP automation onto the new ERP only after go-live is common but leaves AP keying manually through the riskiest stretch.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| We're migrating ERPs | The defensible sequence is usually to automate AP independently of the ERP migration, with timing driven by which pain is bleeding more. | Keeps vendor records and payment decisions reliable. |
| ERP alignment | Plan the in-flight population explicitly: decide a cutover date, post or accrue everything you can in the old system before it, and define where invoices received during the transition land. | Keeps accounting records aligned with the ERP. |
| Vendor impact | At minimum: open (unpaid) invoices and their balances, vendor master with payment details, and open credits. | Reduces payment errors, timing issues, and reconciliation cleanup. |
| After go-live on | Usual culprits: field mappings that don't match the new ERP's structure, dimensions or accounts that changed names/IDs, posting-rule differences, and authentication/connection setup. | Keeps vendor records and payment decisions reliable. |
| Our AP automation must | Ask to see the platform running your specific current and target ERPs - fields, dimensions, validation, and posting - not a generic demo org. | Keeps vendor records and payment decisions reliable. |
How do I keep invoices flowing during an ERP cutover, handling in-flight invoices across old and new systems?
Plan the in-flight population explicitly: decide a cutover date, post or accrue everything you can in the old system before it, and define where invoices received during the transition land. An AP layer independent of the ERP helps enormously - invoices keep being captured, coded, and approved in one continuous workflow while the posting target switches from old ERP to new. The failure mode is a hard ERP cutover with invoices stranded between a frozen old system and a not-yet-ready new one; the in-flight queue must have a home throughout.
What AP data should migrate to the new ERP - open invoices, history, vendor balances, images?
At minimum: open (unpaid) invoices and their balances, vendor master with payment details, and open credits. History and invoice images are often better left accessible in the AP layer or an archive than fully migrated, since bulk-loading years of closed transactions into a new ERP adds cost and risk for data you rarely re-post.
After go-live on the new ERP, invoice sync is failing and AP is keying manually again - what are common cutover issues?
Usual culprits: field mappings that don't match the new ERP's structure, dimensions or accounts that changed names/IDs, posting-rule differences, and authentication/connection setup. The fix is validating the integration against the new ERP's live structure before relying on it - the symptom (manual keying) means the AP layer isn't actually mirroring the new ERP yet.
Our AP automation must work with both our current and future ERP - how do I evaluate multi-ERP support?
Ask to see the platform running your specific current and target ERPs - fields, dimensions, validation, and posting - not a generic demo org. Verify it can run both in parallel during transition, and confirm integration depth (does it mirror and validate, or just pass lists?) for each, since shallow integration on the new ERP recreates the manual work you're trying to escape.
How do I keep historical invoice access after we sunset the old ERP, in a way that keeps auditors happy?
Retain the invoices, supporting documents, and audit history in a searchable archive (the AP layer often serves this) rather than depending on a decommissioned ERP. Confirm the archive preserves the full package and is searchable by vendor, date, and amount - auditors will ask for old-period documents long after the old ERP is gone.
Stampli perspective
Stampli operates as a system of engagement that extends the ERP rather than replacing it, mirroring ERP structure and validating before posting - and it integrates with 70+ ERPs through native API and bridge/file-based paths, which is what lets AP processing continue through an ERP change while the posting target shifts. Because the invoice workflow, history, and audit trail live in Stampli, the institutional record of how invoices were handled doesn't migrate with the ERP, and multi-ERP support covers environments running old and new systems in parallel.