39. ERP as a value lever in M&A

The deal team had a clean value case: reduce working capital, consolidate procurement, speed up reporting, and move finance to a shared service model within year one.

The target’s ERP was described as “fit for purpose.” It ran order entry, purchasing, inventory, financial postings, and month-end close. It had been in place for years. The CFO trusted the team that supported it.

Then the first 100-day plan started to take shape.

Procurement savings depended on a common vendor master and enforceable approval flows. Working capital improvement depended on inventory accuracy by plant and SKU. Finance cost reduction depended on a faster close and common chart of accounts. Commercial margin actions depended on cleaner pricing and product profitability. None of those levers could move at the pace in the model unless ERP changed.

That is the decision many deal teams make too late:

Should ERP be treated as a value lever in the deal plan, a stabilization gate before value work starts, or a deferred transformation after the business is safe?

This is not an architecture preference. It is a capital allocation decision. ERP can accelerate value, block value, or consume cash before the thesis can move. The mistake is treating all three cases as one “ERP workstream.”

ERP is not one decision

ERP in M&A touches too many outcomes to be managed as a single technology topic. It sits behind revenue, cash, margin, control, reporting, procurement, supply chain, and compliance.

That does not mean every deal needs an ERP program. It means the deal team needs to choose the ERP posture early and make the consequences explicit.

There are three viable postures.

1) ERP as a value lever

Choose this posture when the business case depends on ERP-enabled change and the current estate can absorb it without putting operations at risk.

Examples:

• procurement savings require supplier master cleanup, approval controls, and spend visibility
• working capital improvement requires inventory discipline, planning parameter cleanup, and purchase order compliance
• finance cost reduction requires close standardization, reporting automation, and a common chart of accounts
• margin expansion requires cleaner pricing, rebate, customer, and product data

In this posture, ERP is not a back-office remediation item. It is part of the value plan. The ERP roadmap should have value gates with dates, owners, and EBITDA or cash impact attached.

2) ERP as a stabilization gate

Choose this posture when ERP weakness could block Day-1 stability, first close, TSA exit, or operational continuity.

Examples:

• the ERP is shared with the seller and the TSA period is short
• month-end close takes more than eight business days with heavy manual journals
• order-to-cash depends on fragile interfaces to CRM, WMS, tax, or billing
• key ERP knowledge sits with one employee or one contractor
• the system is out of vendor support or has audit findings in access controls

In this posture, the right move is not to chase ERP-enabled value first. It is to protect revenue, cash, close, payroll, inventory, and controls. Value work waits until the gate is safe.

3) ERP as a deferred transformation

Choose this posture when ERP needs to change, but the first-year value case can be captured through process fixes, reporting layers, data controls, or selected integrations without full core replacement.

Examples:

• the buyer and target run different ERP platforms, but year-one value depends on procurement and reporting, not a single instance
• a carve-out needs an ERP stand-up, but replacement would overload the team before TSA exit
• the target’s ERP is imperfect but stable, and the hold period does not support a major program before operating basics are fixed

Deferred does not mean ignored. It means the transformation is sequenced after the first value and stability gates. The deal model should still include discovery, design, one-time cash, and leadership capacity.

The value impact: where ERP changes the model

ERP should change the deal plan when it affects one of six value lines.

EBITDA timing. Procurement savings, finance shared services, plant process standardization, and SG&A reduction often depend on ERP controls and data. If supplier and item masters are messy, the buyer may announce savings that cannot be enforced.

Working capital. Inventory accuracy, purchase order discipline, payment terms, billing timeliness, and credit controls are ERP-driven in many businesses. A two-point working capital improvement plan can disappear if stock counts are unreliable or invoices lag because interfaces fail.

Revenue protection. Quote-to-cash, tax, billing, subscription management, customer credit, and order allocation sit close to ERP. A poorly sequenced ERP change can slow orders or create billing errors during the first two quarters, when the deal team is trying to prove momentum.

TSA cost and exit risk. In carve-outs, shared ERP instances and shared finance processes can keep the buyer on seller services longer than planned. Each extension consumes cash and management attention. It also gives the seller more control over timing.

One-time cash. Data cleanup, interface remediation, license true-ups, system integrator support, test environments, upgrade work, and temporary bridges can be mandatory spend. If not funded, they show up later as emergency cost.

Control and reporting confidence. The first post-close close is a credibility event. If management cannot produce a clean reporting pack, the board loses confidence in the value plan, even if operations are running.

The practical question is not “How good is the ERP?” The question is: which value lines are ERP-dependent, and what has to be true before each value line can move?

What goes wrong when the posture is not chosen

ERP failures in deals usually come from ambiguity, not lack of effort.

The business assumes ERP is a value lever. IT treats it as stabilization. Finance assumes transformation can wait. Operations assumes the existing system will absorb new plants, products, suppliers, and reporting needs. The program plan labels all of it “ERP.”

Four patterns follow.

Pattern 1: the team funds replacement when the first need is control

A buyer decides to move the target onto its ERP instance to create standardization. The program starts design workshops before the target has a clean chart of accounts, reliable inventory balances, or tested interface ownership.

The result is predictable. The new design inherits dirty data and unclear process ownership. Testing expands. Cutover slips. The team spends money on a destination design while the first close still depends on spreadsheets.

Deal consequence: value moves right, one-time cash rises, and finance savings become hard to count.

Pattern 2: the team stabilizes forever

Another buyer sees ERP risk and chooses to “keep the lights on.” That is often the right first move. But no one defines the exit criteria from stabilization.

Six months later, the same manual journals, vendor duplicates, pricing exceptions, and inventory adjustments remain. Procurement savings are delayed because controls were never redesigned. The business is stable, but the deal thesis is still waiting.

Deal consequence: the first-year synergy story becomes a year-two improvement plan.

Pattern 3: deferred transformation becomes unfunded debt

The deal team decides not to replace ERP in year one. That may be right. But the model removes the cost instead of moving it.

The ERP remains out of support. The customization footprint stays undocumented. The buyer adds reporting tools and manual bridges around the core. By exit, the business has higher run cost and a buyer diligence issue of its own.

Deal consequence: exit multiple risk increases because the next buyer discounts for unresolved core systems work.

Pattern 4: ERP is used to justify value without owning the business change

ERP can enforce procurement compliance, automate close tasks, and improve inventory control. It cannot make category managers use negotiated contracts, finance teams own reconciliations, or plant leaders fix planning parameters.

When ERP is treated as the whole solution, business ownership disappears. The system goes live, but the value does not.

Deal consequence: the program claims delivery while EBITDA, cash, and reporting outcomes lag.

Decision triggers: choose the ERP posture

The posture should be selected with explicit triggers. The following rules are a starting point.

Treat ERP as a value lever when:

• at least 30% of the first-year value case depends on procurement, working capital, finance productivity, pricing, or supply chain controls inside ERP
• the current ERP is supported, stable, and has named owners for the modules that touch value: FI/CO, SD, MM, PP, WM/EWM, HR, or reporting
• the target can provide reliable master data extracts for vendors, customers, items, chart of accounts, plants, and cost centers within two weeks
• integration or configuration work can be delivered without putting Day-1, first close, payroll, or order flow at risk
• the business owners for each value lever are named before close

If those conditions hold, put ERP gates directly into the value plan. Do not bury them under an IT roadmap.

Treat ERP as a stabilization gate when:

• TSA exit requires separating shared ERP processes in less than nine months
• month-end close takes more than eight business days or depends on more than 25 recurring manual journals
• order-to-cash, inventory, payroll, or payment runs depend on interfaces with weak monitoring or unclear ownership
• more than one core ERP instance supports the same legal entity, plant, or product flow without clear operating boundaries
• support risk, cyber control gaps, or access findings could affect audit, close, or transaction processing
• ERP knowledge is concentrated in one employee, one contractor, or one seller team

If these triggers show up, stabilize first. Count only the value that can be achieved without stressing the fragile point.

Treat ERP as deferred transformation when:

• the ERP estate is too complex to change safely in the first 100 days, but the business can operate reliably
• the first-year value case can be captured through reporting layers, data cleanup, interface controls, or process governance
• replacement would require a full process redesign across finance, supply chain, manufacturing, or HR
• the buyer lacks available ERP talent because the same team is needed for Day-1, TSA exit, audit readiness, and integration
• the hold period or exit plan supports a staged program with clear funding and milestones

If transformation is deferred, document what is deferred, what is funded now, and what must not be built as a throwaway workaround.

Evidence asks that force the answer

The best evidence is not a slide that says “ERP is stable.” It is the operating record.

1) ERP value dependency map

Ask finance, operations, procurement, and IT to map each value lever to the ERP objects and workflows it depends on.

For example:

• procurement savings: supplier master, item categories, purchase approvals, contract repository, invoice matching
• working capital: inventory balances, reorder parameters, demand planning, purchase orders, goods receipt, billing cycle
• finance productivity: close calendar, journal workflow, reconciliations, consolidation, reporting pack
• pricing improvement: customer master, product master, discount rules, rebates, tax, invoice accuracy

This map tells the team whether ERP is part of the value path or a background system.

2) Instance, legal entity, and process map

Ask for every ERP instance, client, company code, legal entity, plant, warehouse, country, and business unit. Include adjacent systems: CRM, CPQ, WMS, MES, planning, tax, billing, treasury, payroll, and reporting.

The goal is to find hidden dependencies. A business may look like one target in the model but five operating models in the systems.

3) Close and control package

Ask for the last three close calendars, manual journal counts, reconciliation status, audit findings, segregation-of-duties conflicts, privileged access exports, and finance incident logs.

If close is weak today, the buyer should be careful about counting fast reporting, finance headcount savings, or clean synergy tracking in the first two quarters.

4) Interface and batch failure evidence

Ask for interface inventory, batch schedules, error logs, job ownership, monitoring tools, and incident history. Focus on order entry, shipment, invoicing, inventory, payroll, banking, and tax.

ERP does not need to be perfect. It needs to fail visibly, with owners and recovery paths.

5) Customization and change capacity

Ask for custom code, extensions, scripts, workflows, reports, forms, test environments, release calendars, defect backlog, enhancement backlog, and named ERP owners by module.

This evidence shows whether the team can change ERP and run the business at the same time.

6) Cost bridge

Ask for licenses, support partners, system integrator spend, open purchase orders, project commitments, upgrade needs, contract renewal dates, and known vendor roadmap constraints.

ERP cash is often split across IT, finance, operations, and transformation budgets. The bridge prevents required spend from hiding outside the model.

How best teams handle it

Strong deal teams do not ask ERP to do everything at once. They make a posture call and then govern the work against value and risk.

They write the ERP deal thesis in one page

The one-pager should include:

• the ERP posture: value lever, stabilization gate, or deferred transformation
• value lines affected: EBITDA, cash, revenue, TSA, reporting, controls
• the first three ERP gates and dates
• one-time cash required before Day 100 and before year one
• the named business owner and technology owner
• what is explicitly out of scope for the first 100 days

This keeps ERP from becoming a debate about platforms. The platform choice matters only after the deal logic is clear.

They split stabilization from value capture

Stabilization has different rules from value capture.

Stabilization protects transaction flow, close, payroll, inventory, security, and control. It should use conservative change windows, named recovery paths, and business acceptance tests.

Value capture changes process, data, reporting, controls, and behavior. It should have benefits, gates, and owners attached.

When both are run by the same overloaded team with one plan, stabilization wins by default and value slips quietly.

They avoid making ERP replacement a first-year dependency unless the thesis demands it

One ERP can be the right answer. It is rarely the fastest answer.

If the first-year value case depends on procurement visibility, consolidated reporting, or supplier compliance, the team may get there faster with master data cleanup, process controls, and a reporting layer while leaving the core in place.

If the first-year value case depends on common manufacturing planning, shared order allocation, unified inventory, or a carved-out ERP before TSA expiry, replacement or stand-up may be unavoidable.

The trigger is value and risk, not the desire for a cleaner architecture.

They put business owners on ERP gates

IT can configure approvals. Procurement owns compliance. IT can build reporting. Finance owns definitions and close discipline. IT can migrate inventory data. Operations owns accuracy and cycle counts.

ERP value is lost when business ownership is assigned after design. Best teams name owners before close and give them decision rights over process, data, and acceptance.

They fund the bridge, not just the destination

Most deals need interim controls: reporting bridges, interface monitoring, data cleanup, temporary support, access remediation, and manual reconciliation support.

These are not signs of failure. They are the cost of moving from the current operating model to the target one without breaking the business.

The failure is pretending the bridge is free.

The practical decision tree

Use a simple sequence.

First: Is Day-1, first close, payroll, order flow, inventory, or TSA exit exposed by ERP?

If yes, ERP is a stabilization gate. Fund remediation, define exit criteria, and delay ERP-enabled value that stresses the weak point.

Second: Does more than 30% of first-year value depend on ERP workflows, data, controls, or reporting?

If yes, ERP is a value lever. Put ERP gates in the value plan and assign business owners.

Third: Can the team change ERP without overloading the same people needed for close, TSA exit, audit, or operations?

If no, defer transformation. Use wrappers, reporting, data controls, and selected interfaces to protect value timing.

Fourth: Does the current ERP create exit risk for the buyer’s future sale or IPO path?

If yes, fund transformation discovery now even if execution waits. Do not let deferred work become hidden debt.

The output should be a posture, not a list of findings.

Monday-morning actions

In the next 10 business days, the deal lead, CFO, CIO, and operating lead should force six outputs.

1. Name the ERP-dependent value lines. Tie each one to EBITDA, working capital, revenue, TSA cost, reporting, or control risk.
2. Pick the posture. Value lever, stabilization gate, or deferred transformation. If the team cannot choose, it lacks evidence.
3. Pull the hard artifacts. Instance maps, close calendars, interface logs, customization inventory, access exports, module ownership, and ERP cost bridge.
4. Set three gates. Day-1/first close gate, Day-100 value gate, and year-one transformation or deferral gate.
5. Fund the bridge. Data cleanup, monitoring, temporary support, reporting, access remediation, and test environments should be in the model.
6. Assign business owners. Procurement, finance, operations, and commercial leaders must own the process and data outcomes that ERP supports.

ERP can be a value lever in M&A, but only when the deal team treats it as part of the thesis, not a system preference. If the core is fragile, stabilize it. If the value path runs through ERP, manage it like a value program. If transformation can wait, defer it deliberately and fund the bridge. The wrong answer is to call ERP “post-close execution” and discover in month three that the model was depending on it all along.