41. SAP in M&A: common scenarios and pitfalls

The buyer wanted a clean answer: keep the target on the seller’s SAP for 18 months, then migrate onto the buyer’s S/4HANA program.

The first pass looked sensible. The seller offered TSA support. The buyer already had SAP skills. The investment case counted procurement savings, finance reporting, and inventory improvement by the second full quarter after close.

Then the SAP facts changed the deal clock. The target was not on a clean SAP instance. It shared a client with two retained seller businesses, used custom pricing routines in SD, ran plant-level inventory through EWM, sent tax data through a local add-on, and depended on BW reports maintained by one seller contractor. The buyer’s S/4HANA program had a release freeze for six months after close. The TSA did not include project work.

The real decision was not “SAP or not SAP.” It was:

Which SAP posture should the deal take: stay on seller SAP, clone, carve, migrate, or redesign around S/4HANA timing and deal economics?

That choice determines Day-1 stability, TSA cost, one-time cash, working capital control, and when ERP-enabled synergies can be counted. A weak answer creates the worst pattern in SAP deals: the business stays operational, but the value plan waits.

The five SAP postures

Most SAP deal situations fit one of five postures. The wrong posture is often chosen because teams start with technology preference instead of deal constraint.

1) Stay on seller SAP

The acquired or carved business remains on the seller’s SAP environment under TSA while the buyer prepares a later exit.

This works when the business is small relative to the seller, the seller has incentive to support the TSA, data boundaries are clean, and the value plan does not require early process change inside SAP.

It fails when the TSA becomes a holding pattern. The buyer cannot change pricing logic, chart of accounts, approval workflows, reporting, or master data at the pace the deal model assumes. The seller protects stability, not the buyer’s integration agenda.

2) Clone the SAP environment

The seller creates a technical copy of the relevant SAP system or instance, then removes retained data and hands the copy to the buyer.

This can be the fastest way to preserve business continuity when the target already runs on a mostly dedicated SAP instance. It is rarely cheap. The clone carries the seller’s configuration, custom code, data quality, security roles, interfaces, and technical debt into the buyer’s environment.

The clone decision is attractive when TSA is short and the buyer needs a working replica. It is dangerous when the clone is treated as a clean future platform.

3) Carve the business from shared SAP

The team separates legal entities, company codes, plants, customers, vendors, materials, open orders, inventory, balances, history, roles, and interfaces from a shared seller SAP estate.

This is the hardest posture to manage because it is both a business separation and a data separation. Shared master data and shared process variants usually matter more than server architecture.

A carve works when the scope is narrow, the seller has strong data ownership, and the TSA gives enough time for multiple extraction and reconciliation cycles. It breaks when teams discover late that a company code is clean but the customer, product, tax, pricing, and reporting structures are shared.

4) Migrate to the buyer’s SAP

The target moves into the buyer’s SAP estate, often as a new company code, plant, sales organization, purchasing organization, or country template.

This is the natural answer when the buyer has a mature SAP platform and the target is operationally similar. It is also the posture most likely to be overpromised. Moving into buyer SAP requires process fit, master data fit, controls fit, and enough buyer capacity. The buyer’s template is not free simply because it already exists.

The migration works when the target can adopt the buyer’s process with limited exception handling. It fails when the buyer forces a template onto a business with different pricing, manufacturing, service, tax, or regulatory requirements.

5) Redesign around S/4HANA

The deal uses separation or integration as the trigger to move onto S/4HANA, often with RISE with SAP, a new finance model, clean core principles, and rationalized add-ons.

This can create the best long-term answer. It can also destroy the first year if the deal needs Day-1 stability, fast synergy capture, or low execution risk.

S/4HANA redesign should be a deal decision, not an IT aspiration. If the value plan depends on procurement control and close acceleration inside 100 days, a full redesign may be the wrong first move. If ECC support risk, fragmented instances, and poor controls would force a program anyway, redesign may be mandatory cash.

Where value is made or lost

SAP posture changes deal economics through five routes.

TSA cost and exit risk: staying on seller SAP can look cheap until service caps, project exclusions, change freezes, data extraction fees, and exit penalties appear. A one-year TSA with no clean exit design is not a plan. It is a deferral.

One-time cash: cloning, carving, migration, S/4HANA redesign, interface rebuilds, data cleanup, license true-ups, security remediation, and testing environments can move cash needs materially. These costs often sit outside the first synergy model because they are split across IT, finance, operations, and tax.

Synergy timing: SAP posture controls when procurement, finance, inventory, and reporting synergies can start. If supplier master data cannot be consolidated for nine months, negotiated procurement savings may not convert to EBITDA on the modeled clock.

Working capital: inventory accuracy, credit limits, invoicing, payment runs, tax postings, goods receipt, and intercompany flows sit inside SAP. A poor cutover can delay invoices, duplicate payments, freeze shipments, or create inventory write-offs.

Management control: the first post-close close cycle tests whether the buyer can see revenue, margin, cash, inventory, and backlog. If SAP reporting stays in seller BW or depends on retained people, the buyer may own the business without owning the numbers.

The value question is simple: which SAP posture protects Day 1 while creating a credible path to the operating model in the deal thesis?

The common pitfall: confusing instance boundaries with business boundaries

Deal teams ask whether the target has its own SAP instance. That is useful, but incomplete.

A dedicated instance can still depend on seller-controlled identity, BW, PI/PO, EDI, Ariba, tax engines, bank connectivity, master data governance, Basis support, Solution Manager, or shared job monitoring. A shared instance can sometimes be separated cleanly if company codes, plants, customers, vendors, and interfaces are truly distinct.

The test is not where the system runs. The test is where the business logic and data dependencies sit.

Ask the seller to map these dependencies:

• company codes, controlling areas, plants, storage locations, sales organizations, purchasing organizations, and profit centers
• customer, vendor, material, pricing, chart of accounts, tax, and bank master data
• SD, MM, FI/CO, PP, WM/EWM, TM, GTS, Ariba, SuccessFactors, Concur, BW, BPC, SAC, PI/PO, CPI, and local statutory tools
• open orders, open purchase orders, invoices, credit memos, inventory balances, intercompany balances, fixed assets, and historical reporting
• custom code, forms, batch jobs, interfaces, security roles, and privileged access

If that map does not exist by signing, the buyer is accepting a SAP dependency without pricing it.

Decision triggers

The SAP posture should change when the facts cross specific thresholds.

If TSA is under 12 months and SAP is shared, do not rely on a later clean carve

A shared SAP environment with a sub-12-month TSA leaves little room for data discovery, design, build, testing, reconciliation, user acceptance, and cutover. If the seller also excludes project work from the TSA, the buyer should assume either a fast clone with cleanup debt or a minimum viable new build.

What changes in the model:

• add separation program cash before close
• delay SAP-enabled synergies until after stabilization
• negotiate TSA extension rights and exit wave mechanics

If the target is on ECC and S/4HANA is required inside 24 months, treat transformation as mandatory cash

ECC timing cannot be handled as a vague future IT roadmap if it lands inside the hold period, TSA exit, or buyer integration wave. The buyer needs to decide whether the deal funds an interim posture or goes straight to S/4HANA.

What changes in the model:

• separate “run safely” spend from “redesign” spend
• avoid double-paying for clone now and redesign immediately after unless risk requires it
• test whether finance, procurement, and operations can absorb the change

If more than 20% of order-to-cash logic is custom or manual, slow commercial integration

Custom SD pricing, tax, rebates, credit management, EDI, or billing forms can block customer migration and revenue reporting. A buyer that pushes commercial integration before testing these flows can disrupt invoicing and collections.

What changes in the model:

• make order-to-cash testing a gating item
• fund interface monitoring and exception handling
• hold back revenue synergy timing until invoicing is proven

If the buyer’s SAP template cannot support target operations with fewer than five material exceptions, do not force-fit the template

Template adoption is powerful when the business model matches. It is expensive theater when the target has different manufacturing, service, project accounting, subscription billing, export control, batch traceability, or local statutory needs.

What changes in the model:

• create a fit-gap estimate tied to named process exceptions
• decide which exceptions are temporary, permanent, or deal-breaking
• keep local process where standardization would damage margin or service levels

If data reconciliation needs more than two mock cycles, move the cutover date or reduce scope

SAP cutovers fail when open items, inventory, fixed assets, customer balances, vendor balances, tax data, or historical sales data do not reconcile. Two failed mock conversions are a signal, not a project delay to explain away.

What changes in the model:

• add a cutover gate owned by finance and operations, not only IT
• reduce historical data scope if continuity can be protected another way
• extend TSA data access rights beyond system exit

If SAP knowledge sits with one seller employee or one systems integrator, fund retention and knowledge transfer

Custom code, pricing routines, batch jobs, and month-end activities are often known by a small group. If those people do not transfer or stay available, the buyer inherits configuration without operating knowledge.

What changes in the model:

• make named knowledge holders part of closing conditions or TSA staffing
• fund parallel run support
• require runbooks for close, interfaces, security, and batch jobs

Evidence asks that produce a real SAP answer

The diligence team does not need a full SAP blueprint before signing. It does need enough evidence to choose a posture and price the consequences.

SAP estate map

Ask for the SAP instance map, client structure, modules in use, version, hosting model, Basis ownership, add-ons, and linked systems. Include ECC, S/4HANA, BW, BPC, SAC, PI/PO, CPI, GTS, EWM, TM, Ariba, Concur, SuccessFactors, tax engines, banks, EDI providers, WMS, MES, CRM, and planning tools.

The map should show which legal entities, plants, warehouses, sales organizations, and countries sit where.

Separation and integration dependency map

Ask for shared master data, shared company codes, shared plants, shared interfaces, shared jobs, shared reporting, shared support teams, and shared infrastructure. Separate “technically shared” from “operationally shared.” Both matter, but they create different work.

Custom code and change history

Ask for custom objects, enhancement points, forms, workflows, Z reports, user exits, BAdIs, transports, release history, failed changes, and defect backlog. For S/4HANA readiness, ask for simplification item checks and custom code analysis if available.

Custom code is not automatically bad. Custom code in pricing, tax, revenue recognition, inventory valuation, or intercompany is where deal risk concentrates.

Open transaction and data quality evidence

Ask for open sales orders, purchase orders, invoices, goods receipts, customer balances, vendor balances, inventory balances, fixed assets, blocked documents, duplicate masters, incomplete masters, and reconciliation reports.

Data quality is not an abstract problem. It becomes delayed cash collection, missed shipments, wrong inventory, late close, and disputed working capital.

License and commercial position

Ask for SAP license agreements, named user counts, engine metrics, indirect access position, HANA database terms, support fees, cloud subscriptions, SI contracts, and seller rights to transfer or sublicense. In carve-outs, ask whether the buyer can use seller licenses during TSA and what happens after exit.

Licensing can change the economics of a “simple clone.” A technical copy without usage rights is not an operating model.

TSA service schedule

Ask for what the seller will actually provide: run support, incidents, change requests, project work, reporting, data extracts, security administration, batch monitoring, interface fixes, compliance support, cutover help, and after-hours coverage.

The service schedule should include volume caps, response times, exclusions, fee escalators, data access rights, and termination mechanics. If project work is excluded, write that into the SAP posture decision.

How the posture decision works

Use the posture decision in sequence. Do not start with the preferred platform.

First, protect Day 1. If the business cannot ship, invoice, pay suppliers, close books, or meet statutory requirements without seller SAP, stay on seller SAP or clone. Redesign can wait.

Second, price the exit. If the seller will not support change, if TSA fees step up after 12 months, or if the environment is shared across retained businesses, the exit path needs cash and named milestones before signing.

Third, test process fit. If the buyer’s SAP template can support the target with a small set of controlled exceptions, migration may be the best answer. If the target’s process differences protect margin, service levels, or regulatory compliance, forcing the template will burn value.

Fourth, decide whether S/4HANA is now or later. If ECC support, custom code, instance fragmentation, and reporting weakness force a program anyway, build the deal plan around S/4HANA. If the business first needs operational stability, use a two-step path: stabilize or clone, then redesign after the value plan has breathing room.

Fifth, assign owners outside IT. Finance owns close and reporting readiness. Operations owns inventory, warehouse, and manufacturing flows. Commercial owns pricing and billing continuity. Tax owns statutory and indirect tax setup. IT owns build, integration, security, environments, and cutover. The SAP decision fails when it is treated as an IT-only call.

What goes wrong after close

The most common failure is a quiet one: SAP keeps running, but every value initiative slows down.

The buyer cannot change vendor terms because supplier masters are mixed with seller data. The first close relies on seller BW reports that are not included after TSA exit. Inventory data does not reconcile between SAP and the warehouse system. A pricing routine blocks customer migration. The clone includes obsolete roles, so the audit team flags segregation-of-duties issues before the first quarter closes. S/4HANA design workshops consume the same finance and operations people needed for integration.

Each issue has a technical label. The consequence is economic: delayed EBITDA, higher TSA fees, working capital leakage, more one-time cash, and slower management control.

The root cause is usually a posture chosen too late. By the time the team accepts that SAP is shared, customized, under-documented, and tied to the seller’s operating model, the negotiating room has closed.

What best teams do

Strong teams turn SAP from a diligence finding into a deal decision.

They name the SAP posture before signing. The answer can be provisional, but it must be explicit: stay, clone, carve, migrate, or redesign. Each option gets cash, timing, owner, and risk gates.

They force a red team review of the preferred answer. If the plan is to stay on seller SAP, the red team tests seller incentives, TSA exclusions, change rights, data access, and exit timing. If the plan is to clone, it tests licensing, data removal, interfaces, hosting, roles, and audit findings. If the plan is to migrate, it tests template fit and buyer capacity. If the plan is S/4HANA redesign, it tests business change load and value timing.

They split the program into three clocks:

• Day-1 continuity: ship, invoice, pay, close, comply
• TSA exit: own the system, data, people, contracts, and support model
• value enablement: procurement, finance, inventory, reporting, and operating model changes

Those clocks may overlap, but they cannot be managed as one project plan. When they compete for the same SAP people and business owners, the deal needs a sequence.

They put commercial terms around SAP reality. TSA extension rights, seller staffing commitments, data extraction rights, project work rates, license transfer mechanics, cutover support, and fee escalators belong in the negotiation. A vague “reasonable assistance” clause is not enough for a shared SAP estate.

They set go/no-go gates that the steering committee can understand:

• first mock conversion reconciles inventory, AR, AP, and open orders within agreed tolerances
• order-to-cash test covers the top revenue flows and exception paths
• security roles pass SoD review before production access
• interface monitoring has named owners and daily exception reporting
• close runbook is tested before the first buyer-controlled close
• TSA exit date is not confirmed until data, reports, and support handover are proven

Monday morning

The deal lead should not ask the CIO for an SAP risk rating. Ask for a posture recommendation by Friday.

In the next one to two weeks, assign five owners.

The CFO should define the minimum SAP outputs needed for the first three closes: trial balance, management P&L, cash, AR, AP, inventory, backlog, and working capital reporting.

The COO or business unit leader should identify the workflows that cannot break: order entry, shipment, invoicing, purchasing, goods receipt, production, warehouse movements, and customer service.

The CIO should produce the SAP estate and dependency map, including modules, interfaces, add-ons, custom code, hosting, support partners, identity, and reporting.

The tax and legal teams should test entity setup, statutory reporting, indirect tax, license transfer rights, data retention, and TSA terms.

The integration lead should put the five postures on one page with cash, timing, dependencies, and gates: stay, clone, carve, migrate, redesign.

Then make the call. If SAP is clean and the seller has incentive to support the transition, stay on the seller’s system long enough to exit well. If TSA is short and the estate is shared, stop pretending the separation is simple. If the buyer’s template fits, migrate with discipline. If S/4HANA is unavoidable, fund it and protect the business from too much change at once.

The wrong SAP posture does not always break Day 1. It does something more expensive: it lets Day 1 work while the deal thesis waits.