SAP in mergers, acquisitions and divestitures: the complete guide to consolidation, carve-outs and proving it worked

Every deal model has a line for IT synergies and a line for integration cost. In an SAP shop, both lines run through the ERP. Consolidated books, shared procurement, one order-to-cash process, a clean exit from a transition services agreement: each one depends on moving company codes, plants, customers, suppliers and open items from one SAP configuration into another, or prying them apart, without losing a cent or a shipment. This guide covers the whole arc, from the scenario decision to the evidence a controller signs. It is written for the people who carry it out: SAP leads, finance transformation teams, test managers, IMO leads, and the CIOs who have to tell the board it worked.

One thread runs through all of it. In M&A, the data move is rarely what fails. What fails is proving that the moved data and the changed processes behave correctly at the new scale and in the new structure, before the business depends on them. That is why the testing, verification and validation section is the longest one here.

Disclosure: Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. ACCELQ appears in this guide as the worked example for automating the verification work in the testing sections. Every other part of the guide is tool-neutral, and the methods apply whatever automation you use. ACCELQ does not sponsor or review this site. Read the full disclosure.

Why SAP decides whether the deal pays

McKinsey found in 2011 that 50 to 60 percent of synergy initiatives in the deals it studied were strongly related to IT, and that successful IT integrations delivered 10 to 15 percent IT cost savings^[54]. The study is old, but the mechanism has not changed: shared services, consolidated procurement and a single close need a single system, or at least systems that agree. KPMG’s 2026 guidance on SAP integration in M&A makes the same point from the delivery side. It recommends consolidating ECC and S/4HANA landscapes in phases, starting with finance^[40].

On the sell side the dependency is sharper. Deloitte’s 2026 divestiture survey of about 1,500 executives found that sellers struggle most after close with stranded costs, TSAs and financial reporting, and that most businesses are far from fully separated at close^[44]. PwC’s analysis of carve-outs puts a number on speed: an 8 to 11 percent value uplift, of which roughly 5 to 7 percent comes from about a year of extra value capture by exiting the TSA early and 0.5 to 0.8 percent from avoided TSA markup^[43]. The SAP separation is usually the longest pole in that tent.

And when it goes wrong, it goes wrong in public. Asda’s chair called the problems in its separation from Walmart’s systems “totally self-inflicted”, naming insufficient testing among the causes^[65]. Neogen told the SEC that its new ERP and the exit of transition agreements with 3M led to shipment delays and an elevated order backlog^[62]. Both stories are in the case studies below, along with what to test so they don’t become yours.

Scenarios and target states

Start with the deal, not the software. Six scenarios cover almost everything I see, and each one points to a different family of SAP options.

Consultancies name the same choices in different words. An academic synthesis lists best-of-breed, absorption, co-existence and new-build^[79]. PwC uses transformational, absorption, tuck-in and standalone^[42]. Deloitte’s carve-out options are to separate the existing landscape and keep it, migrate onto the buyer’s systems, or implement a new cloud solution^[47]. KPMG adds the execution pattern: phased (lower risk), big bang (faster and riskier, suited to simpler landscapes), or hybrid^[40]. Whatever vocabulary your IMO uses, write the target state down in one sentence per legal entity and get the steering committee to sign it.

The decision tree

The factors that move the decision

Real programs show the range. Liberty Global’s Sunrise merged with UPC and moved six legacy systems to one S/4HANA, halving the landscape; the platform later supported Sunrise’s spin-off and listing in November 2024^[48]. Accelleron, spun out of ABB, ran S/4HANA Cloud Public Edition with SAP ERP in a two-tier model and finished separation in 22 months across 40 countries^[39]. Both are success stories told by their delivery partners or SAP, so read them as possibility, not as benchmarks.

The SAP toolbox in 2026

The tooling is where most published guidance is out of date or muddled. Here is the current picture, as of October 2026, with the distinctions that matter.

DMLT: the service for org-unit changes

SAP’s Data Management and Landscape Transformation (DMLT) group, the successor to the old SLO (System Landscape Optimization) offering, delivers org-unit transformations as SAP services built on SAP Landscape Transformation tooling. The SAP Support page for mergers, acquisitions, divestments and restructuring lists company code clone, deletion/carve-out, merge, split and transfer; controlling area merge and split; plant merge and reallocation; HCM restructuring; and BW services. It says the services cover ECC, S/4HANA and cloud solutions from design through cutover, and names Migration Cockpit, SAP Landscape Transformation and Test Data Migration Server as related products^[1]. SAP employees were still publishing DMLT company code merge guides in March 2026^[2].

The underlying solutions are documented in the SAP LT 2.0 Master Guide. It dates from 2018, so check each scope against the current SAP Notes, but it is still the clearest list of what each transformation does^[5]:

Two rules from SAP Help shape every merge plan. First, the company codes to be merged must be in the same client. Second, document flow is not affected and running processes continue, but you may need adjustments to controlling areas, G/L, customer and vendor customizing, charts of accounts and number ranges^[3]. So a merge of company codes that live in two systems is always two steps: get both into one client (client transfer, migration or SDT), then merge.

SAP’s 2026 DMLT company code merge guide lays out seven steps: pre-planning and analysis; clean-up (cut-off date, clear open items, reconcile intercompany, archive); configure the target company code; data transformation “validated against the source totals”; testing and validation (reconciliation, functional, SIT, UAT, performance, compliance and audit); cutover; and hypercare with decommissioning of the old company codes^[2]. Step five is one paragraph in that guide. It is a third of this one.

SAP Business Transformation Center: Lean SDT in Cloud ALM

SAP Business Transformation Center (BTC) is a different product. It runs on SAP Cloud ALM and frames SAP’s standard transformation solutions: analysis (Digital Blueprint, Find Transformation Approach) and execution (Migration Cockpit, Lean Selective Data Transition, SUM, the RISE system transition workbench, Data Transition Validation). SAP lists it as included in the SAP support offering^[6]. The Find Transformation Approach app combines SAP Readiness Check data, data profiling and a questionnaire to recommend new implementation, selective data transition or system conversion with a percentage fit. For a public cloud target, the only option it offers is new implementation^[8].

Lean SDT in BTC lets you leave outdated company code or fiscal year data behind with time-slice filtering. Since April 2025 it is wired into Cloud ALM project and task management, and transformation projects can currently only be created for selective data transition from ECC to S/4HANA^[7]. A community comment says S/4HANA to S/4HANA is on the 2026 roadmap^[10]; I found no SAP release note confirming it as of this writing, so don’t plan an S/4-to-S/4 carve-out on BTC without checking.

Why testers should care about BTC. It formalizes three cycle types. A test cycle lets errors be bypassed for iterative tuning. A dress-rehearsal cycle is meant to practice the productive cutover with parameters close or equal to it, and errors block all further steps. Then the go-live cycle. Each runs through prevalidation, preparation, transformation and post-processing, with at most three active cycles and logs in the Cycle Logs app^[9]. That is a mock-cycle discipline built into the tool, and you should mirror it even when you use something else.

Selective Data Transition engagements

SAP defines SDT as a migration into S/4HANA with selective scope and individual transformations. Its scenarios include staged cutover by company code, wave rollouts by system, client or company code, merging or splitting systems, harmonizing master data, transaction data or the chart of accounts, and M&A carve-outs from S/4HANA to S/4HANA. Targets are RISE private cloud and on-premise; public cloud is not supported. SAP runs SDT with an expert group of partners founded in 2020^[11]. The two technical patterns are shell conversion (a copy of production stripped of master and transaction data, then converted) and mix-and-match (a fresh install that receives selected configuration and code)^[13],[12]. In a multi-ERP merger, a common pattern is to pick the leading ERP, shell-convert it, then migrate the others after harmonization^[14]. One partner markets carve-out, conversion and cloud move as a single project with one set of testing and one go-live^[74]; that is a partner claim, but the logic is sound if the test plan is built for it.

Central Finance: Day 1 finance without touching operations

Central Finance replicates financial postings from SAP and non-SAP sources into an S/4HANA instance through SAP Landscape Transformation Replication Server. Because it is finance-only, operational integration decisions can wait, and account, customer and profit center mapping happens during replication, so harmonization can mature over time. Parties can exchange data structures (not values) before close, so the mapping design can start early^[21]. Central Finance also brings reconciliation with it: comparison reports at three levels (document counts, G/L and cost element balances, line items), one source system per report^[22]. Load in order: master data, cost objects, WBS elements, FI/CO postings, then CO secondary postings^[23].

Migration Cockpit: new company codes from files or direct transfer

The Migrate Your Data app (F3473) replaced the LTMC Web Dynpro transaction^[17]. It offers files, staging tables, and direct transfer over RFC from SAP ERP; direct transfer selects by company code and needs DMIS 2011 SP19 or later on the source^[15],[16]. Community posts say direct transfer does not support S/4HANA sources^[18], so S/4-to-S/4 carve-ins lean on staging tables, files, SDT or DMLT. I found no SAP Help statement that explicitly endorses loading an acquired company as a new company code into a live productive S/4HANA. It is a common rollout pattern, and SAP lists the Migration Cockpit as a related product for DMLT M&A work^[1]. Validate object coverage for your release, and load into a production-like copy first.

Group Reporting and greenfield

SAP S/4HANA Finance for group reporting supports consolidation of investments for first consolidation, step acquisition, partial and total transfer, partial and total divestiture, and horizontal merger^[19]. Decide early how acquisitions enter consolidation (journal entry or flat-file upload) and how divestitures run through consolidation of investments^[20]. For a standalone target, flexible upload of its trial balance from Day 1 is the minimum viable consolidated view, with no change to the target’s systems.

Greenfield is the other end. A carve-out lets NewCo start with a clean core without extensive customizations^[41], and SAP’s two-tier ERP material names acquisitions and divestitures as drivers^[38]. In PwC’s carve-out analysis, a fit-for-purpose IT system using pre-packaged accelerators such as ERP solutions added 1.5 to 2 percent in value capture^[43]. The price is a full process build and a full test cycle.

The ECC 2027/2030 deadline factor

If either party runs SAP ECC, the maintenance calendar is part of the deal. Mainstream maintenance for SAP Business Suite 7 ends at the end of 2027; optional extended maintenance runs to the end of 2030 for a premium of two percentage points; S/4HANA is committed to 2040^[27]. Separately, the SAP ERP, private edition, transition option was announced in 2025 to cover 2031 to 2033 for customers who move to SAP ERP, private edition by the end of 2030; as first announced it could not be bought before 2028, and it is not a maintenance extension^[28]. An October 2026 update lets those subscriptions run to the end of 2035, with further prerequisites in SAP Note 3591251, while the move must still happen before the end of 2030^[29]. Our guide to the ECC maintenance dates covers the details.

Every extra hop adds a full regression and reconciliation cycle. Option C concentrates the risk into fewer, larger rehearsals. If you go that way, invest in automation before Mock 1, because each rehearsal will need the same suite run end to end.

Worked example: 2000/2100 into 1710

To keep the rest of the guide concrete, here is one illustrative deal used throughout. The names, numbers and dates are invented for teaching; the SAP objects and constraints are real.

Deal thesis: procurement and shared-service synergies, so the target state is absorption. The target’s legal entities survive at first; the US entity behind 2000 will legally merge into the buyer’s US entity about a year after close. Entity 2100 stays a separate Canadian subsidiary.

The plan the IMO signs:

1. Day 1: the target stays on ECC. Group Reporting receives 2000 and 2100 trial balances by flexible upload, mapped from TGCA to the group chart of accounts. Treasury, payroll and order-to-cash run as before. Access is segregated and the buyer’s finance team gets read access to target reporting on Day 1, not before.
2. Days 1–90: capture the target’s end-to-end regression baseline on ECC; finalize org and master data mappings with real values (now legal after close); decide the move route. Here: Migration Cockpit direct transfer by company code from ECC (DMIS level confirmed on the source), with SAP and the SI comparing it against a DMLT company code transfer or Lean SDT. 2000 and 2100 arrive as new company codes in client 100, assigned to controlling area A000.
3. Months 3–8: three mock loads into a fresh copy of buyer production, then a dress rehearsal. Reconciliation, regression, interface, SoD and performance tests after every one.
4. Month 9: cutover at a period boundary (open items as of the period-end close, never mid-month), then hypercare through the first quarter-end close.
5. Month 13 onward: after the legal merger, a DMLT company code merge folds 2000 into 1710. It is possible only now, because both company codes are finally in the same client^[3]. Then the target ECC goes read-only, retained data moves to an archive, and the system is decommissioned.

Sign to close: clean teams and gun-jumping

The period between signing and closing is where IT teams most often get ahead of the law. The FTC’s guidance is plain: the risks of sharing information with a competitor last until the merger closes. Current and future prices, strategic plans and costs are sensitive. Information you share should be narrowly tailored and reasonably related to diligence or integration planning. Clean teams should not include people responsible for competitive planning, pricing or strategy, and customer identities should be aggregated or masked^[58].

Enforcement is real. In January 2025, XCL Resources, Verdun Oil and EP Energy paid a record $5.6 million civil penalty for gun-jumping; the conduct ran for 94 days in 2021 and included control over the target’s ordinary-course operations and expense approvals. The settlement also requires clean team agreements in future competing-product deals^[59]. The final judgment set the penalty at $5,684,377^[60]. EY describes clean rooms where outside advisors access both parties’ sensitive data between signing and closing, including for systems integration and access-control benchmarking, with an audit trail of who saw what^[51].

Here is how that translates for an SAP team. Take it to your deal counsel and get their sign-off; it is a starting point, not legal advice.

What this means for testing. No production copies of the target in the buyer’s test systems before close, unless anonymized and cleared by counsel. Before close, the test team can build everything that depends only on structure: the test strategy, the reconciliation rule set (with the layers and tolerances, not the values), the data-driven test design keyed by the target’s company codes and plants, and the buyer’s own regression baseline. The target’s baseline and anything that needs its data waits for Day 1. Track what you ask for in the IT due diligence checklist, and log every dataset you receive, who saw it and its counsel clearance in a clean team data-sharing register.

Org structure and master data

Harmonization is where the deal thesis meets the data model. Every object below needs a mapping decision, an owner, a key date and a validation rule. The org structure harmonization map and chart of accounts mapping workbook give you the columns.

Chart of accounts: n:1 or nothing

The SAP LT chart of accounts conversion supports 1:1 and n:1 mappings with mapping checks, and splitting an account is not possible^[5]. The same discipline helps whatever tool you use: every source account maps to exactly one target account. If a source account mixes two meanings (a single “other receivables” account holding employee advances and supplier credits, say), fix it in the source before migration by reclassifying, not by hoping the mapping can split it. In the worked example, about 1,400 TGCA accounts collapse onto a much smaller set of YCOA accounts. Each mapping row carries the reconciliation check that proves it: the sum of mapped source balances equals the target balance by company code, period and currency type.

Business partners: dedupe without merging separate legal entities

Overlapping customers and suppliers are the most underestimated workstream. MDG consolidation matches records using SAP HANA fuzzy search or smart data quality and builds a best record from survivors’ fields^[30]. Watch for false positives: records with many matching attributes can still be separate legal entities, so tune match rules and review clusters by hand^[31]. A parent company and its subsidiary often share a name, address and phone number but not a tax ID or bank account; merging them breaks credit management, tax reporting and dunning. Log every match group, decision and new ID in a master data harmonization workbook, and record which mock cycle tested it.

Common customers and suppliers also change their role. A customer of the target that is a subsidiary of the buyer becomes an intercompany partner; resolve that before migration, not after the first elimination fails^[2].

Running the program: IMO, RACI, timeline

EY describes three tiers: an executive steering committee, an integration management office, and functional workstreams. The IMO owns the roadmap, upholds guiding principles, resolves cross-functional issues and challenges workstream charters against Day 1 requirements, on a weekly cadence, with Day 1 readiness sessions and simulations before close^[49]. McKinsey argues the IMO should report directly to a CEO-led steering committee and be staffed with top performers; a traditional PMO is poorly suited to breakthrough value^[55]. In carve-outs, EY suggests appointing an executive who stays with the seller to lead the PMO, and warns that allegiances shift^[50].

The SAP workstream sits inside that structure, but its test and cutover work cuts across finance, supply chain, HR, security and every interface owner. That is why the RACI matters more than usual.

PwC warns that buyers involve too many vendors during sign-to-close, which cascades into one-time cost overruns^[43]. Keep the SI count small and make one party accountable for the reconciliation evidence. Track it all in an IMO program tracker and synergy register, and keep the IT side honest with an IT synergy and dual-running cost tracker: two ERP licenses or subscriptions, TSA fees and markup, parallel hosting, duplicate support, interface bridges and archiving all run until the decommission date. Neogen, for example, reported ERP expense as a separate adjusted EBITDA add-back in fiscal 2024^[62].

The program timeline

Day 1, Day 100 and end state

KPMG’s advice is to plan backwards from Day 1, because the transaction side usually sets the date^[41]. EY’s carve-out roadmap focuses Day 1 on must-haves such as order-to-cash, notes that ERP often requires logical and physical separation of commingled data and systems, and frames reporting as Day 1, Month 1 and Quarter 1. IT has to operationalize new legal entities, segregate access, handle name changes and enable separate financial reporting, and the seller should settle intercompany balances^[50]. Watch system blackout periods during cutover.

The Day 1 / Day 100 / end-state readiness checklist turns this into owners, dependencies, TSA references, test evidence and go/no-go criteria.

TSAs, reverse TSAs and the exit

A transition services agreement (TSA) is the seller running services for the buyer after close, usually including SAP: the divested company codes keep transacting in the seller’s system while the buyer builds its own. A reverse TSA runs the other way, with the buyer providing services back to the seller, for example when shared master data or a shared plant ends up on the buyer’s side. I found no Big 4 source that defines reverse TSAs in detail, so treat the term as practitioner shorthand and write the scope out in full.

Durations are longer than people plan for. Deloitte Switzerland assumes IT TSAs of 8 to 12 months or longer^[45]. PwC puts a typical TSA exit at 12 to 24 months, with 6 to 12 achievable, and counts more than 1,500 design decisions in a typical exit^[43]. Accelleron had 24 months^[39]; Asda’s initial arrangement with Walmart was three years^[65].

EY says to finalize TSA schedules that document how services are delivered, disputed and exited, and notes that TSA scope can restrict the seller’s stranded-cost mitigation^[50]. EY-Parthenon adds that legal, tax and audit are typically not offered under TSAs^[52]. Deloitte US recommends SLAs and KPIs, an escalation path, a steering committee, a modest single-digit markup and a clear exit strategy, and mentions one-time TSAs such as data migration for the exit^[46]. Deloitte Switzerland lists the constraints sellers feel: governance effort, binding commitments, disproportionate operating costs and limited control over systems and data^[45].

The TSA tracker for SAP services has these columns and an exit plan tab.

Carve-outs and divestitures

A carve-out is the M&A scenario that most needs precision, because the failure mode isn’t only missing data. It is also data that leaves when it shouldn’t. Co-mingled data is one of the hardest parts of a divestiture^[73]. In one partner-reported carve-out, about 23 percent of the data changed owners^[71].

KPMG’s carve-out advice is to separate “surgically”: carry only what NewCo needs, protect IP, meet GDPR, agree on historical data, apply the same selection to satellite systems, and use tooling with preconfigured reconciliations. Its testing principle is that what you do today, you will be doing tomorrow, proven with positive and negative tests^[41]. A practitioner with experience of many SAP divestitures recommends not deleting divested data from the seller’s production system (archive instead), having both buyer and seller run positive and negative tests, identifying master data shared with non-carve-out units early, and scheduling cutover on a weekend away from month-end^[76].

Remove, scramble or keep

Access cutoff

EY lists segregating access to systems and data as a Day 1 IT requirement^[50]. In SAP terms that is more than locking users. The separation plan should cover users by legal entity (SU01, SU10, SUIM), role changes in PFCG, firefighter IDs, shared service and batch users, RFC destinations and trusted systems (SM59), SSO and identity provider federation, VPN and network paths, and email domains, with dated evidence of each cutoff and an access review after it. The carve-out data separation and access cutoff plan is built around that list.

Licensing and contracts

• Affiliates. Licensing consultancies note that SAP licenses typically cover the licensee and its affiliates, often defined by more than 50 percent control. After close, a divested unit is no longer an affiliate, so its use of the seller’s SAP under a TSA may need SAP’s consent or a transitional-use clause^[77],[78]. Some of these consultancies publish fee estimates for such consent; they are single-source, unverified estimates, and I don’t repeat them here.
• Temporary licenses. EY recommends identifying technology suppliers early, because they may insist on the purchase of temporary licenses to support the TSA period^[53].
• Digital access. SAP’s Digital Access model licenses indirect use by documents created, across nine document types, while human users stay under named-user licensing. SAP offers a free Digital Access evaluation service^[36]. New interfaces from an acquired company’s non-SAP systems that create documents in the buyer’s SAP may fall under it. Evaluate before you wire them up.
• RISE and GROW. Check the order form for affiliate definitions, divestiture and change-of-control terms, scale-down rights and term before signing the deal, not after.

The license and contract entitlement checklist lists these questions per contract, with owner and legal reference columns.

What goes wrong: public cases

Public, well-documented M&A system failures are rare, because most never reach a regulator or a filing. The ones that do share the same patterns.

The failure modes repeat: insufficient end-to-end and integration testing; capacity not tested at merged volume; a TSA exit and an ERP cutover in the same window; co-mingled data leaking; weak governance of outsourced delivery; go-live decisions under external pressure; and internal-control weaknesses after an ERP change^[64]. Every one of them is a testing problem before it is anything else, which brings us to the core of this guide.

Testing, verification and validation

Most M&A testing plans I review are a migration test plan with a few reconciliation reports attached. That misses what is different about consolidation. In an implementation, you test a new design. In a consolidation, you test that an existing business still works after its data, its org structure, its interfaces and its users have all moved at once, and that the business it moved into still works too. And in a carve-out, you also have to prove a negative: that nothing left that shouldn’t have.

Three words carry the whole section, so here is how I use them:

• Reconciliation proves the numbers moved: counts, balances and open items agree between source and target, with every difference explained.
• Verification proves the system was built as designed: mappings applied, org assignments correct, roles and interfaces configured.
• Validation proves the business works: the same end-to-end processes produce the same correct results for the same inputs, in the new structure, at real volume, for the real users.

SAP’s DMLT company code merge guide lists reconciliation, functional, SIT, UAT, performance, and compliance and audit testing as one step^[2]. Here is that step unpacked into what a program actually needs.

Step zero: capture the baseline before anything moves

You can’t prove that a process still works unless you recorded how it worked before. Before the first mock load, run the end-to-end scenarios for every org unit in scope, in the source system, and keep the outputs: document numbers and types, account determination, tax codes and amounts, pricing results, output and form content, and the resulting balances. In the worked example, that means sales, procurement, inventory, asset and period-end scenarios for company codes 2000 and 2100 and plants 2000, 2010 and 2100 on ECC, plus the same set for 1710 on S/4HANA, because the buyer’s own processes must not regress when new company codes arrive in its client.

Mind the gun-jumping line. The buyer can baseline its own system any time. The target’s baseline is captured after close, or by the target in its own systems under counsel-approved arrangements.

The reconciliation layers

The layers come from combining SAP’s LTVF validation categories^[24], the DMLT merge method^[2], and the carve-out negative-testing advice from KPMG and practitioners^[41],[76]. The consolidation data reconciliation workbook has one tab per layer, with columns for each mock cycle. Layer 7 has its own intercompany and elimination test matrix: one row per entity pair and intercompany process, with the expected post-merge treatment and the residual after elimination.

SAP’s validation tools, and what each one covers

Before an ECC-to-S/4HANA conversion, SAP also provides finance consistency checks to run on the source (FIN_CORR_RECONCILE and related reports); check the current SAP Notes for your release. Clean source data is cheaper than explained differences.

A worked reconciliation, company code 2000

Illustrative figures from Mock 2 of the worked example. The point is the shape of the evidence, not the numbers.

Three habits make this work. Set tolerances before Mock 1, with the controller, per check (zero for balances, a count rule for timing differences). Keep an accepted-difference log with the approver’s name and date. And run the same checks, from the same rule set, in every cycle, which is exactly what LTVF is built for^[24]. Our data migration reconciliation checklist covers the generic object list.

Regression across merged org units

When new company codes and plants arrive in a live client, the configuration that drives every transaction gains new branches: account determination (OBYC by valuation area and valuation class), pricing and tax determination, output determination with new legal names, credit control areas, dunning and payment program settings (FBZP), intercompany stock transfers and billing, cross-company-code postings, and period-end jobs scoped by company code. The buyer’s existing processes run through the same tables. That is why consolidation regression must cover both the moved org units and the existing ones.

The efficient pattern is one automated end-to-end scenario per process, parameterized by org unit, run against the baseline and again after every mock. A sales scenario (create order, deliver, post goods issue, bill, post to accounting) becomes one test with a row per company code, sales area and plant combination. Compare the outputs to the baseline: document posted, accounts hit, tax amount, segment, output content.

Scale the same idea across procure-to-pay (including the 410 shared suppliers and the payment run), record-to-report (accruals, foreign currency valuation, depreciation, assessments, settlement, close), plan-to-produce for the new plants, and payroll. Keep the scope in a consolidation test and validation strategy, and prioritize the way our regression automation guide describes: high-volume, high-value, high-change processes first. SAPinsider’s SAP HR M&A series makes the same point for repeat acquirers: reuse configuration and test assets from the first deal^[57].

Positive and negative carve-out tests

Negative tests are queries with an expected result of zero. Run them per out-of-scope org key, on every table that carries one, including the ones nobody remembers:

Natuvion’s write-up of the Construction Forms carve-out describes exactly this goal: an SAP landscape containing only carved-out data, checking that nothing from other company codes leaked in^[70].

Security, roles and SoD

Role harmonization changes who can do what in which company code, often for thousands of users at once. SAP Access Control defines an access risk as one or more actions or permissions that, when available to a single user, create the potential for fraud or unintentional errors. It distinguishes segregation-of-duties, critical action and critical permission risks, and analyzes them in real time or in batch^[34]. When you change the rule set (for new company codes or org-level values), regenerate it before analysis^[35].

Use the security role and SoD harmonization matrix for the mapping and the security, role and SoD test plan for the test design.

Interfaces after rewiring

Every interface touching a moved org unit changes something: a logical system, an RFC destination, an EDI partner ID, a bank file format with a new legal name, a tax engine company mapping. In the Techwave divestiture SAPinsider described, EDI cutover to OEMs and tier suppliers was the milestone that meant the business was live^[56].

The interface rewiring tracker and the existing interface inventory and test tracker hold the inventory.

Performance at merged volume

Asda’s chair named a lack of capacity planning alongside insufficient testing^[65]. Consolidation changes volumes in ways a functional test never shows: a payment run (F110) with the combined supplier base, MRP across new plants, billing runs (VF04) for merged sales orgs, period-end jobs for more company codes, and a Universal Journal that grew overnight. Test with production-like volumes in Mock 3 and the dress rehearsal: run the month-end batch chain in its real window (SM37 runtimes against the window), measure dialog response for the busiest transactions (ST03N), and model database growth. The SAP performance test plan lists the scenarios.

Mock cycles and the dress rehearsal

BTC formalizes the progression: test cycles where errors can be bypassed, a dress rehearsal with production parameters where errors block, then go-live^[9]. LTVF is designed to reuse the same validations across mock migrations, dress rehearsals and production cutover^[24]. The partner-reported AMAG carve-in used three migration test cycles plus one dress rehearsal in eight months^[69]. Use those as the skeleton.

Track runtimes, errors, validation run IDs, reconciliation pass rates and the go/no-go for the next cycle in the system consolidation cutover plan and mock tracker, alongside the generic mock cutover rehearsal tracker and cutover plan and runbook.

The sign-off evidence pack

At the go/no-go, nobody should have to take anyone’s word for anything. The evidence pack is the set of artifacts that lets a controller, an auditor or a regulator see that the migration was controlled and tested, the standard TSB was held to^[61].

Hypercare

EY frames post-close reporting as Day 1, Month 1 and Quarter 1^[50]. Neogen’s and Asda’s problems surfaced in fulfillment weeks after cutover^[62],[67]. Keep hypercare open through at least the first period-end and the first quarter-end close in the new structure. During it, run daily reconciliation spot checks on the moved company codes, re-run the regression pack after every emergency transport, and watch interface queues and batch runtimes. Exit on criteria, not on the calendar: use the hypercare plan and exit criteria and the hypercare defect triage log.

What you can automate

Automating the verification layer

Each mock cycle needs the same regression, interface and spot-check work done again, against a fresh system, under a deadline. Four mocks and a production cutover means five full runs before hypercare even starts. That repetition is why the verification layer is the best automation investment in an M&A program, and why manual-only test plans tend to shrink their scope by Mock 3 just when the risk is highest.

ACCELQ is the worked example here. Matt Angerer, who runs The Sign-Off Table, works at ACCELQ; see the disclosure. The capabilities below come from ACCELQ’s documentation and SAP’s partner directory; the pattern works with any tool that has the same features.

Seven consolidation testing pain points: what they cost and how ACCELQ addresses them

The costs below follow from the method in this guide and the public cases above; none is a benchmark. The last column lists only what ACCELQ documents today.

How it runs in each mock cycle

The master checklist

One page per phase. Each item maps to a template in the next section.

Templates and courses

Every template below is free to download from the template library, with worked examples that use the same 1710 and 2000/2100 company codes as this guide.

Academy courses that go deeper: data migration from Data Migration Fundamentals for SAP S/4HANA through Migration Cockpit direct transfer, data quality, cleansing and mapping rules, data reconciliation and validation sign-off, selective data transition concepts, mock load strategy and migration runbooks and migration governance, data privacy and data volume decisions; finance with S/4HANA Group Reporting and Central Finance: replicating and reconciling; and the transformation track from transition paths and the 2027–2030 deadline map to business partner and CVI preparation, finance conversion essentials and conversion cutover and downtime planning.

Related guides: the ECC to S/4HANA migration testing plan, S/4HANA test data management, what to automate first, the ECC maintenance dates and who owns testing under RISE.

Frequently asked questions

What is an SAP carve-out?

Separating a business unit’s data, processes and users from the seller’s SAP so the unit can run on its own system or the buyer’s. The main approaches are clone-and-delete, an empty shell with selective migration, selective migration into the buyer’s SAP (carve-in), and a greenfield NewCo^[73],[41]. See carve-outs.

What should an SAP carve-out project plan include?

Working backwards from the Day 1 date: data scoping by org key, a disposition (transfer, delete, anonymize, retain) per table, the separation approach, TSA schedules and an exit plan, access cutoff, interface changes, at least three mock cycles plus a dress rehearsal^[69], positive and negative tests by both parties, and hypercare through the first quarter-end close.

What tools does SAP provide for carve-outs and mergers?

DMLT services on SAP Landscape Transformation for org-unit merges, splits, transfers and deletions; SDT engagements; BTC with Lean Selective Data Transition for ECC to S/4HANA; the Migration Cockpit; Central Finance; and Group Reporting, plus LTVF and DTV for validation^{[1],[6],[11],[24]}. See the tooling map.

What does DMLT stand for, and is it the same as SLO?

Data Management and Landscape Transformation. It is SAP’s services group and offering for landscape transformations, the successor to SLO (System Landscape Optimization), and it delivers company code, controlling area and plant transformations for M&A^[1],[5].

Did DMLT move into SAP Business Transformation Center?

Not according to SAP’s pages as of October 2026. DMLT still offers its M&A services, and BTC’s execution scenario is Lean Selective Data Transition from ECC to S/4HANA^[1],[7].

How do you merge two company codes in SAP?

Put them in the same client first, because SAP requires it^[3]. Then plan with SAP or a partner through the DMLT method: clean up and settle intercompany, configure the target, transform and validate against source totals, test, cut over and decommission^[2]. Only merge company codes when the legal entities merge.

What is selective data transition, and what is mix-and-match?

SDT moves selected scope into S/4HANA with individual transformations. Shell conversion converts a stripped copy of production; mix-and-match starts from a fresh install and brings in selected configuration and code^[11],[13].

How does Group Reporting handle acquisitions and divestitures?

Through consolidation of investments: first consolidation, step acquisition, partial and total transfer, partial and total divestiture, and horizontal merger^[19]. A standalone target can submit data by flexible upload from Day 1.

What is a TSA in SAP M&A?

A transition services agreement under which the seller keeps running SAP services for the divested business after close. IT TSAs often last 8 to 12 months or longer^[45], and exits typically take 12 to 24 months^[43]. Plan the exit as a cutover. See TSAs.

What is the best tool for SAP data reconciliation?

It depends on the route: LTVF for DMLT, SDT and M&A programs; DTV for conversions; the comparison reports for Central Finance^{[24],[25],[22]}. None of them covers end-to-end process validation, which you still need to test.

What is a Central Finance reconciliation report?

One of the CFIN comparison reports that compare a source system with Central Finance by document counts, by G/L and cost element balances, and by line items, one source system at a time^[22].

How do you reconcile intercompany balances before a merge?

Settle them before transfer to avoid double counting^[2], confirm trading partners on both sides, and test that eliminations in Group Reporting leave zero residuals. The intercompany and elimination test matrix lays out the cases.

Is there an SAP cutover plan template in Excel?

Yes: the free system consolidation cutover plan and mock tracker and the general cutover plan and runbook.

Is there an M&A Day 1 readiness checklist template?

Yes: the Day 1 / Day 100 / end-state readiness checklist, built on EY’s Day 1 must-haves and Day 1, Month 1, Quarter 1 reporting^[50].

How do you merge duplicate business partners after an acquisition?

Match, then decide. MDG consolidation standardizes, matches, builds a best record, validates and replicates^[30]. Review match groups for false positives, because related legal entities can look like duplicates^[31].

How does SAP company code deletion work in a carve-out?

SAP LT company code deletion removes data directly or indirectly assigned to a company code while keeping shared data and leaving the system intact (Note 1462004)^[5]. It is offered as the DMLT company code deletion / carve-out service^[1]. Prove it with negative tests, and don’t delete in the seller’s production system when archiving will do^[76].

What is a mock conversion or mock migration?

A full rehearsal of the data move into a copy of the target system, followed by reconciliation and testing. BTC calls these test cycles and dress-rehearsal cycles^[9]. Plan at least three plus a dress rehearsal.

Can the buyer and target share SAP data before the deal closes?

Only what is narrowly tailored to diligence or integration planning; sensitive data goes through a clean team^[58]. Structures and field mappings are generally fine with counsel approval; operational control and production access are not^[59].

Summary and next steps

The deal team will measure the program by synergies and dates. The business will measure it by whether invoices go out, suppliers get paid and the books close. The evidence pack is what connects the two. The short version of this guide:

1. Pick the target state from the deal thesis and the SAP route that delivers it, then price the testing bill each extra hop adds.
2. Stay on the right side of the clean team rules: structures before close, values after, and no target production data in buyer test systems.
3. Capture an end-to-end baseline before anything moves, for the buyer’s org units and the target’s.
4. Reconcile in layers, test positively and negatively, and re-run the same rule set and regression pack after every mock cycle.
5. Treat the TSA exit as a go-live and keep hypercare open through the first quarter-end close.

Two ways to move faster from here:

Subscribe to the newsletterfor updates as SAP’s M&A tooling changes.