Can the core system support the value plan and operating model on the required clock, or must it be stabilized, replaced, carved out, or funded as mandatory cash?
If the answer is unclear, the investment case is carrying a hidden assumption. ERP is not a back-office topic in that situation. It is the operating constraint behind revenue, cash, margin, reporting, and Day-1 stability.
Why ERP changes the investment case
ERP findings matter when they change one of five deal levers.
- Revenue timing: quote-to-cash, pricing, tax, billing, credit holds, and order fulfillment may not support the commercial plan.
- Working capital: inventory accuracy, demand planning, purchasing controls, and payment terms may not be controllable at the level the model assumes.
- EBITDA: procurement savings, finance headcount reduction, and shared service plans depend on standard processes and clean controls.
- One-time cash: upgrades, remediation, data cleanup, carve-out builds, or replacement programs become required before value can be captured.
- TSA exit: if the ERP is shared with the seller or technically hard to separate, the buyer inherits time pressure and service cost.
The diligence output should not be “ERP risk: medium.” It should say which value levers are safe to count, which require funding, and which need a different clock.
The common mistake: testing the system, not the deal requirement
Most ERP diligence starts with the wrong question: “Is the ERP good?”
That produces vague answers. SAP, Oracle, Microsoft Dynamics, NetSuite, Infor, and Epicor can all support good businesses. They can also block a deal plan if the configuration, data, custom code, or team capacity does not match what the buyer needs after close.
The better question is: what must ERP do differently because of this deal?
For a platform acquisition, the answer may be consolidated reporting, faster close, procurement control, or integration into the buyer’s customer and product master. For a carve-out, it may be a new legal entity structure, tax setup, bank interfaces, chart of accounts, and clean separation from shared seller processes. For a manufacturing asset, it may be MRP stability, inventory accuracy, standard costing, shop-floor integration, and warehouse cutover.
Same ERP. Different deal requirement. Different answer.
A practical diligence lens: fit, condition, and change capacity
ERP diligence should test three things in sequence.
1) Fit: does the ERP match the future operating model?
Fit is not feature coverage. Fit is whether the system can run the workflows the value plan needs.
Start with the workflows that touch money:
- quote-to-cash: pricing, orders, shipment, invoicing, tax, collections
- procure-to-pay: supplier master, purchase approvals, goods receipt, invoice matching, payment runs
- record-to-report: chart of accounts, consolidation, close, management reporting, audit trails
- plan-to-produce: demand planning, MRP, production orders, quality, warehouse movements
- master data: customers, products, vendors, items, plants, cost centers, legal entities
For each workflow, ask what changes post-close. New entities? New accounting policy? New customer hierarchy? New procurement categories? New plant structure? New warehouse provider? New reporting pack? The fit question is whether the current ERP can absorb those changes without breaking controls or slowing the value plan.
2) Condition: is the ERP stable, supported, and governable?
Condition is the difference between an ERP that runs and an ERP that can be trusted under deal pressure.
Check:
- version and vendor support status
- customization footprint and where business logic sits
- interface volume, failure rates, and ownership
- master data quality for customers, suppliers, items, pricing, and chart of accounts
- close calendar and manual journal volume
- access controls, segregation of duties, privileged users, and audit findings
- incident history, change success rate, and release windows
If the system is out of support, heavily customized in order-to-cash, and dependent on one contractor for interfaces, the buyer is not inheriting a system. The buyer is inheriting a constraint.
3) Change capacity: can the team alter ERP while running the business?
This is where many diligence reports are too polite.
The ERP team may be able to run the current business, close the books, support users, and fix defects. That does not mean it can also run a carve-out, integrate with the buyer, redesign controls, clean data, support a new warehouse provider, and deliver procurement synergies in the same 100 days.
Ask for the actual capacity:
- named ERP owners by module: FI/CO, SD, MM, PP, WM/EWM, HR, reporting
- contractor and system integrator dependencies
- open defect backlog and enhancement backlog
- current project load and blackout periods
- release cadence and test environment availability
- key-person exposure for interfaces, custom code, and reporting
If ERP capacity is already full, the deal plan needs either more cash, fewer early changes, or a different sequence.
Evidence asks that cut through management narrative
The fastest ERP diligence is evidence-led. Ask for artifacts that operating teams already use.
1) ERP architecture and instance map
Ask for all ERP instances and adjacent systems, including CRM, CPQ, WMS, MES, planning, tax, billing, treasury, and reporting tools. Show which legal entities, plants, countries, and business units sit on each instance.
Why it matters:
An ERP can look simple in the budget and complex in reality. Multiple instances, shared clients, local add-ons, and shadow reporting tools often set the separation or integration clock.
2) Critical workflow walkthroughs
Ask process owners to walk through order-to-cash, procure-to-pay, record-to-report, and inventory from transaction start to posting. Capture manual steps, handoffs, spreadsheets, approvals, and exceptions.
Why it matters:
ERP risk usually hides in exceptions. The standard process may be fine. The margin leak sits in pricing overrides, blocked orders, unapproved vendors, manual accruals, or inventory adjustments.
3) Customization and interface inventory
Ask for custom objects, enhancements, reports, workflows, forms, integrations, batch jobs, and interface error logs. For SAP, include custom code volume and enhancement points. For Dynamics, NetSuite, Oracle, or Infor, include scripts, extensions, workflows, and partner-built changes.
Why it matters:
Customization is not automatically bad. Customization in tax, pricing, revenue recognition, inventory valuation, or close can make upgrades, carve-outs, and process standardization much harder.
4) Close and control evidence
Ask for the last three close calendars, manual journal counts, reconciliation status, audit findings, segregation-of-duties conflicts, and finance user access exports.
Why it matters:
The first post-close close cycle is where ERP weakness becomes board-visible. If management cannot close reliably today, the buyer should not assume cleaner reporting after Day 1.
5) ERP cost and project bridge
Ask for ERP run cost, support partners, license contracts, project spend, open purchase orders, upgrade estimates, and known vendor roadmaps.
Why it matters:
ERP spend often sits across IT, finance, operations, and transformation budgets. Without a bridge, the model can miss mandatory cash and overstate run-rate synergies.
Decision triggers that should change price, terms, or timing
Good ERP diligence produces decision triggers, not long issue logs. The triggers below force a deal posture.
Trigger 1: ERP is out of support or forced onto a vendor roadmap inside 12-24 months
If a core ERP version loses support during the hold period, TSA period, or first integration wave, treat the upgrade as mandatory cash unless the business can run safely on extended support.
What it changes:
- add upgrade or replacement cash to the model
- delay synergies that depend on process redesign or system consolidation
- test whether the target has enough ERP capacity to upgrade and integrate at the same time
Trigger 2: More than two ERP instances support one operating model without clear ownership
Multiple ERPs can be fine if each supports a clean business boundary. They become a deal problem when one operating model needs common customers, items, pricing, procurement, or reporting across them.
What it changes:
- do not assume fast shared services or procurement savings
- fund master data and reporting control work before counting the full synergy
- decide whether to wrap the current estate or launch a replacement path
Trigger 3: TSA exit depends on separating a shared ERP in less than nine months
If the seller’s ERP supports the carved business through shared clients, shared master data, shared interfaces, or shared finance processes, a short TSA can be a value trap.
What it changes:
- negotiate TSA duration, exit waves, and service levels around ERP reality
- fund a minimum viable ERP environment, not just data extraction
- price stranded seller dependencies and buyer stand-up costs explicitly
Trigger 4: Month-end close takes more than eight business days with heavy manual work
If close depends on many manual journals, spreadsheet reconciliations, or late interface corrections, faster reporting is not a Day-1 benefit. It is a transformation item.
What it changes:
- reset reporting and synergy measurement timing
- fund close stabilization and control cleanup
- avoid finance headcount savings until process and data quality improve
Trigger 5: Order-to-cash or inventory relies on unmonitored interfaces
If orders, shipments, invoices, or inventory movements depend on batch jobs with weak monitoring and unclear ownership, ERP stability can fail under integration load.
What it changes:
- fund interface monitoring and ownership before touching the workflow
- slow commercial integration or warehouse change plans
- build Day-1 controls for failed postings, duplicate invoices, and inventory mismatches
Trigger 6: ERP knowledge is concentrated in one employee or one partner
If one person knows pricing configuration, custom code, interfaces, or month-end jobs, the first 100 days are exposed.
What it changes:
- add retention and knowledge transfer to mandatory deal actions
- require named backfill before counting ERP-enabled value
- avoid parallel ERP changes that depend on the same scarce people
What goes wrong after close
ERP failures in deals rarely start as dramatic system outages. They start as friction that compounds.
Common mechanisms include chart-of-accounts changes that do not map cleanly to product and customer structures, reporting that still requires manual margin reconciliation, supplier-master cleanup that delays procurement controls, warehouse moves blocked by weak inventory accuracy, and interfaces that fail silently. The result is slower close, delayed working-capital actions, and lower confidence in the numbers.
Each issue sounds operational. Together, they change deal economics.
The root cause is usually not a bad ERP. It is an unfunded mismatch between the system, the operating model, and the clock.
Convert ERP evidence into a deal posture
Strong teams do not try to solve ERP in diligence. They force a clear posture and fund the consequences.
1) They define the ERP deal requirement
They write down what ERP must support by Day 1, Day 100, and year one. Examples:
- new legal entity and statutory reporting by close
- buyer reporting pack by first month-end
- procurement category visibility by Day 100
- inventory controls before warehouse consolidation
- clean order-to-cash data before cross-sell reporting
This turns ERP from a general risk review into a deal execution test.
2) They separate stabilization, integration, and transformation
These are different jobs.
- Stabilization: keep revenue, cash, close, and inventory safe.
- Integration: connect ERP to buyer controls, reporting, data, and selected processes.
- Transformation: replace, standardize, or redesign the ERP model.
Combining all three into one post-close workstream is how teams overload ERP capacity and miss the value clock.
3) They create a funded ERP posture
The posture should be one of four calls:
- Stabilize: keep the ERP but fix support, controls, data, and interfaces before major change.
- Wrap: leave ERP in place while using reporting, APIs, or process controls to support the value plan.
- Carve: build or separate a viable ERP environment because TSA or shared-process risk sets the clock.
- Replace: move to a new ERP or buyer instance because fit, support, or economics cannot be solved in place.
The posture is not an architecture preference. It is a deal decision tied to cash, timing, and owner capacity.
Force five ERP decisions before signing
In the next 10 days, the deal lead and technology diligence lead should force five outputs.
- Name the ERP-dependent value levers. List the revenue, working capital, EBITDA, and reporting assumptions that depend on ERP changes.
- Run four workflow walkthroughs. Cover quote-to-cash, procure-to-pay, record-to-report, and the most deal-specific operational flow, such as inventory or manufacturing.
- Pull the hard artifacts. Get instance maps, customizations, interface logs, close calendars, access exports, incidents, and ERP contracts.
- Set decision triggers. Decide what happens if support risk, close weakness, TSA timing, data quality, or capacity gaps cross the thresholds above.
- Write the funded posture in one page. Stabilize, wrap, carve, or replace. Include cash, timing, owners, and which value levers move as a result.
The investment committee does not need a complete ERP design. It needs to know whether the system can carry the deal thesis. If it cannot, the right answer is not a softer diligence paragraph. It is a different price, a different clock, or a funded plan before the deal closes.