Very few operational events land as hard on an asset-based lending relationship as an ERP migration or a major accounting-system conversion. The finance team has spent months on the project. The CFO is anxious about go-live. The controller is behind on reconciliations. Then someone remembers: the borrowing-base certificate is due in three weeks, and the trial balance is going to look nothing like it did a month ago. The receivables aging is coming out of a new system in a new format. Inventory counts are being restated. The lender has not been told any of this in a way that means anything to them.
This is the exact scenario where a borrower loses lender confidence not because the business is worse — often the business is fine — but because the reporting has become unreliable during the exact window when the lender relies on it most. The good news: with early communication and a defensible transition plan, most middle-market ABL lenders will work through an ERP migration without pulling availability. This piece walks through what those conversations should look like and what CFOs should be prepared to demonstrate.
Why lenders worry about ERP migrations
Asset-based lending is fundamentally a reporting-driven credit product. The lender advances against receivables and inventory based on data the borrower produces — the borrowing-base certificate, receivables aging, inventory listing, roll-forwards, and the general ledger. When the source of that data changes, three things happen simultaneously that make lenders nervous.
Reporting continuity breaks
The formats the lender has been receiving for years — often for the entire life of the facility — are about to be replaced. The lender's back office and field examiner have muscle memory around the old reports. Now the receivables aging comes out of NetSuite instead of Sage, or out of Dynamics 365 instead of Great Plains, and the columns are different, the aging brackets calculate differently, and reconciliation to the GL is being redone.
Cutover balances are frequently wrong on day one
In every ERP migration, opening balances get loaded into the new system. In every ERP migration, some subset of those balances is wrong on go-live day — a wrong tax rate on a batch of invoices, a customer master synched incorrectly, an inventory count that didn't match the sub-ledger. Most of these are corrected within days or weeks. But if a borrowing-base certificate is being pulled from the new system before those corrections are complete, availability could swing meaningfully in either direction with no underlying operational change.
Reconciliation slippage
Even when the numbers are right, the reconciliations take longer during and just after a conversion. Month-end close often runs 5-10 days later than usual for two or three cycles. If the credit agreement requires a borrowing-base certificate within 15 days of month-end, and month-end close now takes 20 days, the borrower is in a technical reporting default.
What to tell your lender — and when
The single largest determinant of how an ERP migration lands with your ABL lender is what you tell them and when. Below is a reasonable communication cadence for a middle-market ABL relationship.
90-120 days before go-live: written heads-up
Send the agent (or your relationship manager) a brief written note covering the scope of the migration, the target go-live date, the systems being replaced, the systems replacing them, the modules being converted (order-to-cash and inventory matter most; general ledger and HR matter less), and the internal team leading the effort. The point of this note is not to ask for anything — it is to put the lender on notice that a material operational event is coming.
60-90 days before go-live: sample reports and reconciliation plan
Send parallel-run samples of what the new receivables aging, inventory listing, and borrowing-base certificate will look like. Include the reconciliation between the old-system report and the new-system report for the same period. This is the single most important step in keeping the lender comfortable. If the borrower can demonstrate that the new-system output ties to the old-system output before go-live, most lenders will not require additional accommodations.
30 days before go-live: cutover and blackout plan
Provide the specific cutover plan: when the old system is frozen, when the new system goes live, whether there is a hard cutover or a parallel-run period, and what backup exists if something goes wrong. Confirm the borrowing-base certificate cadence during cutover — many borrowers propose to file the last pre-cutover certificate a few days early and to defer the next one by two weeks. That is usually acceptable when it is discussed 30 days in advance, and it is a problem when it is discussed the day it happens.
Go-live and the first 30 days: enhanced communication
Increase the cadence of update calls for the first month. Even a brief weekly email — cutover completed as planned, month-end close on track, no material data issues identified, first BBC out of new system delivered — reduces lender anxiety materially. Silence during this period is the single most common mistake.
First BBC and first field exam out of the new system
Expect that the first borrowing-base certificate out of the new system will be examined more closely than usual, and that a targeted field-exam visit may be requested in the 60-90 days after go-live to walk through the new reporting and confirm reconciliation to the general ledger. This is not a sign of a problem — it is a standard checkpoint. Preparing for it is straightforward when the parallel-run samples were shared in advance.
What to be ready to demonstrate
Beyond communication, there are concrete artifacts a well-prepared borrower can put on the table.
Parallel-run reconciliation
For the last one or two months before cutover, run both systems in parallel and produce the same reports out of both. The reconciliation between them should be tight — every material variance explained. This is the single most persuasive artifact in the migration conversation.
Data governance during cutover
Written procedures for how open orders, in-transit inventory, unposted cash, and unbilled work will be handled during cutover. Who is responsible for what. How exceptions are captured. Where the reconciliation lands. Lenders do not need to read every page; they need to know it exists.
Cash management continuity
Confirm that cash-application processes, lockbox integration, and cash-dominion mechanics continue to function through cutover. If the ABL involves a controlled lockbox arrangement or blocked-account structure, this is a specific attention point — cash-application errors during the first weeks of the new system can create timing distortions in the borrowing base even when the underlying receivables are fine.
Physical inventory count within the transition window
Many companies perform a physical count as part of an ERP cutover. Sharing the results with the lender — particularly if it identifies any material reconciling items — is much better than the lender learning about it in the next field exam.
User access and internal controls
Confirm that SOX-level or SOX-equivalent internal controls have been ported to the new system. Lenders and their field examiners will ask; having the documentation ready avoids delay.
What to negotiate ahead of time
In many cases, ABL agreements can accommodate the operational disruption of an ERP migration with modest amendments that are much easier to negotiate before go-live than after.
Reporting date deferrals
A one-time or two-time deferral of the borrowing-base certificate delivery date during cutover. This is a routine amendment that most ABL lenders will accommodate when it is asked for in advance. It becomes a technical default if it is not.
Suspension of certain covenants during the transition period
Some agreements have covenants that could be inadvertently tripped during a migration — for example, a cap on unposted cash or a limit on unbilled work — that make sense during normal operations but are not appropriate benchmarks during a cutover. A short-duration modification (30-60 days) is often achievable.
Reserved availability
Some borrowers proactively agree to a modest additional reserve for the first 60 days after go-live, in exchange for the lender agreeing not to reduce availability further based on transition-period reporting anomalies. This is a give-and-take that protects both parties from surprises during the noisy period.
Field exam scope
Confirm the scope and timing of the post-cutover field exam. Most lenders will schedule one within 60-90 days of go-live; agreeing on the scope ahead of time (which modules to review, which reconciliations to walk through) reduces friction. Note that field examination is performed by third-party field examiners like ABLC and by the lender's own internal team; DCE does not perform field exams.
Common mistakes to avoid
Not telling the lender at all
Some borrowers hope the migration will happen invisibly and reveal itself only after everything is working. This never works. The first sign the lender gets is usually a report format that has changed, a delivery that is late, or a variance that has appeared without explanation — and the anxiety is significantly worse than if the conversation had happened earlier.
Doing the migration during a busy season
Going live with a new ERP during the seasonal peak (retailer holiday season, agricultural harvest, apparel importer inventory build) compounds every risk. Where possible, cutover should happen in the seasonally slow period, and the lender should be told this reasoning.
Cutting over receivables and inventory modules on the same day
Where the ERP scope allows, staggering the go-live of the receivables module and the inventory module by 30-60 days reduces the amount of borrowing-base disruption happening at once. This is worth discussing with the ERP implementation team and the lender.
Under-resourcing month-end close during the first cycles
The first three to four month-end closes after go-live take longer than normal. Under-resourcing them — because the finance team is exhausted from the implementation — is where reporting-default risk actually comes from.
Letting the field examiner walk in cold
If the field examiner arrives without having received the parallel-run samples, the cutover plan, or the reconciliation package, the exam takes longer, produces more questions, and generates more follow-up. A one-hour prep call two weeks before the exam changes the tone completely.
Where DCE fits
Don Clarke — SFNet Hall of Fame 2021, Lifetime Achievement Award, author of "Asset Based Lending Disciplines" (the first ABL textbook), and trainer of more than 5,000 professionals at GE Capital, JP Morgan Chase, Lloyds, and Barclays — has watched borrowers manage ERP migrations well and poorly across four decades. The pattern of the ones who do it well is consistent: they treat the lender as a stakeholder in the project plan, they share parallel-run samples early, they document cutover controls, and they do not go silent during the transition period. The ones who do it poorly assume the lender will not notice, and then spend six months rebuilding trust after a series of surprise variances.
DCE advises borrowers preparing for a financing during or after a major system conversion, and helps CFOs and controllers frame the lender communication before, during, and after go-live. We work alongside the implementation team, internal audit, and outside CPAs — we do not implement ERPs, we do not act as auditors, and we do not underwrite or make credit decisions. See also our how to read an ABL borrowing-base certificate line by line and signs your lender is losing interest guides.
ABLC (ablc.net) is DCE's sister firm serving lenders with due diligence, field examination, and training services — including post-conversion field exams that walk through ERP cutover, reconciliation, and reporting continuity.
Planning an ERP migration during an ABL relationship?
DCE helps borrowers frame the lender communication, prepare parallel-run samples, and document cutover controls so the migration does not damage a working credit facility. We work alongside your implementation team, controller, and outside CPAs.
Submit Your DealEducational only; not legal, tax, accounting, or IT-implementation advice. Every ERP migration is specific to the company, the facility, and the systems involved. Borrowers should engage qualified implementation partners, CPAs, and — where the facility complexity warrants — restructuring or lending counsel.