Blog · Carve-Out Advisory

Get the master data wrong and everything downstream breaks.

TSA master data management split decides which customer, supplier, material, and product records follow the carved-out entity, then cleans and governs them on a standalone basis before Day One. Master data sits underneath every operational system, so the split sets whether new systems start clean or start broken. This is foundational separation work, which places it inside carve-out advisory. Get it wrong and the failures appear everywhere at once.

Select
The entity's records only
Govern
So it stays clean
7 min
Read Time
2026
Last Updated
Section 01

The data under everything else.

Master data is the reference data that every operational system shares: the customer records, the supplier records, the material and product master, the chart of accounts, the cost centres. It is not the transactions themselves but the foundations the transactions point at. An invoice references a customer record, a purchase order references a supplier and a material, a stock movement references a product. When the master data is clean and consistent, the systems above it work; when it is not, every one of those systems carries the same flaw.

In a carve-out this makes the master data split unusually consequential. The entity's new ERP, its warehouse system, its billing platform, and its reporting all sit on top of the same master data, so the quality of that data is inherited by everything at once. A duplicated customer, a supplier with a wrong bank detail, or an inconsistent material code does not stay contained in one place; it propagates into invoicing, payments, inventory, and the numbers, all from a single underlying record.

So the buyer treats master data as the foundation it is, not as a technical dataset to be copied. The split decides which records are genuinely the entity's, the cleanse decides whether they are fit to build on, and the governance decides whether they stay that way. Getting all three right is what lets the standalone systems start from solid ground rather than inheriting years of accumulated group data debt.

Section 02

Deciding what is actually yours.

The first and hardest question is which records belong to the entity. A group master file holds records for the whole organisation, and only a subset relates to the carved-out business. Some customers and suppliers are exclusively the entity's, some are exclusively other units', and many are shared, dealt with by both the entity and the rest of the group. A blind copy of the whole file brings across records the entity has no right to and no use for, while a copy that is too narrow leaves out records it genuinely needs.

Shared records need the most care. A customer that buys from both the entity and the seller has one record in the group system, and on separation each side needs its own version with its own relationship, its own terms, and its own history. The buyer works out, domain by domain, which records transfer outright, which are split, and which are duplicated so both sides keep what they need. This is selection work that requires understanding the business, not a query that a system can run on its own.

Data protection shapes the customer and supplier selection. Personal data in those records can only move on a proper basis, and the entity should not receive records, or fields within records, that it has no right to hold. The buyer makes sure the split respects those limits, which sometimes means the entity takes a customer relationship but not the full history attached to it. This selection feeds directly into the system cutovers it underpins, including the EDI trading-partner cutover that relies on matching partner records.

Section 03

Cleansing before it lands.

A carve-out is a rare chance to clean master data before it lands in new systems, and the buyer takes it. Group master files accumulate duplicates, obsolete records, inconsistent formats, and missing fields over years, and copying that mess into the standalone systems simply carries the problem forward. Cleansing during the split, while the data is being moved anyway, is far cheaper than trying to fix it in a live production system later, when every change risks breaking a transaction.

The cleanse targets the flaws that break downstream processes. Duplicate customer and supplier records are merged so invoicing and payments hit one clean record, missing critical fields such as tax identifiers or bank details are completed so the record is actually usable, and inconsistent codes are standardised so inventory and reporting reconcile. The buyer prioritises by impact, fixing the records that feed Day One transactions first, rather than trying to perfect every field in a file that may run to many thousands of records.

Validation closes the cleanse. Before the cleaned data loads into the standalone systems, the buyer checks it against the rules those systems will enforce, so records that would be rejected or would behave wrongly are caught before go live rather than during the first transaction run. Loading clean, validated master data into a new system is what lets the first invoice, the first order, and the first stock movement succeed instead of failing on a bad reference.

Section 04

Governance so it stays clean.

Clean master data degrades without governance, and a carve-out is exactly when governance gets forgotten. Inside the group, central data teams and standards kept the master files in order, and the entity inherited that discipline without owning it. On its own the entity has to provide its own, or the data it cleaned for Day One drifts back into duplicates and gaps within months as new records are created without rules. The split is wasted if nothing maintains its result.

Governance means clear ownership and clear rules. The buyer assigns an owner to each master data domain, the customer master, the supplier master, the material master, so someone is accountable for its quality, and sets the rules for how a new record is created, approved, and maintained. A standing rule that a new supplier cannot be used until its record is complete and approved is the kind of simple control that keeps the file clean, and it has to be in place from the start, not added after the data has already decayed.

The governance also has to fit the standalone entity's scale. A lightweight model with named owners and a few firm rules suits a smaller business better than a heavy central function it cannot staff, and the buyer designs governance the entity can actually sustain. Standing up this discipline alongside the data load, as part of the coordinated separation the TSA Exit Acceleration service runs, is what protects the cleanse from quietly undoing itself.

Section 05

Proving the data holds up.

The split is proven by running real transactions against the loaded master data before Day One. The buyer puts a representative set of orders, invoices, payments, and stock movements through the standalone systems and confirms they find the right records and complete cleanly. If a test invoice cannot locate its customer, or a test payment fails on a bad supplier record, the master data is not ready, and that is far better discovered in a test than in the first live billing run when a customer does not get invoiced.

The test also checks completeness, not just correctness. It is not enough that the records present are clean; the records the business needs all have to be there. The buyer confirms that the customers it will bill, the suppliers it will pay, and the materials it will move on Day One all exist in the new master data, because a missing record is as disabling as a wrong one. A customer that simply was not carried across cannot be invoiced, however clean the rest of the file is.

Master data management split rewards the buyer that respects how much sits on top of it. Selecting the entity's true records, cleansing them before they land, governing them so they stay clean, and proving them with real transactions lets every standalone system start on solid foundations. Treating master data as a copy job is how a carve-out with brand new systems still spends its first months chasing failed invoices, blocked payments, and broken inventory back to a reference file nobody fixed.

FAQ

Master data split questions buyers ask.

What is a master data management split in a carve-out?

It is deciding which master data, the customer, supplier, material, and product records that systems share, follows the carved-out entity, then cleaning and governing it on a standalone basis. Master data sits underneath every operational system, so the split determines whether the entity's new systems start with clean, complete reference data or inherited mess.

Why can the entity not just copy all the master data across?

Because much of the group's master data does not belong to the entity. Shared customers and suppliers, group level material catalogues, and records for other business units would all come across in a blind copy, bringing data the entity has no right to or no use for. The split has to select the records that are genuinely the entity's.

What goes wrong when master data is split badly?

Every downstream system suffers. Duplicate or missing customer records break invoicing and shipping, bad supplier data stops payments, and inconsistent material codes corrupt inventory and reporting. Because master data feeds everything, a poor split shows up as a hundred small operational failures that are hard to trace back to their source.

Who should own master data governance after separation?

The standalone entity needs its own data governance, with clear ownership of each master data domain and rules for creating and maintaining records. Inside the group this governance was often central. On its own the entity has to assign owners and standards so the data it cleaned for day one does not degrade again within months.

Related Reading

More on the data estate.

Free Download

Get the buyer-side TSA Exit Playbook.

The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.

No spam. Unsubscribe in one click. · Read the overview first →

Get the master data wrong and everything downstream breaks.
TSA Exit Acceleration

Start your systems on data that holds.

Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.

White paper

The TSA Exit Playbook

Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.

Read the playbook →
The Day One Letter

Get buyer-side TSA intelligence every two weeks

One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.

Subscribe to The Day One Letter →
White paper

The Data & Analytics Separation Playbook

Scope the data split tightly. Every table you over-migrate and every pipeline you leave on the seller is a line on next year's TSA invoice.

Read the playbook →