Keep ERP Master Data Clean Forever, Not Just at Cutover

What ERP Data Governance Actually Means

ERP data governance is the set of policies, roles, processes, and quality rules that keep an ERP's master data accurate, consistent, and trustworthy for as long as the system runs. Where data migration is a one-time move of records from a legacy system into the new ERP, governance is the permanent operating layer that decides who owns each data domain, how changes get approved, how quality is measured, and what happens when a record breaks a rule. DAMA International frames data governance as the core of its Data Management Body of Knowledge (DAMA-DMBOK): it establishes accountability, policies, and decision rights to ensure data is managed properly across compliance, risk, and operations.

Gartner defines the closely related discipline of Master Data Management (MDM) as a technology-enabled business discipline in which business and IT work together to ensure the uniformity, accuracy, stewardship, governance, semantic consistency, and accountability of the enterprise's official shared master data assets. The key word in that definition is business. Governance is not an IT cleanup project; it is a business accountability structure that IT supports. The most common reason ERP data degrades after go-live is that no business owner was ever named accountable for a domain, so every team feels free to create a duplicate customer, invent a new SKU, or leave a tax field blank.

The financial stakes are large and well documented. Gartner research found that poor data quality costs organizations an average of USD 12.9 million per year, and the firm describes that figure as conservative because many downstream effects (failed AI initiatives, lost customers, supply-chain disruptions) are hard to attribute. IBM's 2025 Institute for Business Value CDO study found that 43% of chief operations officers name data quality issues as their most significant data priority, and Forrester research cited alongside that work notes that more than a quarter of organizations estimate annual losses above USD 5 million from poor data quality. Classic data-quality economics still apply: the SiriusDecisions 1-10-100 rule (widely cited in master-data practice) puts the cost of verifying a record at entry at about USD 1, cleansing it later at about USD 10, and living with the error in operations at about USD 100. For a small or mid-size enterprise that has just spent six figures on an ERP implementation, allowing master data to decay back to its pre-migration state is the fastest way to erase the reporting, automation, and AI benefits the project was funded to deliver. Governance is the insurance policy that protects that investment.

Governance vs. Migration vs. MDM: Stop Confusing Them

Three terms get used interchangeably and cause most of the confusion in early governance conversations: data migration, master data management, and data governance. They are distinct layers, and conflating them is why so many SMEs finish a migration, declare victory, and then watch data quality collapse within twelve months. The table below draws the line cleanly.

A useful mental model is to think of the three as a stack. Migration is the one-off event that loads the data; MDM is the technology layer that keeps a single reconciled record across systems; governance is the human and policy layer on top that decides what the rules are, who enforces them, and what happens when they break. You can buy MDM tooling and run a flawless migration and still lose the data within a year if the governance layer is missing, because no technology enforces quality on its own — people and policies do. Conversely, a strong governance program can deliver excellent quality with only the ERP's native validation, which is why this guide treats governance as the foundation and treats a dedicated MDM platform as an optional layer added only when multiple systems of record demand it.

Master Data vs Transactional Data in ERP

Searchers and PAA boxes constantly ask the same question: what is master data versus transactional data? In an ERP, the distinction decides what you govern hard, what you archive, and where a single error can cascade. Master data is the stable nouns of the business—customers, vendors, items/products, employees, locations, and the chart of accounts. Transactional data is the verbs—sales orders, purchase orders, invoices, inventory movements, payments, and journal lines that reference those nouns by ID. Master data changes occasionally; transactional data is generated continuously and at far higher volume.

The cost-of-error asymmetry is why governance programs focus on master domains first. A wrong shipping address on a customer master can corrupt every shipment and invoice that points at that customer until someone fixes the golden record. A wrong quantity on a single sales order is painful but usually isolated to that event. Transactional data depends on master data for meaning: "Customer #4021 purchased Product #8899 for $149.99" is only useful if those IDs resolve to complete, unique, current masters. When teams blur the two—treating order history as "the customer" or rebuilding product attributes from last-year's lines—duplicate masters, broken reporting, and failed automations follow.

Practical implication for SME ERP governance: put ownership, change-request workflows, and quality KPIs on customer, vendor, item, and CoA masters first. Keep transactional controls (approval limits, period close, segregation of duties) in finance and operations process design, but do not dilute the master-data stewardship program by measuring every journal line the same way you measure the customer master. Archive and retention policy for transactional history is a separate discipline from keeping the golden record clean.

The Four Roles That Make Governance Real

Governance fails without named people. The DAMA-DMBOK framework, which is the de facto reference used across DAMA, the UK Government Data Quality Hub, and most enterprise programs, defines a small set of roles that translate policy into daily behaviour. For an SME running a single Dynamics 365 or Odoo instance, you do not need all of them at enterprise scale, but you do need the accountability each one represents. A governance operating model is simply the system of decision rights, roles, forums, and routines that makes the discipline happen.

The Data Governance Council (sometimes called a steering committee) is the top of the structure. It is a cross-functional body, typically chaired by a COO or CFO, that sets strategy, approves data policies, prioritises remediation work, and arbitrates cross-domain disputes (for example, whether Sales or Finance owns the customer record). Below the council sit the four working roles. Assign these before go-live, not after the first reconciliation break — the migration guide covers the move; this is where ownership lives permanently.

A Data Owner is a senior business leader accountable for a data domain. The owner of customer data is usually the head of Sales or Customer Service; the owner of product or item data is usually the head of Operations or Supply Chain; the owner of the chart of accounts is the Finance director. Owners define the policies, quality thresholds, and access rights for their domain and answer for breaches. A Data Steward is a subject-matter expert who executes governance day to day — maintaining definitions, monitoring quality rules, triaging exceptions, and resolving issues. Stewards do not own the data; they assist the owner in implementing policy. A Data Custodian is the IT role that stores, secures, and technically operates the data. Splitting these three is what stops the classic failure mode where IT becomes the de facto steward of data it does not understand.

Domain Owners: Customer, Item, Vendor, and CoA

Generic "data is important" posts lose to pages that name who owns what. For a single Dynamics 365 or Odoo instance, start with four mandatory domains—customer, item (product), vendor (supplier), and chart of accounts—and publish a RACI the business can run without a CDO office. Each domain gets one Data Owner (accountable), one or more Data Stewards (responsible for day-to-day quality), and IT as Data Custodian (consulted for system constraints, informed of policy). The governance council is accountable for resolving cross-domain conflicts, such as whether a customer bill-to is Finance-owned while ship-to preferences stay with Sales operations.

Customer domain ownership is the most disputed. A workable SME pattern: Finance owns billing identity, tax IDs, credit limit, payment terms, and posting groups because those fields drive invoicing and statutory reporting; Sales or Customer Success owns commercial attributes (segment, account manager, service level) that must still stay consistent with the ERP golden customer once conversion happens. Item ownership usually sits with Operations or Supply Chain for SKU identity, units of measure, costing method, and replenishment attributes, with Finance consulted on valuation and inventory accounts. Vendor ownership sits with Procurement or Accounts Payable for legal entity, bank details, and payment terms—high-risk because banking changes are a fraud vector. Chart of accounts ownership is non-negotiable Finance: only Finance creates or retires GL accounts, and every new account requires an owner-approved change request.

Publish the RACI on one page, attach it to the governance charter, and review it whenever an ERP major release or org restructure moves process ownership. Stewards without owners become IT helpdesk tickets; owners without stewards become unread policy decks. The table below is a starter you can paste into your charter and edit for titles in your company.

Establish One Golden Record per Master Entity

The single most important architectural decision in data governance is declaring one system of record — one golden record — for each master entity. A customer's billing address, credit limit, and contact details must live in exactly one place; every other system that needs them reads from or defers to that source. Without this rule, governance collapses into endless reconciliation, because there is no authoritative version to enforce. For most SMEs the ERP itself (Dynamics 365 Business Central, Finance & Operations, or Odoo) is the natural system of record for customers, vendors, items, and the chart of accounts, with the CRM integrated as a downstream or upstream peer depending on the entity.

Defining the golden record means writing down the survivor rules: when two records conflict, which wins? For a merged customer, does the most recently updated address win, the most complete record, or the one from the highest-revenue relationship? These rules should be explicit, documented, and approved by the data owner, because they are the standard the deduplication tooling applies automatically. Gartner's framing of MDM as ensuring semantic consistency across shared master data assets is fundamentally about this: every system must agree on what the authoritative version of each entity is.

For a typical SME running one ERP and one CRM, the pragmatic pattern is: the ERP owns financial master data (customers for billing, vendors, items, GL accounts) and the CRM owns prospect and lead data until a prospect converts, at which point the ERP customer record becomes golden. Integration should flow the golden record's key fields back to the CRM so sales teams are not working from stale copies. When a conflict arises — a sales rep edits an address in the CRM the same week Finance updates it in the ERP — the survivor rule and the integration direction settle it deterministically rather than leaving two humans to argue.

Turn the Six Quality Dimensions Into Enforced Rules

Data quality is not a feeling; it is measurable. The DAMA-UK Six Primary Dimensions for Data Quality Assessment — accuracy, completeness, consistency, validity, uniqueness, and timeliness — are the vendor-neutral standard adopted across DAMA-DMBOK, the UK Government Data Quality Hub, and most enterprise programs. They apply equally to Dynamics 365 and Odoo. The migration guide uses them to score source data before loading; governance uses them as the ongoing scorecard that detects drift after go-live. The difference is that governance converts each dimension from an assessment into an enforced rule that runs continuously.

A data quality rule is a specific, testable statement that prevents, monitors, or reports insufficient quality of a data value or record. Rules fall into a few practical categories: validation rules (a postal code must match the country pattern; a tax ID must pass the checksum), completeness rules (every customer must have a posting group; every item must have a costing method), standardisation rules (phone numbers are stored in E.164 format; country codes are ISO-3166), uniqueness rules (no two active customers share the same tax ID), and consistency rules (the customer's currency matches their country's default). The goal is to make the ERP enforce as many of these as possible at the point of entry, so that bad records never get created in the first place — your ERP should enforce data rules at entry as the first line of defense, using required fields, dropdown lists, and conditional logic.

For the rules that cannot be enforced at entry (for example, detecting near-duplicate customers that pass uniqueness checks but represent the same real-world entity), stewardship runs them on a schedule and routes the exceptions to a human by exception. This is the core principle of sustainable stewardship: automate the deterministic checks, and let the data steward spend their time only on the judgement calls. A mid-size business with disciplined point-of-entry validation and a weekly duplicate-detection batch can keep customer data quality above 98% with a part-time steward; the same business without these rules will see quality degrade within a single quarter.

The Data Change Request Workflow

Ownership and rules are theoretical until there is a workflow that enforces them. The data change request (DCR) is the standard unit of governed change: any creation or modification of a master record that is not auto-approved by an entry-validation rule passes through a defined intake, approval, and application path. Without a DCR workflow, master data changes happen ad hoc — a sales rep phones IT to add a customer, a buyer creates a vendor on the fly, an accountant invents a GL account — and within months the chart of accounts and vendor master are unmaintainable. With a DCR workflow, every change is attributable, reviewable, and reversible.

A practical vendor-onboarding example shows the model. A buyer identifies a need for a new vendor and submits a DCR with the legal name, tax ID, banking details, and payment terms. The AP data steward validates the tax ID, runs a duplicate check against the existing vendor master, and confirms banking details through a verified channel. The AP data owner (often the controller) approves. The steward creates the record in the ERP with the approved attributes and publishes the vendor number back to the requester. The whole flow is logged with timestamps, so audit can reconstruct who approved what and when. The same shape applies to new customers, new items, and GL account creation.

The approval gate's strictness should match the risk. A low-risk change (updating a phone number) can be auto-approved or steward-approved in one step; a high-risk change (creating a new bank-account vendor, adding a GL account, merging two customer records) should require owner approval and sometimes a second control. The temptation in an SME is to make every change a single-step self-service entry to keep things moving — this is exactly how data quality collapses. The discipline is to make the high-risk changes governed and the low-risk changes fast, so that governance is felt only where it actually protects the business.

Measure What You Want to Keep Clean

What gets measured gets governed. Gartner has reported that a majority of organizations still do not measure data quality (commonly cited around 59%), which is why governance programs lose budget fights to projects with a dashboard. The governance council should review a small, stable set of data quality KPIs every month—not a sprawling scorecard nobody reads. The most useful MDM and data quality KPIs cluster around completeness (percentage of required fields populated), accuracy (percentage of records matching a verified source), duplicate rate (percentage of records flagged as non-unique), match rate (share of inbound or cross-system records successfully matched to an existing golden record rather than creating a new one), time-to-create or time-to-approve (how long a DCR takes end to end), and the change success rate (percentage of changes applied without rework). Vendors and practitioners such as Stibo Systems, Semarchy, and data-quality platforms consistently recommend this family of measures because they are both meaningful and computable from the ERP itself.

Targets should be set per domain by the data owner, not imposed uniformly. Customer tax-ID completeness might target 100% (it is a legal requirement for invoicing in most jurisdictions), while customer email completeness might target 90% (useful for marketing but not legally mandatory). Item master accuracy might target 98%, while the chart of accounts targets 100% because every GL account rolls into financial statements. Industry practice for uniqueness and completeness on critical keys is strict: many data-quality frameworks target ≥98% completeness on key fields, ≥99.5–100% uniqueness on primary and natural keys, accuracy near 98% for customer and product masters, and duplicate rates under 2%. Match rate is the KPI that reveals whether integration and stewardship are working: a falling match rate usually means new-customer creation is outpacing dedup rules, or CRM-to-ERP identity mapping has drifted.

Publish the scorecard monthly to the governance council and, where appropriate, to the broader business. Visibility is a surprisingly powerful governance tool: when a sales team sees that their region's customer data is 84% complete while another region is at 97%, peer pressure does more than any policy document. Trend the metrics over time so the council can see whether quality is improving, stable, or decaying—and act before a slow drift becomes a reconciliation break. Pair the scorecard with a short narrative on the top three issues and the remediation in flight, so the meeting drives decisions rather than reading numbers.

Native ERP Tooling vs Dedicated MDM for Mid-Market

Most SMEs do not need a dedicated MDM platform on day one. Both major ERP ecosystems ship with enough native capability to run a credible governance program for a single instance, and the integration cost of a dedicated MDM tool (Profisee, Semarchy, Informatica, Reltio, Stibo, SAP MDG) is rarely justified below multi-system complexity or a few hundred million in revenue. The pragmatic sequence is: exhaust native capability first, add lightweight stewardship and quality tooling second, and only evaluate a dedicated MDM platform when you genuinely have multiple systems creating the same entity and need a hub for golden-record survivorship.

In the Microsoft ecosystem, Dynamics 365 Business Central and Finance & Operations both provide field-level validation, mandatory-field enforcement, and configured approval workflows out of the box. For cross-system governance, Microsoft Purview is the unified data governance, risk, and compliance family: it can register and scan a Dataverse environment, build a data map, run automated data quality checks (including configurable thresholds and, as of recent releases, incremental quality scans), and expose a searchable catalog. The Power Platform documentation covers how Purview governs Dynamics 365 and Power Platform data stored in Dataverse—catalog, classification, lineage, and access policies without leaving the Microsoft estate. For an SME on Business Central, this is often more governance tooling than is needed initially; for an SME on Finance & Operations with Fabric and Power BI ambitions, Purview is the natural control plane before a third-party MDM.

In Odoo, the native tooling is lighter but adequate for a single instance. Odoo's CRM includes a deduplication tool that finds near-duplicate leads and contacts by name, email, and phone; the importer enforces External IDs for idempotent create-or-update; required fields, selection lists, and Python constraints can be added per model with the Studio app or custom modules; and the built-in chatter and approval workflows give a lightweight audit trail. The gap in native Odoo is cross-instance and cross-system master management—if you run Odoo alongside a separate CRM or e-commerce platform, a small integration layer that funnels master changes through the Odoo golden record is usually enough until volume justifies a dedicated MDM. Before buying any tool, confirm the gap is real and not a process problem dressed up as a technology problem. The comparison table below is the decision frame mid-market teams should use with finance before a multi-year MDM contract.

A 90-Day Roadmap to Stand Up Governance After Go-Live

Governance is easiest to launch in the first ninety days after go-live, while the implementation team is still engaged, the data is freshly cleansed, and the business has not yet built bad habits around the new system. The roadmap below assumes a single Dynamics 365 or Odoo instance and a part-time data steward; it is deliberately sequenced so that each phase delivers something the council can see and approve before the next phase begins. Treat it as the post-go-live counterpart to the data migration playbook—where that guide ends at cutover, this one picks up the baton.

Days 1–30 are about establishing the operating model. Stand up the Data Governance Council with a named executive chair. Assign a Data Owner for each major domain (customer, vendor, item, chart of accounts, employee). Name at least one Data Steward per domain and confirm the IT Data Custodian. Write a one-page data governance charter that defines the roles, the council cadence (monthly is typical), and the escalation path. Baseline the current state of data quality by running the DAMA-UK six-dimension assessment against the freshly migrated data, so you have a starting score to trend against.

Days 31–60 are about rules and workflows. Publish the data quality rules per domain, converted from the six dimensions into specific, testable statements the ERP can enforce. Configure point-of-entry validation in the ERP (required fields, selection lists, format checks, conditional logic). Stand up the data change request workflow for high-risk entities—new vendors with banking details, new GL accounts, customer merges—with owner approval gates. Identify the top three duplicate clusters in the customer and vendor masters and assign remediation owners with due dates. Begin a weekly duplicate-detection batch routed to stewards by exception.

Days 61–90 are about measurement and cadence. Build the monthly governance scorecard with the starter KPI set (completeness, accuracy, duplicate rate, match rate, time-to-approve, change success rate, validation pass rate). Publish the first scorecard to the council with per-domain targets and a short narrative. Lock in the monthly council meeting as a recurring forum with a standing agenda: scorecard review, top issues, remediation status, policy decisions, and escalations. By day ninety, the program should be self-sustaining—owners know their targets, stewards know their workflows, and the council has a rhythm that survives the departure of the implementation team.

After day ninety, tie the governance calendar to the ERP release calendar—not only to the fiscal close. Microsoft and Odoo both ship recurring platform and application updates; every major version or feature wave can introduce new mandatory fields, deprecate APIs, change integration behavior, or enable Copilot/agent features that read master data at scale. Add a standing pre-release agenda item 2–4 weeks before each planned wave: which new fields need ownership, which validation rules must change, which integrations need re-match testing, and whether the AI or automation features about to go live assume quality levels you have not yet met. A monthly council plus a release-aligned checkpoint is the mid-market cadence that prevents governance from becoming a one-time post-project ritual.

Before AI Agents: Master-Data Readiness Checklist

AI agents do not fix bad master data—they amplify it. Practitioners in supply chain and operations put it bluntly: wrong BOMs, stale lead times, and dirty supplier records make autonomous workflows "confidently wrong at 10× speed." The same pattern shows up whenever an agent can execute, not just suggest: a human-assisted tool that proposes a bad vendor payment can be stopped; an agent that posts the payment from a duplicated bank master will repeat the error at scale. Industry commentary in 2025–2026 repeatedly links abandoned AI pilots to missing AI-ready data and weak governance rather than model capability alone.

For ERP teams, AI readiness is mostly master-data readiness in the domains agents will touch. If you plan demand agents, the item master (UoM, lead times, BOM links, status) must be unique and current. If you plan finance agents, customer and vendor tax IDs, payment terms, and CoA structure must be complete and stewards must own exceptions. If you plan service or sales agents, customer hierarchy and contact completeness matter more than a flashy model. IBM-linked industry analysis has put data accuracy among the top barriers CDOs cite for AI; treating "we'll clean data after the pilot" as a plan is how pilots never become production.

Run this checklist with the governance council before enabling any agent or Copilot feature that writes back to the ERP or takes operational action: (1) Named owner and steward for every domain the agent will read or write. (2) Completeness and uniqueness on natural keys above the targets in your scorecard for those domains. (3) Documented golden-record and survivorship rules for CRM/ERP identity. (4) Match rate ≥95% on the feeds the agent will use. (5) DCR workflow for high-risk creates/merges so the agent cannot invent a new vendor or GL account without a human gate. (6) Audit logging and a kill switch for agent write paths. (7) A pre-release quality gate on the ERP update calendar before turning new AI features on. For a broader assessment beyond ERP masters, use a dedicated AI data-readiness review that covers catalogs, lineage, and model evaluation—not only the customer and item tables.

Why Governance Programs Quietly Die (and How to Prevent It)

Most governance programs do not fail loudly; they erode. The council stops meeting, the scorecard stops being published, the DCR workflow gets bypassed because it is too slow, and within a year the data looks like it did before the migration. The failure modes are remarkably consistent across SMEs and worth naming explicitly so the governance council can watch for them. The first and most common is the no-named-owner problem: data is everyone's responsibility and therefore no one's, so duplicates accumulate and quality rules go unenforced. The fix is the operating model above—a named owner and steward per domain, with the council holding them accountable.

The second failure mode is IT-as-steward. IT is asked to maintain the customer master because they understand the system, but IT does not understand the business rules behind a tax-ID format or a credit-hold policy, so the work either does not get done or gets done mechanically without judgement. The fix is structural: IT is the Data Custodian (store, secure, operate), while a business SME is the Data Steward (define, monitor, remediate). The third failure mode is no metrics—governance runs on opinion and anecdote, so it loses every budget fight to revenue-generating projects. A monthly scorecard with trend lines makes quality visible and defensible. Gartner's observation that many organizations still do not measure data quality is the warning label on this failure mode.

The fourth and subtlest failure is scope creep into a multi-system MDM transformation before the single-instance basics work. An SME that cannot keep one ERP's customer master clean will not solve the problem by buying a dedicated MDM platform; it will simply import the same broken processes into more expensive software. The fifth, newer failure mode is AI-first, data-second: enabling Copilot or agent features against unowned masters so that automation multiplies duplicates, wrong lead times, and bad bank details faster than stewards can remediate. The discipline is to exhaust native validation, stewardship workflows, and a monthly scorecard first; treat dedicated MDM as a response to proven multi-system-of-record pain; and treat agent write-paths as a privilege that requires the readiness checklist above. Each of these failure modes is preventable with the operating model and cadence in this guide—the work is unglamorous and repetitive, which is exactly why most organisations skip it and exactly why the ones that do it compound an advantage over time.

Frequently asked questions