AP Automation and ERP Migration: When to Implement (Before, During, or After)

The single most consequential AP automation decision in an ERP migration isn't which platform to buy. It's when to deploy it: before the migration starts, during the parallel-run period, or after go-live. The default answer most finance teams hear from their implementation partner is "after, once the new ERP is stable." That default is wrong more often than it's right.

Here's why the stakes are high. By 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals, and as many as a quarter will fail catastrophically, according to Gartner's 2024 Predicts 2024: ERP Strategy and Implementation. ERP migrations are risky on their own. Accounts payable is one of the highest-volume, lowest-tolerance functions in the new environment, and it's usually the one that breaks first.

You can hear the failure pattern in how practitioners describe it. A thread on r/manufacturing that's become a kind of cautionary classic is titled, roughly, "thought we'd switch ERPs in 6 months, it took 16." Buried in those threads are the AP-specific lines. Go-live was a wreck because nobody had AP figured out, the implementation partner said wait and we wished we hadn't, and one team ran AP on paper for two months after cutover because the integration broke. The common thread is that AP got left until last, and last turned out to be a blackout.

A before / during / after framework with concrete trigger criteria lets you match the timing to your migration rather than to a rule of thumb. The right answer depends on your target ERP, your existing AP volume, and the go-live sequence your implementation partner has planned. Whether you're moving to NetSuite, Acumatica, Microsoft Dynamics 365 Business Central or Finance & Operations, Sage Intacct, or a comparable mid-market cloud platform, the sequencing question is the same.

Key Takeaways

• AP is one of the riskiest cutover surfaces in any ERP migration: vendors expect to be paid on terms, the financial close depends on AP closing, and the implementation team is judged on whether AP works the day after go-live.

• Deploying AP automation "before" the migration is the underused option. It cleans the vendor master and approval workflows the new ERP will ingest, and leaves a working approval queue in place when the cutover gets bumpy.

• Implementation partners default to "after" because it removes a variable during the build, but that default leaves AP running on paper or spreadsheets for the weeks or months after go-live.

• "During" fits when the new ERP's native AP module isn't production-ready at go-live and a parallel run of more than four weeks is planned.

• "After" is genuinely right in a narrower set of cases: you're already on a modern AP platform, volume is low, or you're re-platforming within the same ERP vendor.

• Integration breadth across many ERPs turns the cutover from a second migration into a configuration change, which is the strongest practical argument for the "before" path.

Why does AP automation timing matter so much in an ERP migration?

Timing matters because AP is high-volume and unforgiving, and a migration concentrates risk on exactly that kind of function. Vendors expect payment on terms. The close can't complete until AP closes. And the implementation team's reputation rides on whether AP works on day two, not day ninety.

The numbers around ERP projects explain the caution. Only about 30% of ERP projects finish on time and within budget, with roughly 55% running over budget and 68% past schedule, and a median time to ROI of about 2.5 years, according to Gartner's 2024 research. Separately, 23% of ERP projects exceed their budgets outright, with additional technology needs cited as the leading cause of the overruns, according to Panorama Consulting Group's 2024 The 2024 ERP Report. When most of the projects in your reference class run long and over budget, you don't want your highest-volume finance function depending on everything going right.

AP is also migrating from a manual baseline almost everywhere. About 82% of B2B payments in North America still involve manual touchpoints at some stage of the process, according to AFP's 2024 Payments Survey conducted with J.P. Morgan. That's the starting point most teams are carrying into the new ERP, regardless of when they automate. A migration is the worst possible moment to discover that the manual AP process can't keep up with the new system's demands.

What is the AP failure mode during an ERP cutover?

The failure mode is a cutover blackout, where AP simply can't process for a stretch of time after go-live. It tends to unfold the same way every time, and the sequence is worth naming because each step is preventable.

First, the vendor master doesn't migrate cleanly. Duplicate vendors, inconsistent payment terms, stale remit-to addresses, and missing GL mappings come across into the new ERP, and AP can't pay against records it can't trust. Second, approval workflows weren't reconfigured in the new system, so invoices land in a queue with no routing logic behind them. Third, the new ERP's native AP module isn't ready for production volume on day one, which is common because AP is usually the last module configured and tested. The team falls back to paper or spreadsheets, exceptions pile up, and payments slip past terms.

This isn't a rare edge case. Data migration is the most-cited migration challenge, named by 47% of organizations as the most difficult aspect of an ERP project, according to Panorama Consulting Group's 2024 The 2024 ERP Report. The AP master data of vendors, payment terms, and GL codes is the highest-volume slice of that data. The disruption shows up in the outcomes too, with 8% of organizations reporting business disruption during ERP cutover and order processing, financial close, and accounts payable named as the most-disrupted functions, per the same Panorama report.

AP is the canary. When it stops, everyone notices, and the noise is usually loud, because the people who notice are your suppliers. One review verbatim from a NetSuite cutover captures it plainly. The team couldn't approve anything for three weeks after go-live, and the accounts payable process ground to a halt while exceptions stacked up.

Why do implementation partners default to "AP after ERP is stable," and when is that wrong?

Implementation partners default to "after" because it removes a variable during the riskiest phase of the project. The logic is reasonable on its face. You don't want to introduce a new AP platform while you're also standing up a new general ledger, chart of accounts, and reporting layer. Fewer moving parts during the build means fewer things to debug at go-live. From the partner's side of the table, "stabilize the ERP first, then bolt on AP automation" is the lower-effort, lower-blame sequence.

The problem is that "fewer variables for the partner" and "less risk for the finance team" aren't the same thing. The cost of waiting is that AP runs in manual fallback for the weeks or months between go-live and the eventual AP deployment. That's exactly the window where suppliers go unpaid, the close drags, and the AP team burns out.

The reviews are blunt about where that leads. In one migration the AP team threatened to quit during go-live, and in another the company ran AP on paper for two months after cutover because the integration broke. Neither of those is a software problem. They're a sequencing problem.

There's a second, quieter cost. The vendor master and approval-workflow data the implementation team migrates is often the same messy data the company will pay a vendor to clean up later. You migrate the mess, then you migrate it again. Cleaning AP data before it's ingested into the new ERP is cheaper than cleaning it twice, and the only way to clean it in advance is to have an AP layer doing the work before the migration touches it. That's the case for "before," and it's stronger than the conventional wisdom allows. "After" is the right call in specific situations, covered below, but it shouldn't be the unexamined default.

How do you decide whether to implement AP automation before, during, or after the ERP migration?

You decide by matching your situation to the trigger criteria for each path, not by defaulting to "after." The framework below summarizes the three options. Each has clear conditions where it's the right call, and each gets its own walkthrough in the sections that follow.

The "before" path is the most underused of the three and viable more often than implementation partners assume.

When does deploying AP automation before the ERP migration make sense?

Deploying before makes sense when AP is still manual and the migration would otherwise carry messy data and an exhausted team into the new system. This is the underused option, and the trigger criteria are specific:

• The current AP process is manual or near-manual, with invoices keyed by hand and approvals chased over email.

• The vendor master is dirty and needs cleanup before migration, which is the most common condition given how often data migration ranks as the hardest part of the project.

• The AP team is small enough that one bad cutover week consumes its annual error budget. Median AP team size at $50–$250M companies is just 4–7 FTE, according to IOFM's 2024 AP Department Benchmarks, so there's no slack to absorb a manual-processing scramble.

• The implementation partner is bandwidth-constrained on AP design and would rather not own the AP module during the build.

• AP volume runs above roughly 2,500 invoices a month, where manual fallback isn't survivable for more than a few days.

In this path, you deploy AP automation 60 to 120 days before cutover. The automation layer cleans the vendor master and standardizes approval workflows, you migrate that clean data into the new ERP, and the integration sync keeps running through the switch so there's no period where AP has nowhere to go. The economics start paying off before the ERP even goes live, because manual AP invoice processing costs $10–$15 per invoice on average while automated processing runs roughly $2–$3, according to APQC and Ardent Partners' 2024 State of AP Automation. An ERP migration that automates AP first captures those savings months earlier than one that waits. Grounding the rollout in established AP automation best practices is what keeps the before path smooth rather than adding a second project on top of the migration. This pre-migration sequencing isn't a Corpay-specific recommendation either; it's the pattern most AP automation specialists land on once they've watched enough cutovers go sideways.

When does deploying AP automation during the ERP migration make sense?

Deploying during makes sense when the new ERP's AP module won't be ready on day one and you need a safety net that spans the gap. The trigger criteria are narrower than the before path but just as concrete:

• The target ERP's native AP module isn't production-ready at go-live, which you'll usually know from how late AP sits in the configuration schedule.

• A parallel-run period of more than four weeks is planned, where the legacy and target systems both stay live while data and processes move over.

• The implementation partner explicitly wants an AP fallback queue rather than a hard cutover for payables.

• The AP team can manage a phased cutover, bringing functions online module by module rather than all at once.

In this path, the automation layer handles AP through the entire hypercare period while the new ERP comes online piece by piece. Invoices keep getting captured, coded, approved, and paid on the automation layer's workflow, independent of whether the new ERP's native AP module is finished. Once the new system is stable, the AP integration cuts over to it fully.

This is the sequencing that the "6 months became 16" stories were missing. In those migrations, AP had nowhere to run during the gap, so the team improvised with paper and spreadsheets for the duration. With an AP layer running in parallel, the gap stops being a blackout and becomes a managed transition. The most critical AP automation workflows are exactly the ones you want insulated from the migration timeline, because they're the ones suppliers feel.

Protect cash flow with modern AP

Modernize AP to cut costs, speed approvals, and mitigate payment risk — gaining the real-time visibility to protect cash flow and scale with confidence.

Download the whitepaper

When does deploying AP automation after the ERP migration make sense?

Deploying after makes sense in a narrower set of cases, and it's worth being honest that "before" is not always the answer. There are real situations where adding an AP project on top of an ERP migration creates complexity you don't need. The trigger criteria for waiting:

• Your current AP process is already on a modern automation platform that the new ERP can connect to, so AP isn't a risk surface at cutover.

• The target ERP's native AP module is production-grade and fully tested at go-live, which is more realistic for enterprise implementations with long runways.

• AP volume is low, under roughly 500 invoices a month, where even a manual fallback week is manageable.

• The migration is a re-platform within the same ERP vendor — NetSuite to a newer NetSuite edition, or Sage on-premise to Sage cloud — where workflows and master data carry over with less disruption.

• Finance leadership wants to minimize concurrent project complexity and AP genuinely isn't the bottleneck.

In these cases, you complete the migration first, stabilize for 90 days or more, and then deploy AP automation into a clean, known-good environment. The benefits of automation are well established regardless of timing: 84% of finance leaders report that AP automation has reduced invoice processing time and 67% report cost reduction, according to IOFM's 2024 AP Automation Benchmarking. Those gains are there whether you automate before the migration or a quarter after it. The point of the framework isn't to push every team toward "before." It's to stop teams from landing on "after" by default when their situation actually calls for "before."

What does an AP-automation-aware ERP migration project plan look like?

An AP-aware project plan overlays AP automation milestones onto the migration timeline rather than treating AP as an afterthought to bolt on once everything else works. The goal is to remove AP from the list of things that can blow up at go-live. Given how few ERP projects land on time and on budget, an AP-aware plan is built specifically to beat that floor on the AP dimension, even when the broader project slips.

The sequence runs roughly in this order:

1. Vendor master cleanup and normalization.

2. Approval-workflow redesign on the automation layer.

3. AP automation deployment and integration build.

4. Cutover testing and go-live.

5. Hypercare and integration handoff.

Each of those milestones has timing and ownership questions that are easy to get wrong. The three subsections below work through the ones that matter most, starting with the vendor-master cleanup, then approval-workflow continuity, then the realistic deployment timeline relative to go-live.

What's the vendor master cleanup work, and when does it happen?

Vendor master cleanup is the work of de-duplicating, validating, and normalizing your vendor records before the new ERP ingests them, and it should happen first, ahead of the cutover. This is the highest-leverage early step because vendor data is both the highest-volume slice of the migration and the most error-prone. The same four problems surface in almost every migration: duplicate vendor records, payment terms that are inconsistent or missing entirely, remit-to and banking details that have gone stale, and GL codes that were never mapped to the new chart of accounts.

The cleanup itself involves merging duplicates, standardizing how terms are recorded, validating banking and remit details against the vendor, and mapping each vendor to the correct GL accounts in the new chart of accounts. When an AP automation layer is deployed before the migration, it does this validation as part of normal operation — every invoice that flows through forces the underlying vendor record to be correct — so by cutover the vendor master is already clean. When the cleanup is left to the migration itself, it competes for attention with the rest of the data-migration work, which is the work teams already report as the hardest part of the project. Treating it as an AP exercise that happens before migration, rather than a data exercise that happens during it, is what keeps it from slipping. Solid vendor management practices are the foundation here, because a clean vendor master is only worth having if the controls that keep it clean survive the cutover too.

How do you design approval workflows that survive the ERP cutover?

You design approval workflows on a layer that doesn't change when the underlying GL changes. Approval routing — who signs off on what, at which dollar thresholds, with which separation of duties — is logic that lives on top of accounting data, not inside it. When that logic is built natively into the old ERP, it has to be rebuilt from scratch in the new one, and the rebuild is one of the things that's rarely finished by go-live.

The alternative is to run approvals on the automation layer, where the workflow definition is independent of which ERP sits underneath. When the GL changes, the routing rules don't. The matching logic doesn't either: three-way matching of invoice, purchase order, and receipt is a control you want running continuously through the migration, not one you rebuild and re-test in a new system the week before cutover. Designing approvals this way means the migration changes the system of record without changing how invoices get approved and paid. The people doing the approving don't experience a cutover at all, which is exactly what you want from a finance control during a high-risk project.

What's a realistic AP-automation deployment timeline relative to ERP go-live?

A realistic AP automation deployment runs about 60 to 120 days for the before path, a concurrent build for the during path, and 90-plus days of post-cutover stabilization before deployment for the after path. The numbers aren't arbitrary; they track how long the underlying work takes.

The before path needs 60 to 120 days, enough time to deploy the automation layer, clean the vendor master through live processing, redesign approval workflows, and build and test the integration to the new ERP, all ahead of cutover. A during-path deployment has no separate timeline at all, because the AP work runs concurrently with the ERP build. The automation layer goes live early, and the integration target switches from the legacy ERP to the new one once the new system stabilizes. Waiting for the after path means letting the new ERP run for at least 90 days, so the environment is genuinely stable before you introduce the AP platform, which avoids stacking two stabilization periods on top of each other.

The mistake to avoid is compressing any of these to fit a go-live date that's already slipping. Most ERP timelines slip, so when the project timeline moves, the AP plan should move with it rather than getting crushed into the cutover week.

Which ERPs does Corpay AP automation integrate with, and how does that affect the timing decision?

Corpay AP automation integrates with 180+ ERPs out of the box, with bidirectional sync that pushes master data out and writes approved transactions back. That breadth covers the platforms mid-market and enterprise finance teams run day to day, and the specific list matters more than the headline number, because the timing decision hinges on whether your particular legacy and target systems are both supported.

The supported platforms include NetSuite, Acumatica, Microsoft Dynamics 365 Business Central, Microsoft Dynamics 365 Finance & Operations, Sage Intacct, Sage 100, Sage 300, QuickBooks Online, QuickBooks Desktop, Workday, and Deltek, along with the construction-vertical ERPs Foundation Software, Viewpoint Vista, and Sage 100 Contractor. That spread is what makes the integration breadth a timing lever rather than a feature-sheet line. This article anchors a set of integration deep-dives, including the live walkthrough of Acumatica AP automation and what Sage Intacct's native AP can and can't do, with NetSuite and Microsoft Dynamics companion pieces in the same cluster.

Automate AP end to end

Replace manual approvals, check runs, and reconciliation with a single automated workflow that syncs to your ERP — so your AP team spends time on strategy, not paperwork.

Explore AP Automation

How does the 180+ ERP integration breadth de-risk the timing decision?

The breadth de-risks the decision because if the automation layer integrates with both your legacy ERP and your target ERP, switching the integration target at cutover is a configuration change, not a second migration. That single fact is the strongest practical argument for the before path. You deploy AP automation against the legacy ERP, run it there while you clean data and stabilize workflows, and when the new ERP is ready you point the same AP layer at it. Nothing about the AP process rebuilds; only the connection endpoint changes.

Compare that to the alternative, where AP is native to each ERP. There, moving from the old system to the new one means rebuilding the entire AP function in the target ERP from scratch, which is precisely the work that doesn't get finished by go-live. An AP layer that sits above both systems turns "rebuild AP in the new ERP" into "repoint AP at the new ERP." For finance teams weighing the timing options, integration breadth across both the legacy and target systems is what makes "before" not just defensible but usually the lower-risk choice.

How does Corpay handle the parallel-run period when both the legacy and target ERPs are live?

During a parallel run, the AP layer connects to both the legacy and target ERPs at once, which is what makes the during path workable. In a parallel-run period, the old system stays live while the new one is validated, and for a stretch both are technically in use. An AP layer that can sync with both means AP doesn't have to pick a side during that window. Master data stays consistent across both systems, approved invoices write back to whichever ERP is the active system of record, and the eventual full cutover is a controlled switch rather than a leap.

This is the same dual-integration capability that powers the during sequencing described earlier. The automation layer carries AP through the hypercare period, talking to both ERPs as needed, and only finalizes the cutover to the new system once it's genuinely stable. For a migration where the parallel run is long and the new ERP's AP module is late — the exact conditions that turn a 6-month project into a 16-month one — running AP on a layer that spans both systems is the difference between a managed transition and the two-months-on-paper outcome the reviews describe.

Pair Corpay AP automation with your ERP migration

Corpay is the AP automation layer that 180+ ERPs integrate with out of the box, which is what lets it be deployed before, during, or after your migration depending on the trigger criteria above. Deploying before cleans the vendor master and stabilizes the highest-risk finance function ahead of cutover. The during path gives the implementation team a fallback approval queue through hypercare, while the after path lands automation into a clean environment once the ERP is stable. Because Corpay complements the ERP rather than competing with it, the AP layer is one less thing to rebuild in the new system, and the bidirectional sync means master data and approved transactions move in both directions without manual re-keying.

For most mid-market migrations, the before path is more viable than implementation partners assume, and it's the cheapest insurance against an AP cutover blackout. To go deeper, explore Corpay AP automation, weigh the ERP integrations that determine your timing options, or see how everything fits together on the unified Corpay Complete platform. If you're still shaping the project plan, the AP automation software guide and the AP automation RFP checklist frame the vendor-selection questions worth answering before cutover.

Frequently Asked Questions

Should we implement AP automation before, during, or after an ERP migration?

It depends on your situation, but "before" is the right call more often than the default suggests. Deploy before when AP is manual, the vendor master needs cleanup, or a small team is at risk of a rough cutover. Choose during when the new ERP's AP module isn't ready at go-live and you need a fallback queue through the parallel run. Save after for cases where you're already on modern AP, volume is low, or you're re-platforming within the same vendor.

What is ERP migration?

ERP migration is the process of moving an organization's data, processes, and configurations from one enterprise resource planning system to another, often from on-premise software to a cloud ERP. It includes migrating master data, reconfiguring workflows, and cutting over to the new system. If you want the broader context on what an ERP actually does, that foundation helps explain why finance functions like accounts payable are among the riskiest pieces to get right during a migration.

What's a typical ERP migration timeline, and how long does it actually take?

ERP migrations frequently run longer than planned. Projects estimated at six months stretching to a year or more are common enough that practitioners trade the stories on community forums. Only a minority finish on time and within budget, and most run past schedule, so finance teams should plan for slippage and protect high-volume functions like AP from the disruption that delays cause.

What are the most common ERP migration challenges?

Data migration is the single most-cited challenge, with vendor and master data the highest-volume and most error-prone slice. The other recurring problems are approval workflows that have to be rebuilt in the new system, native modules that aren't production-ready at go-live, and the business disruption at cutover that hits order processing, financial close, and accounts payable hardest.

What's the difference between ERP migration and ERP implementation?

Implementation is standing up an ERP for the first time or deploying new modules within an existing system. Migration is moving from one ERP to another, which adds the work of extracting, cleaning, and mapping data out of the old system and into the new one. Migration carries the extra risk that legacy data is messy and that processes built around the old system don't translate cleanly, which is why AP sequencing matters so much in a migration specifically.

What's an ERP migration checklist for the finance team?

A finance-focused checklist runs through a handful of milestones the team owns directly:

• Vendor master cleanup and validation.

• Approval-workflow redesign on a layer that survives the cutover.

• GL and chart-of-accounts mapping.

• Integration build and testing for AP and the other transaction systems.

• Cutover testing and a hypercare plan for the weeks after go-live.

The AP-specific items — clean vendor data, continuous approval routing, and a fallback queue — are the ones most likely to be left until last, which is exactly why they fail first.

How does AP automation reduce ERP migration risk?

AP automation reduces risk by cleaning vendor and approval data before migration, providing a stable AP workflow that doesn't depend on the new ERP's native module being ready at go-live, and offering a fallback queue during the parallel-run period. It removes accounts payable from the list of functions that can fail at cutover, which matters because AP is one of the three most-disrupted functions when cutovers go wrong.

Can AP automation run during the parallel-run period of an ERP migration?

Yes. With a platform that integrates with both the legacy and target ERPs, AP automation runs through the parallel-run and hypercare periods, syncing with both systems while the new ERP comes online. The AP integration then cuts over fully once the new ERP is stable, which avoids the AP blackout that turns a planned parallel run into months of processing invoices on paper.

How do you migrate vendor master data into a new ERP without breaking AP?

You clean and normalize the vendor master before migration rather than carrying messy data into the new ERP. Deploying AP automation ahead of the migration validates vendor records, payment terms, banking details, and GL coding through live processing, so the new system ingests clean data. AP keeps running through the switch instead of stalling on duplicate records and unmapped accounts.

David Luther

Product Marketing Program Manager

David Luther, MBA is a product marketing program manager with years of experience in commercial banking, finance, and technology sectors, with research and writing appearing in financial publications.

AP Automation