AP Automation Go-Live: How to Cut Over Without Disrupting Month-End Close
- How long does AP automation implementation take without disrupting month-end close?
- What does a close-aware cutover calendar look like?
- How do you freeze the vendor master and migrate open invoices?
- Should you run the old and new AP process in parallel?
- How do you reconcile the first close after go-live?
- What belongs in an AP automation rollback plan?
- Go live in weeks with Corpay
AP automation implementation usually takes several weeks to a few months. Whether it disrupts month-end close depends on the go-live date, not the project length. Go live early in the month, right after the prior close.
Those are two different questions, and most project plans only answer the first. The vendor's implementation team schedules go-live when configuration and testing are done, which is reasonable from their side. From the controller's side, a go-live that lands three days before close means the first live payment run, the first batch of migrated invoices, and the first accrual cutoff all happen in the busiest week of the month. The rest of this plan is about choosing the date on purpose and protecting the weeks around it.
Key Takeaways
Implementation length and close disruption are separate problems. The first depends on scope, and the second depends almost entirely on when you go live.
Schedule go-live one to three business days after the prior close is signed off, so at least two full payment runs happen before the next close.
Freeze vendor master changes for the cutover window, because bank-change requests are where payment fraud concentrates.
Migrate open invoices once, after the prior close is signed off, against a control total, and reconcile later changes as a delta.
Run one shadow payment cycle with only the new system authorized to release payments, and write down what would trigger a rollback and when rollback stops being possible.
How long does AP automation implementation take without disrupting month-end close?
Most mid-market AP automation implementations take several weeks to a few months from kickoff to go-live, and none of that has to touch close. Close is disrupted by a badly placed go-live date, not by the project itself.
The phases and what drives their length are laid out in the AP automation implementation timeline. The last three weeks before cutover are where close gets hurt, and they deserve their own plan. Treat the implementation length as the vendor's estimate and the go-live date as your decision. Vendors with a managed model tend to compress the front of the project, and Corpay customers are typically live in weeks, but even a short project needs its go-live placed carefully against close.
When should go-live fall relative to close?
Go live one to three business days after the prior month's close is signed off, which for a close that wraps by business day five means roughly business day six to eight. That still leaves at least two full payment runs and most of a month of invoice processing before the next close starts.
Close takes longer than people remember when they're planning. APQC data reported by CFO.com in "Metric of the Month: Cycle Time for Monthly Close" puts the median monthly close at 6.4 calendar days, with top performers at 4.8 days or less and the bottom quarter at 10 or more. That's 2018 data, and plenty of teams are faster now, but add a few days of AP cutoff work before close starts and the safe window for a go-live shrinks to roughly the second and third weeks of the month.
The alternative is familiar. The go-live lands on the 28th because that's when testing wrapped up, the AP team processes its first live batch while also pulling accrual support, and the controller spends close reconciling two systems instead of one. Nothing goes catastrophically wrong. It just costs a week of everyone's patience, and the team's first impression of the new system is that it made close harder.
Quarter-end and year-end months are worse candidates. If the project finishes in late November, wait for January rather than going live into a year-end close and audit fieldwork.
What does IT need to do before cutover?
IT's cutover work is mostly access and connections, and it needs to be finished before go-live week rather than during it. The evaluation-stage security review is a separate exercise. In the final two weeks, IT typically owns the following.
Set up single sign-on and provision users with roles that match the approval matrix
Issue ERP integration credentials and confirm the open posting period the new system will write to
Connect bank files or payment rails, including the positive pay file feed if you issue checks
Turn off scheduled payment jobs and vendor imports in the old system on go-live day
Confirm who supports the integration after hours during the first payment run
If you're also changing ERPs, don't stack the two cutovers in the same month. AP automation during an ERP migration works better when one system is stable while the other moves.
What does a close-aware cutover calendar look like?
A close-aware cutover calendar counts backward and forward from go-live day and keeps every risky step out of close week. The version below assumes a close signed off by business day five, go-live a business day or two later, and a weekly payment run.
When | Task | Owner |
Go-live minus 10 business days | Announce the vendor master freeze and the cutover dates to AP, purchasing, and approvers | Controller |
Go-live minus 5 | Start the vendor master freeze and queue any bank-detail requests for call-back verification | AP manager |
Prior close signed off (go-live minus 1 or 2) | Keep posting in the old system through sign-off, then take a controlled extract of open invoices with control totals by count and dollar amount, and log every invoice received or changed after the extract by record ID, change type, and status | AP and IT |
Go-live day | Stop old-system writes at a set cutoff time and route anything received after it to a logged intake queue, load and tie out the extract, load the final delta and reconcile it, switch intake to the new system, then load and reconcile the queue, and confirm the old system's payment jobs and bank connection are disabled | AP, IT, and vendor |
Shadow cycle (before the first scheduled run) | Generate the first payment proposal in the new system, compare it vendor by vendor to the old system's read-only data, and sign off the exit criteria | AP manager and controller |
First live payment run | Release the first live payment file from the new system only, after the shadow sign-off | AP manager |
Second payment run | Lift the vendor master freeze | Controller |
First close | Reconcile the AP subledger to the general ledger and the aging report line by line | Controller and AP |
The dates matter less than the order. Finish close before you extract, extract before you load, shadow before you release, and never let two systems release payments in the same week.
How do you freeze the vendor master and migrate open invoices?
Freeze vendor master changes for about five business days before go-live through the second payment run, and migrate open invoices once, with control totals that tie before anything gets paid. Those two steps prevent most cutover errors.
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
Why freeze vendor master changes during cutover?
A freeze keeps the vendor data you're migrating from changing underneath you, and it shuts the door on the most common fraud attempt during a system change. Fraudsters know when companies switch AP systems, because vendors and employees get emails about it.
According to the AFP's 2026 Payments Fraud and Control Survey, 74% of organizations were affected by business email compromise in 2025, and 76% experienced attempted or actual payments fraud. The FBI's 2025 Internet Crime Report counted $3,046,598,558 in reported business email compromise losses in the same year. A request to "update our bank details in your new system" is about the most convincing pretext there is during a migration.
During the freeze, bank-detail requests go into a queue rather than straight into either system. Each one gets a call-back to a phone number already on file before it's applied, using the same steps you'd use for vendor bank verification at any other time. Urgent new vendors can still be added, but by one named person, with a second approver.
How do you move open invoices without paying them twice?
Move open invoices in one batch, tie the batch to a control total, and stop the old system from paying anything from that moment on. Duplicate payments during cutover almost always come from an invoice that existed in both systems for a few days.
Define "open" before extraction. Approved but unpaid invoices move. Invoices still in approval usually move too, and their approvals restart in the new workflow, which is annoying but cleaner than importing half-finished approval histories. Paid invoices stay behind, apart from the payment history you need for duplicate checks.
Don't stop posting early to make the extract easier. The old system keeps accepting invoices until the prior close is signed off, and only then does IT take the controlled extract. Anything received or changed between the extract and go-live, whether a new invoice, a credit memo, or an approval, goes on a log that one person keeps by the old system's record ID, change type, status, and before and after amounts. On go-live day, stop writes to the old system at a set cutoff time, hold anything that arrives after it in a logged intake queue, with an ID on every item, that loads once the new system's intake opens and is reconciled by count and amount like the delta, close the log, and load it as a separate delta batch after the main load ties out, and reconcile the delta to the log before the shadow cycle, so nothing received in the gap gets lost or entered twice.
Once loaded, compare invoice count and total dollars to the extract and resolve every difference before the first payment run. Then run the new platform's duplicate payment detection against the last 90 days of paid history from the old system, since a vendor who resends an invoice during cutover is exactly what that check should catch.
Should you run the old and new AP process in parallel?
Run one shadow cycle on the payment side, with exit criteria agreed before go-live and only the new system authorized to release payments. A full parallel run of invoice entry in both systems doubles the AP team's work and rarely finds anything a control total wouldn't.
What's worth comparing is the payment file. Before the first live run, generate the payment proposal in the new system and compare it, vendor by vendor, to what the old system would have paid, using the old system's data in read-only mode. The old system never releases a payment during the shadow cycle, and IT should confirm before the run that its scheduled payment jobs and bank file connection are switched off, because two systems that can both pay will eventually both pay the same invoice. Agree in advance that the shadow cycle ends when the two match or every difference has an explanation, and have the controller sign that off before the first live file is released. If you leave the exit undefined, an anxious team will keep the comparison going for a month.
Payment timing changes during cutover deserve their own attention. Same Day ACH carried 1.4 billion payments in 2025, up 16.7%, worth $3.9 trillion, according to Nacha's 2025 ACH Network volume report, so a vendor moved from check to ACH at go-live may be paid days earlier than before, which affects cash forecasting in the first month. Corpay pays suppliers by virtual card, ACH, or check from one approval flow, which keeps the method change from becoming a second cutover.
Checks are the messy part. They were 9.2 billion payments in 2024, about 4% of noncash payments by number but about 17% by value, according to the Federal Reserve's 2025 Payments Study. Any written from the old system will still be clearing for weeks after go-live, so keep the old positive pay file active until they've cleared, and make sure the new system's check numbers don't overlap the old range.
How do you reconcile the first close after go-live?
Reconcile the first close after go-live line by line, tying the AP subledger to the general ledger and the aging report to both. Expect to spend more time on it than a normal close, and plan for that time.
Three things tend to break. Invoices received in the old system but approved in the new one can land in the wrong period, so review the accrual cutoff by hand this once, using the difference between accrued expenses and accounts payable as the guide. Payments released from the old system in the last week before cutover need to match to invoices that now live in the new one. And the aging report often fails to tie because migrated invoices carry a load date instead of the original invoice date, which the steps for AP aging report reconciliation will catch.
Use the first close to set your baseline, too. APQC data reported by CFO.com in "Metric of the Month: Accounts Payable Cost" put the median cost to process an invoice at $5.83 in 2018, with top performers at $2.07 or less and the bottom quarter at $10 or more. Your own number from the last full month on the old system is the one to compare against at month three, after the team has settled into the new process. Measuring in month one mostly measures the cutover.
What belongs in an AP automation rollback plan?
An AP automation rollback plan names the triggers that would send you back to the old system, the person who makes that call, and what happens to invoices already entered in the new one. Write it before go-live and hope nobody reads it again.
Reasonable triggers include:
The open invoice load doesn't tie to control totals by go-live plus one business day
The first payment file can't be generated or fails bank validation
The ERP integration fails to post for more than one business day
The shadow comparison shows payment differences nobody can explain before the first live run
Keep the old system read-only rather than shut down until after the first close, so its history stays available for research and rollback stays possible up to the point described below. The change management side of an AP rollout matters here too, because a team that was never comfortable with the new system will push for rollback at the first problem.
Rollback stays possible as long as records and payment state can be reconciled back to the old system safely. Loaded invoices, including the delta batch, can be reversed, because the extract and the post-extract log tell you exactly what to re-enter or reopen in the old system. A released live payment can't be unsent. Once the first live file goes out from the new system, going back means rebuilding payment history in the old one by hand, with real risk of paying someone twice. Most teams I've talked to treat that release as the line where you fix forward, and it's worth writing the line into the plan before the date arrives rather than discovering it during a bad afternoon.
Go live in weeks with Corpay
Most go-live pain comes from the AP team carrying the project and the close at the same time. Corpay's fully managed AP takes the supplier side of that work off your team.
With Corpay AP automation, Corpay handles supplier enrollment and payment follow-up, then pays each vendor by virtual card, ACH, or check from one approval flow. Corpay connects through 100+ ERP integrations, including NetSuite, Sage Intacct, Business Central, and Acumatica. Customers are typically live in weeks, save about 40% of the time spent on invoice processing, and earn card rebates that add up to more than $800M paid to Corpay customers each year.
Frequently Asked Questions
How long does AP automation implementation take?
Most mid-market AP automation implementations take several weeks to a few months, depending on vendor count, entity count, ERP integration, and how available your finance team is. Managed providers that run supplier enrollment for you tend to finish faster.
When is the best time to go live with AP automation?
The best time is one to three business days after the prior month's close is signed off. Avoid the last week of the month, quarter-end, and year-end, so at least two payment runs happen before the next close.
What does IT need to do for an AP automation go-live?
IT sets up single sign-on and user roles, issues ERP integration credentials, confirms the open posting period, connects bank files and positive pay, and turns off the old system's payment jobs on go-live day.
How long should a parallel run last?
One payment cycle is usually enough, run as a shadow comparison. Only the new system releases payments, and the new proposal is compared vendor by vendor to what the old system would have paid. End it once every difference is explained.
What happens to open invoices at go-live?
Approved and in-approval invoices move in one controlled extract taken after the prior close is signed off, tied to a control total, plus a reconciled delta, logged by record ID and closed at a set cutoff, for anything that changed afterward. The old system stops paying on go-live day and stays read-only until after the first close.
- How long does AP automation implementation take without disrupting month-end close?
- What does a close-aware cutover calendar look like?
- How do you freeze the vendor master and migrate open invoices?
- Should you run the old and new AP process in parallel?
- How do you reconcile the first close after go-live?
- What belongs in an AP automation rollback plan?
- Go live in weeks with Corpay
Switch to Corpay
Discover how making the move to Corpay streamlines payments and strengthens your business.
Talk to an ExpertSmarter payments. Stronger growth. Keep business moving.
Corpay powers payments for 800,000+ businesses worldwide. Let’s build what’s next for yours.