---
# === IDENTITY ===
id: business/erp-integration/mdm-implementation-patterns/2026
canonical_question: "How do MDM patterns differ - golden record vs registry vs coexistence - for ERP integration?"
aliases:
  - "What are the four MDM implementation styles and when to use each?"
  - "Registry vs consolidation vs coexistence vs centralized MDM for multi-ERP"
  - "Which MDM architecture pattern fits federated vs centralized ERP landscapes?"
  - "How to choose between golden record consolidation and registry MDM for ERP sync"
entity_type: erp_integration
domain: business > erp-integration > mdm-implementation-patterns
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "SAP Master Data Governance (MDG)"
    vendor: "SAP"
    version: "S/4HANA 2023+ / Cloud Edition"
    edition: "Enterprise"
    deployment: hybrid
    api_surface: "OData, RFC/BAPI, IDocs"
  - name: "Informatica MDM (IDMC Multidomain)"
    vendor: "Informatica"
    version: "Cloud-native IDMC 2025+"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, SIF (Services Integration Framework)"
  - name: "Reltio Connected Data Platform"
    vendor: "Reltio"
    version: "2025.1+"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, GraphQL, Streaming"
  - name: "Profisee MDM Platform"
    vendor: "Profisee"
    version: "2024.1+"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, SDK, FastApp UI"
  - name: "Stibo STEP MDM"
    vendor: "Stibo Systems"
    version: "2024+"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, IIEP (Inbound/Outbound Integration Endpoints)"

# === VERIFICATION ===
last_verified: 2026-03-07
confidence: 0.83
version: 1.0
first_published: 2026-03-07

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "Reltio FERN LLM-driven matching GA 2024; Informatica CLAIRE AI matching 2024; SAP MDG Cloud Edition BTP launch 2025"
  next_review: 2026-09-03
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Registry-style MDM does NOT update source systems — it is read-only. Agents must not recommend registry for operational data quality improvement"
  - "Consolidation-style MDM has 4-24h latency for golden records — cannot be used for real-time operational lookups"
  - "Coexistence-style requires conflict resolution logic BEFORE go-live — race conditions between hub and source systems corrupt golden records"
  - "Centralized MDM requires all master data creation to flow through the hub — existing self-service workflows in ERPs must be re-engineered"
  - "SAP MDG is tightly coupled to the SAP ecosystem — integrating non-SAP sources requires middleware (CPI, Boomi, MuleSoft)"
  - "Survivorship rules must be defined per-attribute, not per-record — record-level survivorship loses valuable data from non-winning sources"
  - "Match key design determines merge quality — poor match keys cause both false positives (over-merge destroying distinct records) and false negatives (missed duplicates)"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs implementation-level MDM code and API details for a specific platform"
    use_instead: "business/erp-integration/master-data-management-erp/2026"
  - condition: "User needs product information management (PIM) not master data governance"
    use_instead: "PIM solutions (Akeneo, Salsify, inRiver) — different domain"
  - condition: "User needs one-time data migration between ERPs, not ongoing MDM"
    use_instead: "Data migration playbooks — ETL/ELT patterns with reconciliation"

# === AGENT HINTS ===
inputs_needed:
  - key: mdm_style
    question: "Which MDM architecture pattern are you evaluating?"
    type: choice
    options:
      - "registry (read-only cross-reference, data stays in ERPs)"
      - "consolidation (golden record for analytics, no writeback)"
      - "coexistence (bidirectional sync, golden records + source systems)"
      - "centralized (hub is sole system of record)"
      - "not sure — need decision framework"
  - key: org_structure
    question: "What is your organizational structure?"
    type: choice
    options:
      - "centralized (single IT, uniform processes)"
      - "federated (business units with own ERPs and processes)"
      - "hybrid (central standards, local execution)"
  - key: erp_count
    question: "How many ERP systems are in scope?"
    type: choice
    options:
      - "1 (single ERP + satellite apps)"
      - "2-3 ERPs (common M&A scenario)"
      - "4+ ERPs (large enterprise / conglomerate)"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/mdm-implementation-patterns/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-07)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to:
    - id: "business/erp-integration/master-data-management-erp/2026"
      label: "MDM implementation details — golden record, survivorship rules, API code"
    - id: "business/erp-integration/change-data-capture-erp/2026"
      label: "CDC patterns for real-time data sync between ERPs"
  solves: []
  alternative_to: []
  often_confused_with:
    - id: "business/erp-integration/master-data-management-erp/2026"
      label: "General MDM card covers implementation; this card covers architecture pattern selection"

# === SOURCES ===
sources:
  - id: src1
    title: "Master Data Management Implementation Styles, Explained"
    author: Profisee
    url: https://profisee.com/blog/master-data-management-implementation-styles/
    type: technical_blog
    published: 2025-06-15
    reliability: high
  - id: src2
    title: "4 Common Master Data Management Implementation Styles"
    author: Stibo Systems
    url: https://www.stibosystems.com/blog/4-common-master-data-management-implementation-styles
    type: technical_blog
    published: 2025-03-10
    reliability: high
  - id: src3
    title: "MDM Integration Architecture: Patterns & Best Practices"
    author: Informatica
    url: https://www.informatica.com/resources/articles/mdm-integration-architecture.html
    type: technical_blog
    published: 2025-08-20
    reliability: high
  - id: src4
    title: "What Are MDM Implementation Styles?"
    author: Reltio
    url: https://www.reltio.com/glossary/master-data-management/what-are-mdm-implementation-styles/
    type: technical_blog
    published: 2025-04-12
    reliability: high
  - id: src5
    title: "4 Critical Mistakes to Avoid During Your Master Data Management Implementation"
    author: Profisee
    url: https://profisee.com/blog/4-critical-mistakes-to-avoid-during-your-master-data-management-implementation/
    type: technical_blog
    published: 2025-05-20
    reliability: high
  - id: src6
    title: "Common Master Data Management (MDM) Pitfalls"
    author: Dataversity
    url: https://www.dataversity.net/common-master-data-management-mdm-pitfalls/
    type: industry_report
    published: 2025-02-10
    reliability: moderate_high
  - id: src7
    title: "SAP Master Data Governance — Innovations with S/4HANA Cloud Private Edition 2025"
    author: SAP
    url: https://community.sap.com/t5/technology-blog-posts-by-sap/innovations-in-master-data-governance-with-sap-s-4hana-cloud-private/ba-p/14146957
    type: vendor_release_notes
    published: 2025-09-15
    reliability: authoritative
---

# MDM Implementation Patterns: Registry vs Consolidation vs Coexistence vs Centralized

## TL;DR

- **Bottom line**: Four MDM styles exist — Registry (read-only cross-reference), Consolidation (golden record for analytics), Coexistence (bidirectional sync), and Centralized (hub as sole system of record). Most enterprises start with Consolidation and evolve to Coexistence as governance matures. [src1, src2]
- **Key limit**: Consolidation hubs have 4-24h refresh latency and cannot serve real-time operational lookups; Coexistence requires conflict resolution logic before go-live or race conditions corrupt golden records. [src3]
- **Watch out for**: Treating MDM as a one-time ETL project instead of an ongoing governance program — Gartner projected 75% of MDM programs fail to meet business objectives when governance is absent. [src6]
- **Best for**: Multi-ERP landscapes (2+ ERPs from M&A or organic growth) where customer, vendor, product, or chart-of-accounts data is fragmented across systems. [src1]
- **Decision shortcut**: Federated org with autonomous BUs? Start with Registry or Consolidation. Centralized org with uniform processes? Go straight to Coexistence or Centralized. [src2, src4]

## System Profile

This card compares MDM architecture patterns — not specific platform implementations. The patterns are vendor-agnostic, but implementation choices are shaped by which MDM platform you select. The five major platforms are listed below with their natural fit to each pattern. SAP MDG is unique in that it is tightly coupled to the SAP ecosystem and acts as a centralized/coexistence hub natively within S/4HANA. Informatica and Reltio are vendor-neutral hubs that connect to any ERP. Profisee offers the fastest deployment for Microsoft-centric shops. Stibo STEP is strongest for product data (PIM + MDM combined). [src1, src2, src3, src4]

| Platform | Vendor | Best-Fit Style | Deployment | Primary API | Natural Strength |
|---|---|---|---|---|---|
| **SAP MDG** | SAP | Centralized / Coexistence | Hybrid | OData, RFC/BAPI | Deep SAP integration, workflow governance |
| **Informatica IDMC** | Informatica | Consolidation / Coexistence | Cloud | REST, SIF | Multi-domain, 300+ connectors, CLAIRE AI matching |
| **Reltio CDP** | Reltio | Coexistence / Consolidation | Cloud (SaaS only) | REST, GraphQL | Fast deployment (<90 days), real-time graph |
| **Profisee** | Profisee | Coexistence / Centralized | Cloud / On-Prem | REST, SDK | Microsoft ecosystem (Azure), FastApp UI |
| **Stibo STEP** | Stibo Systems | Centralized / Coexistence | Cloud | REST, IIEP | PIM + MDM combined, product data mastery |

## API Surfaces & Capabilities

MDM platforms expose APIs for three distinct purposes: data ingestion (loading source records), golden record retrieval (consuming mastered data), and match/merge operations (triggering deduplication). The pattern you choose determines which APIs are critical. [src3]

| API Purpose | Registry | Consolidation | Coexistence | Centralized |
|---|---|---|---|---|
| **Inbound ingestion** | Batch ETL | Batch ETL/ELT | Real-time REST + Batch | Real-time REST only |
| **Golden record read** | Cross-reference lookup | Batch export, BI query | REST/GraphQL real-time | REST/GraphQL real-time |
| **Writeback to sources** | None | None | Bidirectional REST/CDC | Publish (one-way out) |
| **Match/merge trigger** | Automated on ingest | Automated + steward review | Automated + real-time | Automated + workflow approval |
| **Event notifications** | None | None | CDC / webhooks / Kafka | Kafka / event bus |
| **Typical latency** | N/A (read-only) | 4-24h batch | <1s to <5min | <1s |

## Rate Limits & Quotas

### Platform API Limits

| Platform | API Call Limit | Bulk Import Limit | Concurrent Connections | Notes |
|---|---|---|---|---|
| SAP MDG | SAP BTP rate limits (varies by plan) | IDoc batch: 10K records/packet | Configurable per dialog process | Limits shared with S/4HANA application layer |
| Informatica IDMC | 100 API calls/sec (default) | SIF batch: 50K records/batch | 20 concurrent REST sessions | Elastic scaling available on IDMC Cloud |
| Reltio | 500 req/sec per tenant (default) | Bulk load: 100K entities/file | Configurable | GraphQL queries count same as REST |
| Profisee | No published hard limit | REST bulk: 10K records/batch | Azure-tier dependent | Scales with Azure App Service plan |
| Stibo STEP | IIEP throughput: ~5K records/min | Batch import: configurable | JVM-bound (heap dependent) | On-prem deployments are self-managed |

[src3, src7]

### Match/Merge Processing Limits

| Operation | Typical Throughput | Bottleneck | Mitigation |
|---|---|---|---|
| Initial data load & match | 50K-500K records/hour | Match algorithm complexity | Pre-cleanse data, reduce match rule count for initial load |
| Incremental match (daily) | 1K-50K records/hour | Duplicate candidate generation | Use blocking keys to narrow match scope |
| Manual steward review | 50-200 records/day/steward | Human throughput | Automate high-confidence merges (>95% score), route only ambiguous cases |
| Survivorship rule execution | Negligible overhead | N/A | Survivorship runs inline with merge — no separate limit |

[src3]

## Authentication

| Platform | Auth Method | Token Type | Lifetime | Notes |
|---|---|---|---|---|
| SAP MDG | SAP BTP OAuth 2.0 / X.509 certificate | Bearer token | Configurable (default 12h) | Communication arrangements in BTP cockpit |
| Informatica IDMC | OAuth 2.0 client credentials | Bearer token | 1h (refreshable) | Separate tokens for REST API vs SIF |
| Reltio | OAuth 2.0 client credentials | Bearer token | 1h | Tenant-scoped tokens |
| Profisee | Azure AD / OAuth 2.0 | Bearer token | 1h (configurable) | Azure AD app registration required |
| Stibo STEP | Basic auth / OAuth 2.0 | Session or bearer | Session-based or 1h | Certificate auth for IIEP |

[src3, src7]

### Authentication Gotchas

- SAP MDG API access requires a Communication Arrangement in BTP — the OData endpoint is not exposed without explicit configuration, unlike standard S/4HANA APIs. [src7]
- Informatica SIF (Services Integration Framework) uses a separate authentication mechanism from the IDMC REST API — do not assume REST API tokens work for SIF calls. [src3]
- Reltio tokens are tenant-scoped — multi-tenant deployments need separate OAuth clients per tenant, which complicates centralized integration middleware. [src4]

## Constraints
<!-- Agents: read this section before recommending any MDM pattern.
     These are hard constraints that must not be violated. -->

- **Registry does NOT write back**: It provides a cross-reference index only. Any recommendation to "use registry to improve source system data quality" is incorrect — registry reads data, it does not modify it. [src1, src2]
- **Consolidation is not real-time**: Typical 4-24h refresh cycles. Recommending consolidation for real-time operational lookups will fail. [src1, src3]
- **Coexistence requires conflict resolution before go-live**: Without predefined rules for handling concurrent updates from hub and source systems, race conditions will corrupt golden records. [src1, src3]
- **Centralized MDM blocks self-service**: All master data creation must go through the hub. Existing business processes that create customers/vendors directly in ERPs must be re-engineered. [src2, src4]
- **SAP MDG is SAP-coupled**: Integrating non-SAP data sources into SAP MDG requires middleware (SAP CPI, MuleSoft, Boomi). SAP MDG cannot natively consume REST APIs from non-SAP systems. [src7]
- **Match key design is irreversible in production**: Changing match keys on a hub with millions of records triggers a full rematch, potentially unmerging existing golden records. Plan match keys before initial load. [src3]
- **Survivorship per-attribute, not per-record**: Defining survivorship at the record level (entire winning record) discards correct attribute values from non-winning sources. Always define survivorship rules per individual attribute. [src3]

## Integration Pattern Decision Tree

```
START — Organization needs cross-ERP master data consistency
├── How many ERP systems?
│   ├── 1 ERP + satellite apps
│   │   ├── Data governance within single ERP? → Use native MDG (SAP MDG, Oracle DRM)
│   │   └── Need 360-degree view for analytics? → CONSOLIDATION (lowest cost)
│   └── 2+ ERPs (multi-vendor or M&A)
│       ├── Organizational structure?
│       │   ├── FEDERATED (autonomous BUs, own ERPs, own processes)
│       │   │   ├── Need cross-BU reporting only? → REGISTRY
│       │   │   ├── Need harmonized analytics? → CONSOLIDATION
│       │   │   └── Need operational data consistency? → COEXISTENCE
│       │   ├── CENTRALIZED (single IT, uniform processes)
│       │   │   ├── Greenfield / ERP consolidation? → CENTRALIZED
│       │   │   └── Brownfield / phased harmonization? → COEXISTENCE
│       │   └── HYBRID (central standards, local execution)
│       │       └── → COEXISTENCE (most common choice)
│       └── Data governance maturity?
│           ├── LOW (no stewards, no data ownership) → Start with CONSOLIDATION
│           │   └── Evolve to COEXISTENCE as governance matures (12-18 months)
│           ├── MEDIUM (some stewards, partial ownership) → COEXISTENCE
│           └── HIGH (dedicated stewards, clear ownership) → CENTRALIZED or COEXISTENCE
├── Data domains?
│   ├── Customer/Account → Highest ROI domain — start here
│   ├── Vendor/Supplier → Second priority — compliance benefits
│   ├── Product/Material → Consider PIM + MDM (Stibo STEP, Informatica PIM)
│   ├── Chart of Accounts → Financial consolidation — often SAP MDG or Oracle DRM
│   └── Employee → HR systems (Workday, SuccessFactors) often already centralized
└── Budget and timeline?
    ├── < $500K, < 6 months → Registry or Consolidation
    ├── $500K-$2M, 6-12 months → Coexistence (single domain)
    └── > $2M, 12-24 months → Centralized or multi-domain Coexistence
```

## Quick Reference

| Dimension | Registry | Consolidation | Coexistence | Centralized |
|---|---|---|---|---|
| **Data ownership** | Source systems | Source systems (hub is read-only copy) | Shared (hub + sources) | MDM hub exclusively |
| **Golden record location** | Virtual (assembled on query) | Hub (batch-created) | Hub (real-time synced) | Hub (sole copy) |
| **Sync pattern** | None (read-only index) | One-way: sources to hub | Bidirectional | One-way: hub to sources |
| **Writeback to ERPs** | No | No | Yes (real-time or near-real-time) | Yes (publish/subscribe) |
| **Typical latency** | N/A | 4-24 hours | Seconds to minutes | Seconds |
| **Data quality improvement** | None (reports dupes, does not fix) | Hub only (source data unchanged) | Both hub and sources | Hub (sources consume clean data) |
| **Implementation complexity** | Low | Medium | High | Very high |
| **Implementation cost** | $100K-$300K | $200K-$800K | $500K-$2M | $1M-$5M+ |
| **Implementation timeline** | 2-4 months | 3-6 months | 6-12 months | 12-24 months |
| **Governance maturity required** | Low | Low-Medium | Medium-High | High |
| **Org structure fit** | Federated, decentralized | Any (analytics-first) | Hybrid, maturing | Centralized, single-standard |
| **# of ERPs sweet spot** | 3+ (many sources, read-only aggregation) | 2-5 (analytics consolidation) | 2-4 (operational sync) | 1-2 (single authority) |
| **Best for** | Reporting, compliance, duplicate identification | BI, data warehouse, customer 360 analytics | Operational consistency across ERPs | Greenfield, ERP consolidation programs |
| **Not suitable for** | Operational data quality, writeback | Real-time lookups, transactional use | Low-governance orgs, budget-constrained | Federated orgs, phased adoption |

[src1, src2, src3, src4]

## Step-by-Step Integration Guide

### 1. Assess current state and define data domains

Map all master data domains (customer, vendor, product, chart of accounts, employee) across every ERP and satellite system. Document who creates each entity, how often, and what the authoritative source is today. [src5, src6]

```text
Domain Assessment Template:
┌─────────────────┬───────────────┬──────────────┬─────────────┬────────────────┐
│ Data Domain     │ Systems       │ Record Count │ Create Rate │ Current Source  │
│                 │               │              │ (per month) │ of Truth       │
├─────────────────┼───────────────┼──────────────┼─────────────┼────────────────┤
│ Customer        │ SF, SAP, NS   │ 2.3M total   │ 5K          │ Salesforce     │
│ Vendor/Supplier │ SAP, Oracle   │ 180K total   │ 200         │ SAP            │
│ Product         │ SAP, PIM, WMS │ 500K total   │ 1K          │ SAP MM         │
│ Chart of Acct   │ SAP, Oracle   │ 12K total    │ 50          │ SAP FI         │
│ Employee        │ Workday, SAP  │ 45K total    │ 300         │ Workday        │
└─────────────────┴───────────────┴──────────────┴─────────────┴────────────────┘
```

**Verify**: Count total unique entities across systems → if cross-system overlap > 30%, MDM ROI is likely positive.

### 2. Select MDM pattern using the decision tree

Use the decision tree above. Key factors: org structure (federated vs centralized), number of ERPs, data governance maturity, and budget/timeline. [src1, src2]

```text
Scoring Matrix (weight each 1-5, multiply by factor weight):
┌───────────────────────────┬────────┬──────────┬──────────┬──────────────┐
│ Factor (weight)           │Registry│Consolid. │Coexist.  │Centralized   │
├───────────────────────────┼────────┼──────────┼──────────┼──────────────┤
│ Real-time operational (3) │   1    │    1     │    4     │      5       │
│ Analytics/reporting (2)   │   3    │    5     │    4     │      4       │
│ Low disruption (3)        │   5    │    4     │    2     │      1       │
│ Data quality impact (2)   │   1    │    3     │    4     │      5       │
│ Governance maturity (2)   │   5    │    4     │    2     │      1       │
│ Budget friendliness (2)   │   5    │    4     │    2     │      1       │
├───────────────────────────┼────────┼──────────┼──────────┼──────────────┤
│ Weighted total            │  43    │   45     │   40     │     37       │
└───────────────────────────┴────────┴──────────┴──────────┴──────────────┘
(Higher = better fit for risk-averse, phased adoption organizations)
```

**Verify**: Confirm pattern selection with stakeholders before proceeding to platform selection.

### 3. Define match rules and survivorship strategy

Design match keys per data domain. Match keys determine which records are candidates for merging. Survivorship rules determine which attribute value wins when merging. [src3]

```text
Match Rule Design:
Domain: Customer
├── Match Key 1 (deterministic): Exact(TaxID) + Exact(Country)
│   → Confidence: 100% → Auto-merge
├── Match Key 2 (fuzzy): Jaro-Winkler(CompanyName, 0.85) + Exact(PostalCode)
│   → Confidence: 85-99% → Auto-merge with steward notification
├── Match Key 3 (fuzzy): Soundex(CompanyName) + Levenshtein(Address, 3)
│   → Confidence: 70-84% → Manual steward review
└── Below 70% → No match (separate records)

Survivorship Rules (per attribute):
┌──────────────┬──────────────────────┬──────────────────────────────┐
│ Attribute    │ Survivorship Rule    │ Rationale                    │
├──────────────┼──────────────────────┼──────────────────────────────┤
│ Legal Name   │ Most trusted source  │ ERP > CRM (ERP has contracts)│
│ Email        │ Most recent          │ Email addresses change often │
│ Phone        │ Most complete        │ Pick non-null, longest value │
│ Address      │ Most trusted source  │ ERP for billing, CRM for ship│
│ Tax ID       │ Most trusted source  │ ERP (validated at PO creation)│
│ Credit Limit │ Highest authority    │ Finance system always wins   │
│ Industry     │ Most recent          │ CRM updated by sales reps    │
└──────────────┴──────────────────────┴──────────────────────────────┘
```

**Verify**: Test match rules against a sample of 10K records → false positive rate < 2%, false negative rate < 5%.

### 4. Configure data flow and sync patterns

Set up integration pipelines based on selected pattern. For coexistence: implement CDC listeners on source ERPs, conflict detection in the hub, and writeback channels. [src3]

```python
# Coexistence pattern: conflict detection pseudocode
# Input:  Incoming change from source ERP + current golden record
# Output: Resolved golden record or escalation to steward

def resolve_conflict(incoming_change, golden_record, survivorship_rules):
    conflicts = []
    for attr in incoming_change.changed_attributes:
        golden_val = getattr(golden_record, attr)
        incoming_val = getattr(incoming_change, attr)

        if golden_val != incoming_val:
            rule = survivorship_rules.get(attr)
            if rule.type == "most_trusted_source":
                winner = rule.evaluate_trust(
                    golden_record.source, incoming_change.source
                )
            elif rule.type == "most_recent":
                winner = max(golden_record, incoming_change,
                           key=lambda r: r.last_modified)
            elif rule.type == "most_complete":
                winner = max(golden_record, incoming_change,
                           key=lambda r: len(str(getattr(r, attr) or "")))
            else:
                # Unknown rule type — escalate to steward
                conflicts.append({
                    "attribute": attr,
                    "golden_value": golden_val,
                    "incoming_value": incoming_val,
                    "source": incoming_change.source
                })
                continue

            if winner == incoming_change:
                setattr(golden_record, attr, incoming_val)
                golden_record.audit_log.append({
                    "attr": attr, "old": golden_val,
                    "new": incoming_val, "rule": rule.type,
                    "source": incoming_change.source,
                    "timestamp": datetime.utcnow()
                })

    if conflicts:
        create_steward_task(golden_record.id, conflicts)

    return golden_record
```

**Verify**: Run conflict resolution against historical change log → unresolved conflicts < 10% of total changes.

## Code Examples

### Python: Informatica MDM REST API — Search and Match

```python
# Input:  Customer record attributes (name, address, tax_id)
# Output: Matched golden record ID and confidence score

import requests

INFORMATICA_BASE = "https://your-org.informatica.com/mdm/api/v2"
TOKEN = "Bearer <your_oauth_token>"

def search_and_match(customer_data):
    """Search for matching golden records in Informatica MDM."""
    headers = {
        "Authorization": TOKEN,
        "Content-Type": "application/json"
    }

    # Step 1: Search for potential matches
    search_payload = {
        "searchType": "MATCH",
        "recordData": {
            "companyName": customer_data["name"],
            "postalCode": customer_data["postal_code"],
            "country": customer_data["country"]
        },
        "matchRuleSet": "CustomerMatchRules",
        "maxResults": 10
    }

    resp = requests.post(
        f"{INFORMATICA_BASE}/match/Customer",
        json=search_payload,
        headers=headers,
        timeout=30
    )
    resp.raise_for_status()

    matches = resp.json().get("matchedRecords", [])

    if not matches:
        return {"status": "no_match", "action": "create_new_golden_record"}

    best_match = max(matches, key=lambda m: m["matchScore"])

    if best_match["matchScore"] >= 95:
        return {
            "status": "auto_merge",
            "golden_record_id": best_match["recordId"],
            "confidence": best_match["matchScore"]
        }
    elif best_match["matchScore"] >= 70:
        return {
            "status": "steward_review",
            "golden_record_id": best_match["recordId"],
            "confidence": best_match["matchScore"]
        }
    else:
        return {"status": "no_match", "action": "create_new_golden_record"}
```

### cURL: SAP MDG — Read Master Data via OData

```bash
# Input:  SAP MDG OData endpoint, OAuth token, business partner ID
# Output: Master data record in JSON format

# Step 1: Get OAuth token from SAP BTP
curl -X POST "https://your-btp.authentication.eu10.hana.ondemand.com/oauth/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&client_id=YOUR_CLIENT_ID&client_secret=YOUR_SECRET"

# Step 2: Read Business Partner master data from MDG
curl -X GET "https://your-s4hana.sap/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1000042')" \
  -H "Authorization: Bearer <token_from_step_1>" \
  -H "Accept: application/json" \
  -H "sap-client: 100"

# Expected response shape:
# {
#   "d": {
#     "BusinessPartner": "1000042",
#     "BusinessPartnerFullName": "Acme Corporation",
#     "BusinessPartnerCategory": "2",
#     "TaxNumber1": "DE123456789",
#     ...
#   }
# }
```

## Data Mapping

### Master Data Domain Mapping Across ERPs

| Data Domain | SAP S/4HANA | Oracle ERP Cloud | Salesforce | NetSuite | Workday |
|---|---|---|---|---|---|
| **Customer** | Business Partner (BP) | Customer (HZ_PARTIES) | Account | Customer | N/A |
| **Vendor** | Business Partner (BP, role FLVN01) | Supplier (AP_SUPPLIERS) | N/A | Vendor | Supplier |
| **Product** | Material (MARA/MARC) | Item (EGP_SYSTEM_ITEMS) | Product2 | Item | N/A |
| **Employee** | Personnel (PA) / Business Partner | Worker (PER_ALL_PEOPLE) | Contact (Employee) | Employee | Worker |
| **Chart of Accounts** | GL Account (SKA1/SKB1) | GL Account (GL_CODE_COMBINATIONS) | N/A | Account (chart) | Ledger Account |

### Data Type Gotchas

- **Name fields**: SAP stores names in structured fields (NAME1-NAME4, max 35 chars each); Salesforce uses Name (max 255 chars, single field). MDM merge must concatenate or truncate carefully. [src3]
- **Address format**: SAP uses structured address (STRAS, ORT01, PSTLZ, LAND1); Salesforce uses BillingStreet (free text). Country codes differ — SAP uses 2-char ISO in some fields, 3-char in others. [src3]
- **Currency representation**: SAP stores amounts in smallest currency unit (cents) with separate currency key; Oracle stores as decimal with embedded currency. MDM survivorship rules must normalize before comparison. [src3]
- **Date/time zones**: SAP stores in user timezone; Salesforce in UTC; NetSuite in company timezone; Oracle ERP Cloud in UTC. Cross-system timestamp comparison without timezone normalization leads to incorrect "most recent" survivorship. [src3]
- **Tax ID format**: Varies by country (US: EIN 9 digits, DE: USt-IdNr 11 chars, UK: VAT 9-12 digits). MDM must normalize format before match key generation or matching fails. [src3]

## Error Handling & Failure Points

### Common Error Scenarios

| Error | MDM Style | Cause | Resolution |
|---|---|---|---|
| **False positive merge** | All | Overly broad match keys (e.g., name + city only) | Add discriminating attributes (tax ID, DUNS, phone). Implement unmerge capability |
| **False negative (missed dupe)** | All | Overly strict match keys, data quality issues | Add fuzzy matching (Jaro-Winkler, Soundex). Pre-cleanse and standardize before matching |
| **Survivorship conflict deadlock** | Coexistence, Centralized | Two sources update same attribute simultaneously with equal trust scores | Add timestamp tiebreaker to survivorship rules. Last-write-wins for equal-trust sources |
| **Circular sync loop** | Coexistence | Hub writes back to ERP, ERP CDC detects change, sends back to hub | Tag changes with origin (hub vs source). Ignore hub-originated changes in CDC listener |
| **Golden record corruption** | Coexistence, Centralized | Race condition between hub merge and incoming source update | Implement optimistic locking on golden records. Use version numbers for conflict detection |
| **Steward queue overflow** | All | Too many ambiguous matches routed to manual review | Tighten auto-merge threshold. Add secondary match rules to resolve ambiguity automatically |

[src3, src5]

### Failure Points in Production

- **Initial data load overwhelms match engine**: Loading millions of records triggers quadratic match comparison (N x N candidates). Fix: `Use blocking keys to partition match scope. Load in batches of 50K. Run match within blocks, not across all records.` [src3]
- **Survivorship rules produce "Frankenstein records"**: Different attributes survive from different sources, creating records that never existed in any source system. Fix: `Add cross-attribute consistency rules (e.g., if address country survives from Source A, city and postal code must also come from Source A).` [src3]
- **CDC lag causes stale golden records in coexistence**: Source ERP commits change, but CDC event is delayed (batch CDC or replication lag), causing golden record to serve stale data to downstream consumers. Fix: `Use streaming CDC (Debezium, Oracle GoldenGate, SAP SLT) instead of polling. Set max acceptable lag SLA and alert on breach.` [src3]
- **Match key change triggers mass unmerge**: Modifying match rules on a production hub with millions of records triggers a full rematch, potentially splitting existing golden records. Fix: `Never change match keys on production without a parallel run. Run new keys against a snapshot, compare results, get steward approval before cutover.` [src3]

## Anti-Patterns

### Wrong: Treating MDM as an ETL project

```text
// BAD — "We'll just deduplicate with an ETL job"
1. Extract customer data from 3 ERPs nightly
2. Run SQL DISTINCT on name + address
3. Load "deduplicated" records into data warehouse
4. Declare "MDM done"

Problems:
- No match/merge engine → misses fuzzy duplicates ("Acme Corp" vs "ACME Corporation")
- No survivorship rules → arbitrary record wins (usually first loaded)
- No writeback → source ERPs still create duplicates daily
- No governance → data quality degrades immediately after load
- No golden record ID → no cross-reference for downstream systems
```

### Correct: Implement proper MDM with match engine and governance

```text
// GOOD — proper MDM implementation
1. Define match rules: deterministic (Tax ID) + fuzzy (name similarity > 0.85)
2. Define survivorship: per-attribute rules based on source trust ranking
3. Load into MDM hub with match/merge engine
4. Auto-merge high-confidence matches, route ambiguous to stewards
5. Publish golden records with stable cross-reference IDs
6. Continuous: source systems send CDC events → hub updates golden record → writeback
7. Governance: data stewards review exceptions, refine rules quarterly
```

[src5, src6]

### Wrong: Ignoring data stewardship ("fully automated MDM")

```text
// BAD — "AI will handle all matching, no stewards needed"
1. Deploy MDM platform with default match rules
2. Set auto-merge threshold to 60% confidence
3. No steward queue, no exception handling
4. Trust the algorithm completely

Problems:
- 60% threshold causes mass false merges (separate companies merged)
- No human review for edge cases (parent company vs subsidiary)
- Unmerge requests pile up with no one to process them
- Legal entities merged that should remain separate for compliance
```

### Correct: Tiered automation with steward escalation

```text
// GOOD — tiered approach
1. Auto-merge: confidence >= 95% (exact Tax ID match)
2. Auto-merge with notification: 85-94% (steward can review retroactively)
3. Manual steward review: 70-84% (steward approves/rejects within SLA)
4. No match: < 70% (separate records)
5. Weekly steward review of auto-merged records (spot-check quality)
6. Quarterly match rule tuning based on false positive/negative rates
```

[src5, src6]

### Wrong: Boiling the ocean — all domains, all systems, day one

```text
// BAD — "Let's master all data domains across all 7 ERPs simultaneously"
1. Scope: Customer + Vendor + Product + Employee + CoA across 7 ERPs
2. Timeline: 6 months
3. Budget: $800K
4. Result: 18 months later, $3M spent, 2 domains partially live,
   project sponsor replaced, organizational trust in MDM destroyed
```

### Correct: Start small, prove value, expand

```text
// GOOD — phased domain rollout
Phase 1 (months 1-4): Customer domain, 2 highest-volume ERPs
  → Deliverable: Golden customer records, duplicate rate reduction metric
  → Budget: $300K
Phase 2 (months 5-8): Add vendor domain, same 2 ERPs
  → Deliverable: Vendor deduplication, compliance reporting
Phase 3 (months 9-14): Expand customer + vendor to remaining ERPs
Phase 4 (months 15-20): Add product domain
Each phase: Measurable ROI before next phase funding approved
```

[src5, src6]

## Common Pitfalls

- **"MDM = technology project"**: Organizations buy an MDM platform expecting it to solve data quality without governance changes. Fix: `Allocate 40% of MDM budget to people and process (data stewards, governance council, data ownership model). Technology is only 30-40% of total cost.` [src5, src6]
- **No executive sponsor with operational authority**: IT-driven MDM projects lack business buy-in and die at first budget cut. Fix: `Secure a VP/Director-level sponsor from an operational business unit (sales, supply chain, finance) — not just IT. Frame MDM in revenue/cost terms, not data quality terms.` [src5]
- **Mismatched style to org structure**: Deploying centralized MDM in a federated organization triggers political resistance from autonomous business units. Fix: `Use the decision tree above. Federated orgs must start with consolidation or coexistence — never centralized.` [src1, src2]
- **Match rules designed by technologists without business context**: IT teams create match keys on obvious fields (name, address) but miss business rules (e.g., same Tax ID but different divisions should NOT merge). Fix: `Involve business data owners in match rule design. Test rules against real data with business users validating merge candidates.` [src5]
- **Ignoring the "Day 2" problem**: MDM goes live with clean data, but no process prevents new duplicates from being created in source systems. Fix: `Implement duplicate-prevention at the source: real-time duplicate check API called before new record creation in each ERP.` [src3]
- **Over-investing in initial data quality before MDM**: Spending 12 months cleansing source data before loading into MDM delays value realization. Fix: `Load messy data into MDM, let the match/merge engine handle deduplication. Clean iteratively with steward review. Perfect is the enemy of good.` [src6]

## Diagnostic Commands

```bash
# Check golden record duplicate rate (Informatica MDM REST API)
curl -X GET "$INFORMATICA_BASE/mdm/api/v2/statistics/Customer/duplicates" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json"
# Expected: { "totalRecords": 2300000, "duplicateClusters": 15000, "duplicateRate": "0.65%" }

# Check match queue depth (steward tasks pending)
curl -X GET "$INFORMATICA_BASE/mdm/api/v2/tasks?status=PENDING&type=MERGE_REVIEW" \
  -H "Authorization: Bearer $TOKEN"
# Expected: { "totalPending": 342, "oldestTask": "2026-02-28" }

# SAP MDG: Check change request status
curl -X GET "$SAP_HOST/sap/opu/odata/sap/API_MASTERDATA_GOVERNANCE_SRV/ChangeRequests?\$filter=Status eq '01'" \
  -H "Authorization: Bearer $SAP_TOKEN" \
  -H "Accept: application/json"

# Reltio: Check entity resolution statistics
curl -X GET "https://your-tenant.reltio.com/reltio/api/entities/_stats" \
  -H "Authorization: Bearer $RELTIO_TOKEN"
# Expected: { "totalEntities": 1500000, "mergedEntities": 120000, "crosswalks": 3200000 }

# Check CDC replication lag (for coexistence pattern)
# Debezium example — check connector lag
curl -X GET "http://kafka-connect:8083/connectors/erp-cdc/status" | jq '.tasks[0].state'
# Expected: "RUNNING" with lag < 30 seconds
```

## Version History & Compatibility

| Platform | Current Version | Previous | Breaking Changes | Notes |
|---|---|---|---|---|
| SAP MDG | S/4HANA 2025 (Cloud Edition on BTP) | S/4HANA 2023 | Cloud-ready mode as default architecture | Classic mode still supported but not recommended for new deployments |
| Informatica IDMC | 2025.2 (cloud-native) | 10.5 (on-prem) | SIF API v3 replaces v2 for match operations | v2 SIF deprecated July 2026 |
| Reltio | 2025.1 | 2024.2 | FERN LLM-matching replaces legacy ML model | Opt-in for existing tenants, default for new |
| Profisee | 2024.1 | 2023.2 | REST API v2 replaces v1 | v1 sunset December 2025 |
| Stibo STEP | 2024 R2 | 2024 R1 | IIEP v3 deprecates v2 outbound endpoints | Migration tool provided |

[src7]

### Deprecation Policy

SAP MDG follows SAP's standard maintenance policy (7 years mainstream + 3 years extended). Informatica cloud-native IDMC has quarterly releases with 12-month backward compatibility for REST APIs. Reltio is SaaS-only with automatic upgrades and 6-month deprecation notice for breaking API changes. [src3, src7]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| 2+ ERPs with overlapping customer/vendor/product data | Single ERP, no cross-system data sharing | Native ERP data governance (SAP MDG within S/4HANA) |
| Duplicate records causing operational errors (wrong invoicing, compliance violations) | Duplicate data exists but has no operational impact | Data warehouse deduplication for reporting only |
| M&A integration requiring harmonization of acquired company's master data | One-time data migration (moving off legacy ERP) | ETL migration scripts with reconciliation |
| Regulatory requirement for single customer view (KYC, GDPR right of access) | No regulatory pressure for unified records | Ad-hoc reporting with manual deduplication |
| Analytics team needs trusted, deduplicated data across business units | Each BU operates independently with no cross-BU reporting | Federated queries against individual ERP data warehouses |

## Cross-System Comparison

| Capability | SAP MDG | Informatica IDMC | Reltio | Profisee | Stibo STEP |
|---|---|---|---|---|---|
| **Primary strength** | SAP ecosystem governance | Multi-domain, AI matching | Real-time graph, speed | Azure/Microsoft fit, ease | PIM + MDM combined |
| **Supported styles** | Centralized, Coexistence | All four | Consolidation, Coexistence | Coexistence, Centralized | Centralized, Coexistence |
| **Deployment** | Hybrid (on-prem + BTP cloud) | Cloud-native (IDMC) | SaaS only | SaaS, PaaS, on-prem | Cloud, on-prem |
| **Match engine** | Built-in (deterministic + fuzzy) | CLAIRE AI + configurable | FERN LLM + ML | ML-assisted + rules | Rules-based + ML |
| **Survivorship** | Attribute-level, workflow-driven | Attribute-level, trust-based | Attribute-level, source-ranked | Attribute-level, rules-based | Attribute-level, rules-based |
| **Non-SAP ERP support** | Requires middleware (CPI, Boomi) | Native connectors (300+) | REST API integration | REST API + Azure connectors | REST API + IIEP connectors |
| **Implementation time** | 12-24 months (typical) | 6-12 months | 2-3 months (fast start) | 3-6 months | 6-12 months |
| **Typical cost (first domain)** | $1M-$3M | $500K-$1.5M | $300K-$800K | $200K-$600K | $500K-$1.5M |
| **AI/ML capabilities** | Generative AI for governance (2025) | CLAIRE AI matching, quality rules | FERN LLM matching | ML-assisted matching | ML matching (emerging) |
| **Data domains** | All (MDG-F, MDG-C, MDG-S, MDG-M) | All (multi-domain native) | Customer, vendor, product | All | Product-centric, expanding |
| **Gartner position** | Leader | Leader | Visionary → Leader | Niche → Challenger | Leader (PIM/MDM) |

[src1, src2, src3, src4, src7]

## Important Caveats

- MDM platform pricing varies dramatically by edition, domain count, and record volume — the cost ranges in this card are rough estimates for first-domain implementations. Always request vendor-specific pricing for your record volumes and domain count. [src1, src4]
- Gartner projected that 75% of MDM programs fail to meet business objectives — the primary cause is lack of governance, not technology failure. Any MDM evaluation must budget for people and process, not just software. [src6]
- SAP MDG Cloud Edition on BTP is relatively new (2025) and has feature parity gaps with the on-premise version. Verify specific capabilities against the current SAP MDG feature scope document. [src7]
- Reltio's SaaS-only deployment model means no on-premise or private cloud option. Organizations with strict data residency requirements should verify Reltio's regional availability matches their needs. [src4]
- The "right" MDM style often evolves over time. Most enterprises start with Consolidation and migrate to Coexistence within 12-24 months. Plan for style evolution in your architecture — do not assume your initial pattern is permanent. [src1, src2]
- Match quality depends more on data preparation than on platform choice. A $200K Profisee deployment with well-designed match keys will outperform a $2M Informatica deployment with poorly designed match keys. [src3]

## Related Units

- [Master Data Management for ERP — Implementation Details](/business/erp-integration/master-data-management-erp/2026)
- [Change Data Capture Patterns for ERP Integration](/business/erp-integration/change-data-capture-erp/2026)