Last week, we asked whether master data should drive business process. The answer was mostly no. Master data can define the shared entities the business depends on, but the process still has to explain what those entities are supposed to do. If the model gets too far ahead of the work, teams end up with clean definitions that do not fit how the business actually runs.

This week, we move into a related mistake: assuming ERP will clean up the master data problem. ERP may be the right place for payment terms, plant settings, cost postings, or invoice status. It is not the right place to settle every argument about customer identity, supplier ownership, product hierarchy, or survivorship. Those decisions need an operating model before they need another system field.

Your ERP Will Not Fix Master Data Problems

The vendor file looked fine until someone sorted it by tax ID.

That one move changed the conversation. A supplier that appeared once in the sourcing portal showed up twice in ERP. The trade name matched the contract record, but the legal name did not. One vendor site had the current remit-to address. Another had the payment block removed six months ago because a legacy interface still needed it.

The AP team knew which record to use. Procurement had a different answer. Compliance was looking at the legal entity, not the pay site. None of those teams was being careless. Each version made sense inside its own workflow.

Then the ERP migration pulled the differences into one workbook.

Someone eventually said, “We’ll fix that when we move it into ERP.”

It sounded practical. The ERP project had funding, vendor support, a steering committee, and a go-live date. A separate master data effort sounded slower. It also sounded harder to explain to leadership.

ERP can store the record, but the unresolved decisions still sit outside the application.

ERP Is Built for Process

A blocked vendor can stop payment. A missing plant setting can stop purchasing. A bad cost center can show up during close, when everyone has less patience and fewer spare hours.

That is where ERP is strong. It supports the process and enforces the rules needed to move work forward. Buy this. Receive that. Post the invoice. Pay the vendor. Close the period.

The vendor, item, cost center, location, billing account, and company code are not just fields on a screen. They are checkpoints in the workflow. If one is missing or wrong, the process slows down or stops.

MDM enters when those same records leave the workflow and start showing up everywhere else. A supplier record may feed procurement, finance, compliance, contract management, analytics, and third-party risk review. A customer record may move through CRM, billing, support, marketing, portals, and reporting.

That view works until another team needs the record for something ERP was not built to answer.

In ERP, the supplier might be the payables vendor. In procurement, it might be a sourcing relationship. In compliance, it might be a risk profile tied to a legal entity. None of those views is automatically wrong.

Trouble starts when the payables view becomes the version every other team is expected to use. Sales asks for account structure. Compliance asks for beneficial ownership. Analytics wants to know why spend is split across three supplier IDs.

The ERP record may be fine for payment, while still weak for enterprise identity.

How ERP Becomes the Master by Accident

Most teams do not choose ERP as the master after a careful design review. They drift into it because the ERP project is already moving.

The budget is there. The timeline is there. The implementation partner is asking for data load templates. Test cycles are on the calendar. Interfaces need source and target fields. Someone has to decide where customer, supplier, product, location, and finance data will come from.

MDM work, by comparison, feels like the thing around the edges. Everyone agrees it matters, but it crosses departments. It touches old systems. It requires business decisions that many teams have avoided for years.

The terminology makes the drift easier. ERP teams use phrases like vendor master, customer master, material master, and chart of accounts. Those terms make sense inside the application. A vendor master in ERP may still be only the payables version of that supplier.

During implementation, teams usually want fewer decisions, not more. If the ERP has a table for the record, the shortcut is obvious: load the data, clean what breaks, and call ERP the system of record.

By that point, the integration team is already building around the assumption. Reports, APIs, batch feeds, and downstream extracts start treating ERP as the source before the business has settled the rules behind the data.

Who owns supplier identity? Who decides when two products are the same? Creation rights, request rights, survivorship rules, and approval steps all need answers before the interface design freezes.

By the time table design is reviewed, some of those choices are already baked in.

When the Vendor File Starts to Crack

The first data load may even pass. Required fields are filled, payment terms are present, and the migration dashboard looks green enough for the next meeting.

Then someone checks the details.

One vendor has a corporate legal name in ERP, a trade name in procurement, and an old acquisition name in the contract system. The tax ID matches two records. The remit-to address is valid for one business unit but wrong for another. One vendor site is blocked for payment. Another record is still active because a nightly job depends on it.

ERP did not create the mismatch; it made the mismatch harder to ignore.

The business still has to decide what the record means. Is the supplier the legal entity, the operating unit, the pay site, the contract party, or the sourcing relationship? For some teams, the pay site matters. For others, the legal entity does. For reporting, the parent-child relationship may matter more than either one.

Governance can handle that, but not with a blanket rule like “ERP owns vendor.”

This is why ERP master data cleanup often disappoints. Teams fix the obvious defects, load the cleaned file, and carry the same unresolved questions into production. A vendor record can be valid enough to pay and still weak as an enterprise supplier record.

Customer and Product Data Break Differently

Customer data brings the same argument in a different form.

Sales might care about territory. Billing needs the legal parent. Support works from service contracts. Analytics eventually asks for all of it, including the historical rollup. If ERP owns the customer only through billing rules, other teams start working around it with local fields, shadow mappings, manual exports, and report-side logic.

The ERP record may still look clean on paper, even while teams outside ERP stop using it as their trusted source.

Product data usually breaks in a different place. The ERP item might support costing, inventory, and purchasing. Commerce needs the sellable version: descriptions, images, GTINs, bundles, substitutes, web categories, and market-specific names. Engineering is thinking about revisions and lifecycle status. Reporting wants product families that may not match how stock is managed.

An item number in ERP does not carry every meaning the business attaches to the product.

Location data has a quieter version of the same problem. A plant, warehouse, billing address, shipping address, and service region may refer to related places, but they answer different business questions.

Blaming ERP misses the point. ERP is often one participant in a wider master data model.

The System of Record Trap

You can hear it in design meetings: “ERP is the system of record, so use that value.”

Sometimes that is the right call. Often, it is an unfinished thought.

When people say “system of record,” they often mean the official place to look for a specific purpose. The phrase gets stretched. People hear “official” and assume every field in that system wins. A customer in ERP becomes the customer. A supplier in ERP becomes the supplier. A product in ERP becomes the product.

That shortcut hides a lot of decisions.

ERP might be right for billing terms, while CRM holds the account relationship and another platform controls consent. Support entitlements may live somewhere else entirely. For suppliers, ERP may own payment status, while procurement owns sourcing status and compliance owns risk classification.

Storing, validating, approving, and publishing are different responsibilities.

The same field can pass through several kinds of authority: storage in ERP, approval by finance, validation against a tax service, publication through a master data API. If those roles are not clear, people argue about where the field lives instead of who is allowed to decide it.

The location of the record is only one part of the answer. You still need to know which system is trusted for which attribute, under which rule, for which use.

At that point, the ERP design is doing governance work whether anyone admits it or not.

The trap starts when every conflict gets routed back to ERP. A missing field becomes an enhancement request. A source conflict turns into a configuration debate. Integration teams waste time asking whether the ERP value wins by default.

Most of those debates are really about ownership.

A system can store a value without being the right place to decide that value. Make that call early, before data migration turns assumptions into design.

Where ERP Is the Better Owner

ERP is usually the better owner when the data is tied tightly to the process it runs.

If payment terms drive invoice approval and cash timing, ERP is a logical owner. If plant-level item settings control purchasing, inventory, or manufacturing, ERP probably needs authority there too. Company codes, cost postings, invoice status, purchase order state, and period close controls often belong in ERP because that is where the audit trail and workflow already exist.

Some master data attributes fit there as well. Finance may own tax setup, credit control, legal billing name, or payment method. Supply chain may own procurement status or inventory unit of measure. Manufacturing may depend on ERP for plant-specific item settings.

Problems start when that narrow ownership becomes domain ownership.

The pattern is common. ERP owns a few finance-controlled supplier fields, so the whole supplier domain gets assigned to ERP. The same thing happens with customers and products. A valid ERP need becomes a broad master data claim.

Then every non-ERP use case has to bend around an ERP-shaped record.

The test I would use is simple. If the field only matters inside the ERP workflow, ERP may be the right owner. If the field shapes how several systems identify, classify, govern, or report the same entity, slow down.

Those fields need shared rules before they need another table.

Where ERP Starts to Overreach

Many records are born outside ERP.

A supplier can start in a procurement portal. A customer may show up in CRM months before billing. A product might begin as an engineering part long before anyone sells or stocks it. If ERP is the only recognized master, early lifecycle data gets pushed into the wrong place or ignored until later.

That “later” is usually migration, reporting, or integration testing.

Hierarchy is where the pressure becomes obvious. Billing wants the legal parent. Sales wants the account team rollup. Risk may care about exposure across related entities. Each structure answers a different question, but teams often try to force one hierarchy to serve all of them.

I have seen this show up first in reporting. Finance asks for revenue by legal parent. Sales asks for revenue by account team. Both reports use “customer hierarchy,” but the words are doing different jobs. When one hierarchy is forced to serve both, someone ends up exporting data and rebuilding the rollup in Excel.

The report is only where people notice the design problem.

ERP also becomes the catchall for fields that belong somewhere else. Risk ratings, external identifiers, digital catalog details, marketing segments, service tiers, consent flags, UNSPSC categories, DUNS numbers, and enriched address data may come from specialized systems or third-party sources.

Loading all of that into ERP can turn the ERP into a storage bin for fields no one really owns there. More fields get added, and the ownership gap stays.

Federated Control Is Often More Realistic

Most organizations cannot stop CRM, ERP, procurement, support, compliance, and reporting from keeping their own IDs overnight.

A giant central MDM hub may be useful later. Many programs need a lighter control pattern first. Federated control accepts what most architectures already show: authority is spread out.

Shared rules still matter. They just sit above local execution instead of pretending one system owns everything. ERP can own payment setup. Procurement can own sourcing context. Compliance can own risk status. A master data service can manage identity, crosswalks, and publishing.

That kind of model is less elegant than a single-box architecture diagram. It is also closer to how large systems actually run.

The key is to make the handoffs explicit. Which fields does ERP own? Which fields does it consume? Which fields does it publish? Which fields should stay outside ERP even if the table has room?

Without those answers, the tool discussion usually turns into another round of guessing.

Pattern 1: Federated Registry

When no one can shut down the old IDs, build the crosswalk first.

A federated registry keeps local systems in place while creating a shared index of key entities. CRM, ERP, and support may all keep their own IDs. The registry records how those IDs relate.

This is often the first pattern that survives contact with politics. Old systems stay online. Teams keep their local workflows. The enterprise gets a way to see that customer 10488 in CRM, account C-77821 in ERP, and support account 9912 are the same customer.

A registry will not clean every field, but it does make duplication and identity conflict visible. That can shift the conversation away from “Which system wins?” and toward “Which system is trusted for this attribute?”

A registry is often the first honest map of the mess.

Pattern 2: Coexistence Hub

A coexistence hub gives the enterprise more control without pretending every field belongs in one place.

Some attributes move under central control while local systems keep the fields they are best suited to manage. For suppliers, the hub might control global identity, duplicate status, tax identifier, and risk classification. ERP might still own payment terms and company code setup. Procurement keeps sourcing status. Compliance owns certifications and review outcomes.

This pattern is often useful during ERP modernization. It lets the program clean and govern key master data without turning ERP into the owner of everything. ERP receives the approved fields it needs. Other systems keep the context they need.

Coexistence sounds manageable until field ownership gets vague.

If no one knows who owns legal name, payment name, display name, and preferred name, the hub becomes another place where confusion lives. The model needs rules that people can explain without a diagram.

Pattern 3: Central Governance Hub

If a bad supplier record can trigger payment risk or compliance review, a registry may not be enough.

A central governance hub fits domains where duplicate prevention, audit trails, approvals, and rule enforcement matter more than speed. Supplier onboarding is a common case. So are regulated product data, legal entities, finance structures, and high-risk customer domains.

In this pattern, records pass through a governed workflow before they are published to consuming systems. ERP receives approved records. CRM, procurement, analytics, and other systems may receive the same governed identity through APIs, events, or batch feeds.

It slows some work down, but that may be the point when the risk is high enough.

Think about a supplier that fails a sanctions check, uses an invalid tax ID, or matches an existing vendor under a slightly different name. Letting that record flow into ERP first and cleaning it later creates extra work. In some environments, it creates real risk.

Teams usually get into trouble when they try to govern too much. If every small change needs central approval, users route around the system. They create local notes, manual mappings, and side processes.

Stronger control belongs on fields where a bad value costs money, creates risk, or stops work.

Pattern 4: Governed Publish and Subscribe

A clean record sitting in one hub does not help the systems still using yesterday’s copy.

Governed publish and subscribe distributes approved master data to consuming systems. ERP might receive supplier updates, while CRM gets customer identity changes and analytics gets hierarchy versions. Other applications may need events instead of nightly files.

The record may be fixed, but the fix does not travel.

You fix supplier status in ERP, but procurement still works from an old extract. Somewhere else, BI is reporting through last month’s hierarchy. A data steward fixes the record in one place and then spends the next week explaining why five other systems still look wrong.

The publishing model forces useful design questions. What fields are sent? How often? In what format? What version is active? What happens when a receiving system rejects the update? Who gets alerted when a required field is missing?

Those questions are usually skipped until something breaks.

Without a governed distribution path, teams go back to extracts, copies, and manual fixes.

Choose the Pattern by Domain

Start with the domain before choosing a tool.

Supplier onboarding, plant-specific material settings, cost centers, and digital product content do not carry the same risk. Treating them the same is how governance becomes both too heavy and too weak.

A few questions usually expose the right direction. How many systems create or update the data? Which fields create the most risk when wrong? Who owns the outcome when the data is wrong?

Approval rules and timing matter too. Some domains need review before a record can be used. Others need fast distribution after a trusted change. Those needs should shape the MDM architecture pattern.

Many programs end up with a mix.

A customer domain might use a registry for identity, coexistence for shared attributes, and publish and subscribe for downstream systems. A supplier domain might use a central governance hub for onboarding while ERP remains the owner for payment setup.

For some domains, the honest diagram is the one that shows split authority and names the handoffs.

Start Before ERP Design Hardens

Waiting until data migration is too late. By then, field mappings are drafted, interfaces are in motion, test scripts are being built, and teams are under pressure to load something.

Profile the data that will enter ERP. Look for duplicate vendors, missing tax IDs, invalid addresses, stale products, orphaned cost centers, and conflicting hierarchy values. Counting defects helps, but the better question is what each defect can break.

A duplicate supplier may show up as split spend, missed discounts, blocked payments, tax reporting risk, or duplicate onboarding work.

Map ownership by attribute, not just by table. A customer table can have fields owned by sales, finance, legal, support, and data governance. A single table owner is rarely enough.

Define which systems can create records and which systems can request records. Those are different rights, and mixing them up is one way duplicates spread. Set survivorship rules before migration. If CRM and ERP disagree on customer name, which wins? If procurement and finance disagree on supplier status, which value should flow downstream?

If there is no answer, the migration team will invent one.

Decide how ERP will receive updates after go-live. A one-time ERP master data cleanup helps, but master data keeps changing. Without a post-go-live control pattern, the data will decay again.

Many teams treat cleanup as a migration task, then act surprised when the same defects come back after go-live. The spreadsheet captured the cleanup work. It did not define who would keep the data clean after go-live.

ERP Has a Role. It Is Not the Whole Strategy.

For finance, procurement, inventory, and operational process data, ERP may be exactly where authority belongs.

But ERP should not become the place where unresolved data decisions go to hide.

Undefined domains, weak ownership, missing survivorship rules, and loose creation rights do not disappear at go-live. ERP receives those choices, or the lack of them.

Before go-live, decide what ERP owns, what it consumes, and what it should leave alone. ERP can run the process while governance defines the rules around shared data. Federated patterns can handle spread-out ownership. Central control can be reserved for the domains where bad data carries real cost.

Give ERP a clear role, then stop asking it to make decisions the business has avoided.