Merger, Acquisitions and Disentanglements simplified - Part II

Our first blog on Merger, Acquisitions and Disentanglements described the playing field on this matter. This second blog dives deeper into the specifics around Carve outs and disentanglements.

When the announcement to carve out (a certain part of) a business is made, usually a hectic and stressful time period starts for all functions involved. Certainly when a company is listed at a stock exchange and a fixed date is set when the carve out needs to be finalized. Next to the workload which lies ahead, also the prospect of all changes that are coming (and potential job losses) have an impact on the  mind set of all people involved.

One of the key decisions to be made from IT perspective is how this carve out is handled. There are several options:

• Buyer will move all existing activities in their own IT environment at the agreed date.

• Buyer will take all activities in their own IT environment at a later agreed date. To overcome the time gap a TSLA is made to support the business activities in the existing landscape (with existing support structures)

  • Separate system within existing landscape (supported by services like SLO/EPIUSE)

  • New organizational entities in existing IT landscape (SLO or separate project)

  • Existing organizational entities are re-used where possible, new organizational entities are created where legal regulations require this..

Day 1: Realize new legal structure within existing IT landscape and support structures (of the seller)

Day 2: New legal structure within new IT landscape (or move IT landscape to buyer) with new support structure and contracts. This is realized in a follow on project from buyer side.

Realizing a disentanglement within your current IT landscape can follow different scenarios:

• If the buyer will take over the business into their own IT landscape at day 1, from the selling side only support is needed w.r.t. data identification, extraction and closing in your current IT landscape. All activities regarding data cleansing and loading in the new landscape will be done by the project team of the buyer (unless otherwise agreed).

• If the decision is made to leave the business initially in the seller’s landscape, the options mentioned above will come into play. The decision to go for either option must be based upon an assessment of risks and benefits of each option:

  • Separate system within existing landscape (SLO/EPIUSE)

Via tooling from SAP or EPIUSE it’s possible to make a (partial) copy of a productive system as a new client on the existing landscape and clean out the migrated data from the old client. Advantage of this approach is of course the clean ‘cut-off’ of the new entities, with clearly separated clients, authorizations and transport landscape. Disadvantage is the incurred cost for such services and necessity to maintain these extra clients also as part of your archiving  obligation.

• New organizational entities in existing IT landscape (same client)

Another option is to create copies of each entity which is part of the disentanglement effort and migrate all master and transaction data from the old entities to the new entities for the business which is impacted. This migration can be done via a classical migration or the use of tooling as described in the previous point. Advantage here is the simplified landscape (no extra client which will exist for a significant number of years and the option to do this with an own team (cost benefit). Disadvantage is that extra effort is needed to split/hide data from integrity and security perspective.

• Existing organizational entities are re-used where possible, new organizational entities are created where legal regulations require this, all within the existing IT landscape.

In this scenario we will do the ‘re-use’ way of working, that is continue with the current entities in your IT landscape and change their legal entity name on date of day 1. Then in principle no or limited migration activity is necessary. This is a simple approach with benefits for business (continue as is) and IT (low effort).

Which is the best options for a carve out/merger will differ per project, dependent on the underlying characteristics of the business:

• Are the company codes dedicated per business or shared among them, shared will always mean creating a new company code or moving business to another country

• Are there more company codes in a country that share a legal entity, such cases make re-use scenario’s easier to implement since there is already a carrier for any activities post day 1 for the old legal entity (mandatory in some countries)

The combination of these two points can lead to several different scenarios for implementation of the carve out.

Of course there are a number of points to be checked in a re-use scenario:

• Reprinting of old documents should contain the old legal names, this must be checked from the start, if this is NOT yet arranged you have time until the go-live to arrange this. New documents (from day 1 onwards) should of course reflect the new legal entity.

• The closing balance of the old legal entity must be available as well as the opening balance of the new legal entity. This can be arranged via postings with special (one-time use) document types. Note that these are ‘only’ fiscal postings, so can be done in your fiscal ledger and should not touch your managerial ledger.

• If only a part of a company code is to be separated, this might lead to a new company code, but it can also be added to an organization in your landscape already representing that new legal entity.

• If the new business will stop in certain countries a migration scenario for the business closure should be considered (where do open customer orders and invoices move to?).

• If this is your only entity in a country, how to deal with returns / warranty after day 1, which legal entity will issue such credit / debit notes. Rules might differ per country.

• At one of our global clients we implemented such a scenario for many countries (including India/Brazil and Mexico), leading to significant cost savings and throughput time reduction. For some countries we implemented an extra company code to reflect the old legal entity for returns (simple setup).

• In some countries due to the length of legal proceedings, you cannot always go-live at the required date. Take such cases into account when creating your correction transports (split per company code), it is more work at the start but gives you also more flexibility.

• During the project normal business changes will continue, arrange special review of all changes being created AFTER you have started your project actions, since new transports might overtake your transports and lead to inconsistencies.

• In some countries due to legal reasons extra migrations might apply (like full asset migration) or transfer of existing contractual obligations is not allowed to a new legal entity.

• From Security & Authorization perspective it must be ensured during the project that during a day 1 scenario the respective businesses are not able to see data from the other entities (authorization on standard objects itself will likely not be sufficient to realize that).