13. ERP due diligence: when the core system is the deal

The deal model assumed faster close, tighter inventory, procurement savings, and cleaner margin reporting within the first two quarters.

The target ran on SAP ECC with heavy order management customization, a bolt-on warehouse system, a pricing workbook used by sales operations, and a month-end close that still depended on 40 manual journals. Management described the ERP as stable. That was true in the narrow sense: the business could run today.

But the deal did not require the ERP to run today. It required the ERP to support a new operating model, new controls, a faster reporting cadence, and integration with the buyer’s procurement and commercial systems on a tight clock.

That is the ERP diligence question that matters:

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.

The buyer changes the chart of accounts, but old product and customer structures do not map cleanly. Management gets a reporting pack, but margin by product is still reconciled manually. Procurement savings are announced, but supplier master cleanup takes longer than expected. A warehouse move is scheduled, but inventory accuracy is too weak to support cutover. Interfaces fail quietly, so invoices lag and working capital slips. The first close takes two extra weeks, and nobody trusts 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.

What best teams do before signing

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.

Monday-morning actions

In the next 10 days, the deal lead and technology diligence lead should force five outputs.

1. Name the ERP-dependent value levers. List the revenue, working capital, EBITDA, and reporting assumptions that depend on ERP changes.
2. 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.
3. Pull the hard artifacts. Get instance maps, customizations, interface logs, close calendars, access exports, incidents, and ERP contracts.
4. Set decision triggers. Decide what happens if support risk, close weakness, TSA timing, data quality, or capacity gaps cross the thresholds above.
5. 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.