SAP Master Data Governance (MDG) explained

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · facts checked against the SAP Help Portal and sap.com, October 2026

Master data governance is the set of rules, roles and approvals that keeps a company's shared master records, such as customers, suppliers, materials and accounts, correct and owned. SAP MDG (SAP Master Data Governance) is SAP's application for it: it decides who may create, change and approve those records, and each change travels through rules and approvers before other systems receive it.

As of October 2026, the current line is SAP Master Data Governance on SAP S/4HANA, documented with its domains and deployment options on the SAP Help Portal; the older MDG on SAP ERP line still serves landscapes on ECC until they convert.

What is master data governance in SAP?

Master data governance in SAP is the set of rules and roles that keep master records correct, complete and owned, with one owner per field. Master records are what a business transacts with: customers, suppliers, materials, accounts and cost centres, not the transactions themselves. A purchase order is created and closed; the supplier behind it outlives a decade of orders and is read by procurement, finance, tax, logistics and legal, each of which cares about different fields on the same record.

Governance answers the problem that follows from that: the record has many authors and no single owner, so it drifts. The same supplier is entered three times with three tax numbers, a material is created without the accounting view and blocks its first goods receipt, a cost centre is renamed after the reports that reference it have already been built. The discipline has a standard vocabulary — a data owner accountable for a domain, data stewards who do the daily work, a data custodian on the IT side, and a definition per field of who may request, who validates and who approves. SAP is one of several vendors selling master data management tooling for it; Informatica, Stibo and Reltio sell into the same conversation, and the choice usually turns on whether the record's centre of gravity is already inside SAP.

The failure that recurs everywhere is buying the tool before naming the owners. Software can route an approval; it cannot decide that the tax department, not procurement, rules on a supplier's VAT registration.

Is master data governance the same as master data management?

No. Governance is one part of master data management. SAP defines master data management, or MDM, as the discipline of creating one trusted master reference for important business data such as products, customers, assets and finance objects, so that processes, operations and reporting do not work from inconsistent versions. It names three pillars: data consolidation, data governance and data quality management. Governance is the pillar concerned with how a record is created and changed and who signs for it. Consolidation merges the records that already exist, and data quality management measures them against rules. The product name is narrower than the product: SAP Master Data Governance covers all three pillars, which is why a project can begin with consolidation and never touch a change request in its first year.

How does master data integration differ from governance?

Integration moves a record, and governance decides whether the record was fit to be moved. In SAP's description, master data integration distributes master data so that every application sees a harmonised view, and it does not change the quality of that data: it always distributes the record in its current state. A landscape with integration and no governance therefore spreads a duplicate supplier or a wrong tax number to every connected system faster than before. The order SAP recommends is to preserve the quality of the mission-critical records first and share them second. The same argument applies before a move to S/4HANA: SAP advises curating master data early, well before the implementation starts, because the more automated processes of the new system depend on it.

What is SAP MDG?

SAP MDG is the application that turns those decisions into a process: a change request replaces direct maintenance of the record, rules validate it at entry, a workflow carries it through the agreed approvers, and the approved record is replicated to every system that needs it. SAP describes the product on its SAP Master Data Governance page, which as of October 2026 presents it under SAP Business Data Cloud, as the governance layer of what SAP calls a business data fabric. It ships in three forms.

• SAP Master Data Governance on SAP S/4HANA — the current line, embedded in S/4HANA itself, on premise or in private cloud, and the one new projects choose. Since the 2023 release it offers a cloud-ready mode for business partner data, a Fiori-only way of configuring governance, consolidation and mass processing on one data model, which SAP recommends as the starting point for new business partner projects.
• SAP Master Data Governance on SAP ERP — the same application on the ECC stack, for landscapes that have not converted yet.
• SAP Master Data Governance, cloud edition — a software-as-a-service offering on SAP BTP, narrower in scope: central governance, consolidation and data quality management for business partner data, on core attributes only, with further domains listed on SAP's road map rather than delivered.

Which master data domains does MDG govern?

Three come delivered — material, business partner (with supplier and customer) and financials — and a company can model further objects of its own in the same framework; projects usually start one domain at a time.

Finance and treasury master data is split across those rows: the banks and counterparties a treasury deals with are business partners, G/L accounts and cost objects belong to the financials domain, and bank accounts themselves are maintained in Bank Account Management, part of cash management in S/4HANA, rather than in a delivered MDG domain — check the current scope on the Help Portal before promising otherwise.

What does MDG do, step by step?

Four things, in the order a record meets them: central governance, consolidation and mass processing, data quality, and replication.

Central governance

A change request replaces direct maintenance: a request type, a workflow with the agreed approval steps, and a record that goes active only when the last step signs. Until then the values sit in a staging area and no process can see them. The settings behind all of it live in MDG's own Customizing tree, transaction MDGIMG.

Consolidation and mass processing

Matching, best-record building and mass change: the run that finds the same supplier entered twice and decides, field by field, which source survives. It works on records already created, which is why it is the usual first delivery — it produces a measurable result without changing anyone's daily work.

Data quality

Validations, derivations and duplicate checks that stop a bad request at entry rather than downstream. Rules are written as decision tables rather than code where possible, so a data steward can read them; address and duplicate checking usually calls a reference directory rather than a hand-written comparison.

Replication

The Data Replication Framework sends the approved record to each receiving system, with key mapping so every system keeps its own numbers, and value mapping for the code lists that differ. Its models are set up in DRFIMG, and a manual send is DRFOUT — the first transaction anyone opens when a receiving system says it never got the record. This is MDG's seam with integration work.

Hub or co-deployed, or the cloud edition?

Co-deployed on S/4HANA for a single-ERP landscape, a hub for several ERPs that must share one golden record, and the cloud edition when the first need is consolidation and data quality rather than governed creation. The choice is argued in every project.

A second decision sits underneath: how the governed data is stored. Under the reuse model the active record lives in the operational tables the rest of the system already reads, so nothing has to be replicated locally and standard reporting works unchanged. Under the flexible model MDG holds the data in its own generated structures, which is what allows objects the ERP has no table for — including custom domains — and what finance objects use. Reuse is simpler and constrains you to what the standard object supports; flexible is open and makes you responsible for getting the data out again.

What does an MDG consultant do each week?

Most of it is change request types, workflow steps, validation rules and replication settings; which of them fills the week depends on the phase (project shapes):

• Design weeks — workshops ending in a field-ownership matrix: who requests, who validates, who approves, what may never change after creation.
• Build weeks — the data model and request screens built, and each of those settings configured.
• Data weeks — profiling legacy records, agreeing match rules, running consolidation, reconciling what arrived against what was sent.
• Test and cutover weeks — a requested material must reach the receiving system through every approval; then legacy maintenance freezes and the load runs.
• Hypercare and AMS weeks — rejected requests, stuck workflows, failed replications, and rules tuned after the fact.

Two arguments run underneath all of them. Approval depth: every extra step is a control the auditor likes and a day the business waits, and a process slow enough to be bypassed has produced worse data than no process at all. And rule strictness: a mandatory field that nobody can populate on day one turns into a placeholder value that silently defeats the rule.

Some of it stays outside the application however well it is configured. Governance stops new bad records but does not clean old ones, which is a consolidation project with its own budget; and the objects themselves belong to Procurement, Sales, Finance and Controlling, each with an opinion about what a field means. Data & Analytics inherits the consequences, and SAP GRC sits next door, because the right to create a payee is an audit question before it is a workflow step (which combinations work).

How do you get into MDG?

Most people get into MDG from data they already maintained rather than from a course, through one of four doors.

• From a master data team — the stewards inside a company that runs SAP; the key-user route with a governance flavour.
• From the area that owns the object — MM consultants who live in the material master, FI or CO consultants who own accounts and cost centres, SD consultants the customer record.
• From migration work — conversions where business partner clean-up, deduplication and load reconciliation are the assignment; the SAP data migration careers guide describes that stream, and the S/4HANA effect keeps it busy.
• From the technical side — workflow, rules and interface people who build the moving parts and want the decisions behind them.

What gets someone hired is one governed object taken end to end: modelled, requested, approved, validated, replicated. Interviews probe there — which fields belong to which approver, what happens when replication fails, when the reuse option is right and when the flexible model is (what interviews test). Being able to name the measures a governance programme reported — duplicate rate, completeness against the agreed field set, how long a request waits — separates someone who ran one from someone who watched it.