Single-domain or multidomain MDM: where to start your master data

Treat it as two decisions: architecture and scope. Choose a platform that can handle several domains, so you do not build silos when the second domain arrives, and start with a single domain: the one where the business pain can be measured, the data owner is available and the result is visible to whoever pays for the program. Materials, suppliers or customers: let the pain decide, not whoever speaks loudest in the meeting.

I have sat in this meeting on many projects. The MDM program is approved, the budget is there, and someone asks: "Which master data do we start with?"

Procurement wants suppliers, because that is where unapproved suppliers and expired documents show up. Engineering and maintenance want materials, because the same item exists under different descriptions and nobody can find the right part. Sales wants customers, because orders get stuck on a wrong address or an outdated credit limit. Every director is right about their own pain. What the room is missing is a way to choose.

What is single-domain MDM and what is multidomain MDM?

SAP defines the discipline like this: "Master data management is the discipline of creating and maintaining a single, trusted view of an organization's most important business data across systems." The same page explains that master data is usually organized into domains based on the core type of business entity, such as customers, suppliers, products, materials and assets (SAP, What Is Master Data Management?).

From there, this is how I explain the terms:

• Domain: a type of business entity with its own model, rules and owners. Material, supplier, customer, finance and reference data are the most common.
• Single domain: the program and the tool cover one type of entity only. For example, materials only.
• Multidomain: one platform, one model and one governance approach covering several domains, with shared rules, workflows and reference data.
• Several domains in separate tools: each domain has its own tool, its own rules and its own team. On the org chart it looks like multidomain; in daily operations it is a set of silos that do not talk to each other.

If you want a refresher on MDM and how it relates to the ERP, I wrote about it in what MDM is and how it underpins the ERP.

Are choosing multidomain and choosing where to start the same decision?

No. And this is where many of these meetings go off track.

The architecture decision answers: can the platform we use handle more than one domain with the same workflow model, the same rules, the same change history and the same reference data? This decision looks years ahead.

The scope decision answers: which domain goes into the first wave, with what boundaries, which owner and what expected result? This decision looks months ahead.

One does not force the other. You can have a multidomain platform and start with materials only. You can also buy a single-domain tool and find out, when suppliers come up, that you need another tool, another contract and another integration. Multidomain describes where you want to end up. The first domain describes where you step tomorrow.

What criteria should you use to choose the first domain?

The table below is the guide I recommend taking into the meeting. Ask the questions for each candidate domain and compare the answers. There is no universal weighting: the company's strategy at that moment defines how much each criterion counts.

Criterion	Question to ask	Sign of a good candidate
Measurable business pain	What damage does this master data cause today, and which indicator shows it?	The pain shows up in operations: repeat purchases, blocked orders, held payments, rejected invoices.
Available data owner	Who decides the rule and approves exceptions?	There is a named person with the time and authority to decide.
Error volume and recurrence	Is the error a one-off, or does it come back every week?	The same type of error keeps repeating and drives rework.
Dependency of other processes	How many processes stop when this data is wrong?	The domain feeds procurement, inventory, tax, billing or maintenance at the same time.
Shared reference data	Which common tables does this domain use?	Designing the domain forces you to organize units, countries or payment terms that later domains will reuse.
Anchor project	Is there a migration, rollout or regulatory change with a fixed date?	The domain is on the critical path of a project such as an SAP S/4HANA migration or Brazil's consumption tax reform.
Compliance risk	Does wrong data expose the company to tax penalties, fraud or sanctions?	An error in this domain creates tax risk, improper payments or dealings with unapproved third parties.
Ability to show results	Can you compare before and after within a few weeks?	There is a measured baseline and a scope small enough to show gains early.

Notice that "who is the sponsor" is not in the table. Without a sponsor there is no program at all, but the choice of domain should follow the pain. If the sponsor's domain is also where the pain is, great. If it is not, have the honest conversation before you start.

What changes between materials, suppliers and customers?

Each domain calls for a different kind of rule, owner and validation. Knowing the difference helps you estimate effort and pick the team.

Materials

The most common pain is free-text descriptions: everyone writes them their own way, and the same item ends up registered more than once. The work is standardizing descriptions, defining attributes by family, organizing classification (including tax classification such as NCM, the goods nomenclature used in Brazil and across Mercosur) and bringing engineering, maintenance, procurement and tax into the process. If this is your pain, see how to identify duplicate materials.

Suppliers

In Brazil, duplicate suppliers tend to be less common when the CNPJ (the Brazilian company registration number) is used as the key, provided headquarters and branches are handled, along with individuals (identified by CPF, the Brazilian individual taxpayer number) and foreign suppliers. The pain is different: suppliers without approval, expired documents, unchecked bank details, a registration status that does not match the official source. The work is validating data against official sources, controlling documents and approval deadlines, and giving procurement, finance and compliance clear roles in the workflow.

Customers

The pain shows up in orders and collections: wrong delivery addresses, poorly built corporate groups, credit limits that do not reflect reality, outdated tax data. The work involves sales, credit, logistics and tax, and the rules need to respect the corporate group hierarchy.

For companies on SAP S/4HANA, customers and suppliers live together in the Business Partner, which changes the conversation about keeping the two domains apart. I covered that in Business Partner in S/4HANA.

Why does reference data come before any domain?

Units of measure, countries, regions, currencies, payment terms, tax tables such as NCM: these are lists that almost every domain uses. If each domain designs its own version, the company ends up with three unit-of-measure tables and none it can trust.

My recommendation is to design reference data once, in the first wave, even if the first domain uses only part of it. This is the piece of a multidomain architecture that pays off most when the second domain arrives, because the foundation is already there.

What does this choice look like in a concrete case?

Hypothetical example: a manufacturer running SAP ECC is preparing to migrate to S/4HANA. In the scoping meeting, procurement asks for suppliers, maintenance asks for materials and sales asks for customers.

Using the table, the team notices three things. Materials has the most recurring pain (free-text descriptions, repeated items in the warehouse), an available owner in engineering, and sits on the critical path of the migration, because loading duplicate items into the new system just moves the problem. Suppliers carries high compliance risk, but its main rule (validation against official sources and supplier approval) can come right after, reusing the same reference data. Customers depends on Business Partner decisions that are still open in the migration project.

The decision: a multidomain platform from day one, a first wave on materials with cleansing before the load (see data cleansing), reference data designed to serve every domain, a second wave on suppliers and a third on customers once the Business Partner design is settled. Procurement and sales leave the meeting knowing when their turn comes and why.

When is it time to open the second domain?

I cannot give you a deadline, because every company moves at its own pace. I prefer to look at signals:

• The first domain runs day to day without needing the project team for every exception.
• Quality indicators have improved against the baseline and stopped swinging.
• The data owner decides rules and exceptions without escalating everything.
• Reference data is stable and documented.
• The area behind the next domain has a named owner and time set aside.

If most of these signals are still missing, opening the second domain usually splits the team's attention and delays both.

What mistakes should you avoid?

• Buying a single-domain tool without thinking about the second domain. It solves today's pain and creates tomorrow's silo.
• Trying to do every domain at once. The program turns into a backlog with no visible result.
• Starting with the sponsor's domain instead of the domain with the pain. The first wave has to prove value, and that is harder where the pain is smaller.
• Skipping the baseline. Without measuring first, nobody can show what improved later.
• Leaving reference data for later. Each domain invents its own table and the rework comes back in the second wave.

Where to start?

1. Settle the architecture decision. Decide whether the platform must cover several domains with shared rules, workflows and reference data. This comes before choosing the first domain.
2. Measure the baseline for each candidate domain. Use simple, comparable indicators. The steps are in how to measure master data quality.
3. Score the candidates with the criteria table. Bring the answers to the meeting and decide on that basis.
4. Name the data owner for the first domain. One person, with time and authority, before you start.
5. Design the shared reference data. Once, for every domain.
6. Evaluate the software and test it with your own data. For evaluation criteria, use the MDM software checklist. Once the domain is chosen, test with a real sample following the proof of concept guide.
7. Define the exit signals for the first wave. Agree in advance on which signals open the second domain, so the decision does not go back to a contest between directors.

Frequently asked questions

What is the difference between multidomain MDM and having several MDM tools?

With multidomain, one platform covers several domains with the same model, the same workflow rules, the same change history and the same reference data. With several tools, each domain has its own logic, its own ERP integration and its own team, and the common tables tend to be duplicated with differences between them.

Can you start with a single domain on a multidomain platform?

Yes, and it is the path I recommend. The platform ensures the second domain reuses what has already been built. The small scope ensures focus, a clear owner and a visible result in the first wave.

Which domain usually pays back fastest?

It depends on the company, and be wary of anyone who answers without looking at your data. The fastest return usually comes from the domain where the pain is recurring, has an indicator, has an available owner and sits on the path of a project with a fixed date. The criteria table in this article is there to help you find yours.

How long should you wait before opening the second domain?

Instead of a deadline, use signals: the first domain runs without the project team, indicators have improved and stabilized, the owner handles exceptions and reference data is stable. When those signals are there, the second domain comes in with less risk.

Is reference data a domain?

It can be treated as a domain of its own, with an owner and rules. In my view, what matters is treating it as a common foundation: designed once, with a defined owner, and reused by materials, suppliers and customers.

Isn't the ERP already multidomain?

The ERP stores many types of master data, but storing is not governing. MDM handles how data is created and changed: who requests it, who validates it, which rule applies, who approves it and what was sent to the ERP. That is why the MDM architecture decision still matters even when all master data already lives in the same ERP.

How 4MDG can help

The 4MDG SaaS platform covers material, supplier, customer, finance and reference data on the same platform, with every record set up as a configured workflow. That means you can start with one domain and open the next on the same workflows and reference data, with integration to ERPs such as SAP, TOTVS and Oracle. The details are on capabilities and architecture.

If you are still unsure which domain to start with, you can request the assessment: you send a sample of materials, suppliers and customers as a spreadsheet or extract, nothing is installed in your environment, and you get a duplicate rate, completeness by attribute, registration compliance, description quality and a recommended path.

Sources

• SAP. What Is Master Data Management? Accessed on October 14, 2026.