Master Data Management

Last quarter your finance team ran three reports, one each from the ERP, the CRM, and the data warehouse, and got three different customer revenue numbers. Each was technically correct given how that system defined 'customer.' That is a master data problem. Master data management (MDM) is the discipline of creating and maintaining one authoritative version of the core entities your business runs on (customers, vendors, products, cost centers, employees) across every system that uses them. Without MDM, each system builds its own version of these entities over time: the CRM creates a customer record when a lead converts, the ERP creates one when an invoice is generated, and the warehouse creates one during onboarding. Nobody enforces that 'Acme Corp' in the CRM and 'Acme Corporation, Inc.' in the ERP are the same entity. Three months later, finance can't reconcile revenue by customer without a manual join. MDM fixes this by setting governance rules, ownership, and a system of record for each entity type before data spreads across systems. It is both a technical architecture and an organizational discipline, and most implementations fail when teams treat it as only one of the two.

How it works

MDM works by naming one system as the source of record for each entity type and requiring every other system to consume that entity instead of creating its own. In B2B finance operations, the customer master usually lives in the CRM or ERP, the vendor master in the ERP or procurement system, and the chart of accounts in the ERP. MDM governance defines who can create new records in the source system, which fields must be populated before a record is valid, and how duplicates are found and merged. The technical layer can follow three architectures. Registry-style MDM builds a central index of master records and links each downstream system's local records back to the canonical identity, without moving data. Consolidation-style MDM pulls records from all systems into a central hub, resolves them into golden records, and publishes the golden records back out. Coexistence-style MDM keeps the golden record centrally while letting systems hold their own local copies that sync on a schedule. Each carries different trade-offs in latency, conflict resolution, and governance. The most common failure in mid-market MDM is picking a technical architecture before defining the governance model, so the technology ends up enforcing rules nobody agreed to.

Where it gets complicated

Each entity type in financial master data fails in its own way. Customer master data breaks most often through duplicates: a new sales rep creates a CRM record for an existing customer under a slightly different name, producing two revenue histories that analytics tools can't join without manual work. At 5,000+ customer records, deduplication becomes a significant project. Vendor master data breaks through uncontrolled creation during urgent purchases: a team needs to pay a new supplier quickly, creates a vendor record without standard vetting, and the ERP fills up with hundreds of one-time vendors with incomplete banking details and no spend categorization. The chart of accounts breaks through proliferation: business units request new GL accounts to track granular activity, and within two years there are 800 accounts that don't map cleanly to management reporting categories. Without MDM governance, each pattern feeds itself. The more records exist, the harder standards are to enforce, and the more workarounds teams build. The governance step most MDM initiatives skip is assigning a named data owner for each entity type: a specific person accountable for record quality, not a team.

How platforms handle it

Most mid-market ERP systems include basic master data management: customer and vendor creation workflows, required field validation, duplicate detection rules, and chart of accounts hierarchy management. If you run a single ERP as the finance system of record, these native features are often enough. A standalone MDM platform such as Stibo, Profisee, or Reltio makes sense when master data spans several systems that each need to stay authoritative for different subsets of data, when an M&A deal means consolidating entity records across two or more ERP instances, or when the volume and complexity of entity relationships is beyond what the ERP's native governance tools can handle. Before evaluating standalone platforms, count how many systems currently create master records and decide whether the governance problem is technical or organizational. Many mid-market MDM failures come from buying a platform to fix a process problem: records are inconsistent because nobody is accountable, not because the technology falls short.

Questions to ask before selecting an MDM approach

• For each entity type (customer, vendor, product, GL account), which system is currently the source of record, and is that designation documented and enforced?
• How many duplicate or conflicting records exist today in each system, and what is the manual effort required to resolve them?
• Who is the named data owner for each entity type, and what authority do they have to reject or merge records created by other teams?
• Does the ERP's native record governance (required fields, duplicate detection, approval workflows) cover our current entity volume and system footprint?
• If we are running multiple ERP instances or have completed M&A, how are entity records reconciled across systems today?
• Is MDM being evaluated as a technology purchase or as an organizational governance initiative, and do we have executive support for the process changes it requires?

Common mistakes

The most common MDM mistake is scoping it as a data cleanup exercise instead of an ongoing governance discipline. Teams deduplicate the customer master before a new ERP go-live, declare success, and then watch the same fragmentation return within 18 months because no rules were put in place to prevent it. A second mistake is starting cleanup before assigning data ownership. Without a named owner for each entity type, nobody is accountable for record quality and nobody has the authority to reject bad records from other teams. The cleanup has no defender. A third mistake is conflating MDM with data migration. Data migration is a project with a start and end date that moves records from one system to another. MDM is an operational discipline that continues after go-live. Organizations that treat MDM as a migration deliverable find out 18 months later that the migration was clean, the governance never happened, and they are back to three different revenue numbers from three different systems.

Not mobile device management

MDM is a shared acronym and the search results reflect it: most of them are about mobile device management, which is IT security. Master data management is the opposite end of the stack. It covers who may create a supplier record, which system owns the customer master, and how duplicates are detected. Duplicate supplier records are the usual symptom of weak master data in finance, because they enable duplicate payments.

Comparing ERP platforms

Most of an ERP decision is settled by data model and entity structure, not by the feature list a demo walks through. Once master data management is settled as a requirement, read the ERP Software category guide for how the market splits, then weigh the NetSuite profile against the Sage Intacct profile on that requirement rather than on the feature list. Our OneStream pricing breakdown records what the vendor publishes and what is quote-based. The OneStream against Planful comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the ERP ROI calculator so the business case is written down before a vendor writes it for you.

Master Data Management questions

Related terms

Chart of Accounts Mapping, Cloud ERP vs On-Premise ERP, and Enterprise Resource Planning (ERP) come up in the same workflow as master data management, and the rest of the ERP platforms cluster is indexed in the finance operations glossary.