SAP Master Data Governance (MDG) explained
SAP Master Data Governance (MDG) is the SAP area that controls how the records every process shares — materials, business partners, cost centres, G/L accounts — are created, approved, cleaned and distributed. It is both a discipline that fixes who owns which field and an SAP application that encodes those decisions as change requests, rules and replication.
Which master data MDG governs
- Material (MDG-M) — basic data, purchasing, MRP, sales, accounting and costing views, each maintained by a different department: the reason the record needs a process rather than a single owner.
- Supplier and customer (MDG-S, MDG-C) — in S/4HANA both are the business partner, kept in sync with the customer and vendor master records by customer-vendor integration; where every Procurement and Sales process starts.
- Finance master data (MDG-F) — G/L accounts, cost centres, profit centres and the hierarchies FI and CO reporting reads.
- Custom objects — anything else a company decides needs the same treatment, modelled with MDG's flexible data model.
What MDG actually does
- 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.
- Consolidation and mass processing
- Matching, best-record building and mass change: the run that finds the same supplier entered twice and decides which fields survive.
- Data quality
- Validations, derivations and duplicate checks that stop a bad request at entry rather than downstream.
- 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 — MDG's seam with integration work.
What does an MDG consultant actually 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.
The one governed object that gets you hired
Most arrive from data they already maintained rather than from a course.
- 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 S/4HANA effect).
- 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).
The areas MDG borders
MDG defines none of these objects itself: Procurement and Sales supply the material, supplier and customer objects, Finance and Controlling the accounts and hierarchies, each with its own opinion about what a field means — the hard part is diplomacy, not configuration. Data & Analytics inherits the consequences, and GRC sits next door, because who may create a supplier and who may pay it is an audit question (which combinations work).
Related reading
- SAP Data & Analytics explained
From BW to SAP Analytics Cloud — turning process data into answers.
- SAP MM and Procurement explained
Purchasing, inventory and invoice verification — how a company buys.
- SAP FI explained: finance in SAP
General ledger, payables, receivables, assets and the close — the books of record.
- SAP terms explained: the working vocabulary
Transports, customizing, master data, IDocs, clean core — the working dialect, as practitioners use it.
Work with SAP?
Join to get your public SAP profile. Your city appears on the map once 5 professionals are mapped there.