---
# === IDENTITY ===
id: business/erp-integration/master-data-management-erp/2026
canonical_question: "How do you implement Master Data Management across ERPs - golden record, survivorship rules, sync?"
aliases:
  - "MDM golden record creation across multiple ERP systems"
  - "Survivorship rules for cross-ERP master data integration"
  - "How to synchronize master data between SAP, Salesforce, Oracle, and NetSuite"
  - "MDM hub architecture patterns for multi-ERP environments"
entity_type: erp_integration
domain: business > erp-integration > master-data-management-erp
region: global
jurisdiction: global
temporal_scope: 2024-2026

# === SYSTEM PROFILE ===
systems:
  - name: "Informatica MDM (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: "SAP Master Data Governance (MDG)"
    vendor: "SAP"
    version: "SAP S/4HANA 2023+"
    edition: "Enterprise"
    deployment: hybrid
    api_surface: "OData, RFC/BAPI, IDocs"
  - name: "Profisee MDM"
    vendor: "Profisee"
    version: "2024.1+"
    edition: "Enterprise"
    deployment: cloud
    api_surface: "REST, SDK"

# === VERIFICATION ===
last_verified: 2026-03-02
confidence: 0.88
version: 1.0
first_published: 2026-03-02

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "Reltio LLM-driven matching (FERN) GA 2024; Informatica CLAIRE AI matching 2024"
  next_review: 2026-08-29
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Golden record creation requires match/merge engine — cannot be replicated with simple ETL deduplication"
  - "Survivorship rules must be defined per attribute, not per record — record-level survivorship loses valuable data from non-winning sources"
  - "Bidirectional sync (coexistence model) requires conflict resolution logic before deployment — race conditions corrupt golden records"
  - "Cross-ERP datetime fields rarely share timezone conventions — SAP stores in user timezone, Salesforce in UTC, NetSuite in company timezone"
  - "MDM hub latency must be <500ms for operational use cases — consolidation-only hubs average 24h refresh and cannot serve real-time queries"
  - "SAP MDG is tightly coupled to SAP ecosystem — integrating non-SAP sources requires middleware (CPI, Boomi, MuleSoft)"
  - "Match key design determines merge quality — poor match keys cause both false positives (over-merge) and false negatives (missed duplicates)"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs single-ERP internal data governance without cross-system sync"
    use_instead: "Consult vendor-specific MDG documentation (SAP MDG, Oracle DRM)"
  - condition: "User needs product information management (PIM) not master data"
    use_instead: "PIM solutions (Akeneo, Salsify, inRiver) — different domain"
  - condition: "User needs data migration between ERPs (one-time move, not ongoing sync)"
    use_instead: "Data migration playbooks — ETL/ELT patterns with reconciliation"

# === AGENT HINTS ===
inputs_needed:
  - key: mdm_style
    question: "What MDM architecture style do you need?"
    type: choice
    options:
      - "registry (cross-reference index, data stays in source ERPs)"
      - "consolidation (golden records for analytics, no writeback)"
      - "coexistence (bidirectional sync, golden records + source systems)"
      - "centralized (MDM hub is single system of record)"
  - key: data_domains
    question: "Which master data domains?"
    type: choice
    options:
      - "customer/account"
      - "vendor/supplier"
      - "product/material"
      - "employee/worker"
      - "multi-domain (2+ of the above)"
  - key: erp_landscape
    question: "What ERP systems are in scope?"
    type: choice
    options:
      - "SAP-centric (S/4HANA + satellites)"
      - "multi-vendor (SAP + Oracle + Salesforce + others)"
      - "cloud-native (NetSuite, Workday, D365)"
      - "legacy + modern hybrid"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/erp-integration/master-data-management-erp/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-02)"

# === RELATED UNITS ===
related_kos:
  depends_on: []
  related_to: []
  solves: []
  alternative_to: []
  often_confused_with: []

# === SOURCES ===
sources:
  - id: src1
    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-06-15
    reliability: high
  - id: src2
    title: "MDM Survivorship: How to Choose the Right Record"
    author: Profisee
    url: https://profisee.com/blog/mdm-survivorship/
    type: technical_blog
    published: 2024-11-20
    reliability: high
  - id: src3
    title: "What Is a Golden Record in MDM?"
    author: Profisee
    url: https://profisee.com/blog/what-is-a-golden-record/
    type: technical_blog
    published: 2024-09-15
    reliability: high
  - id: src4
    title: "4 Main Master Data Management Implementation Styles"
    author: Reltio
    url: https://www.reltio.com/blogs/4-main-master-data-management-implementation-styles/
    type: technical_blog
    published: 2024-12-10
    reliability: high
  - id: src5
    title: "Master Data Management Implementation Styles, Explained"
    author: Profisee
    url: https://profisee.com/blog/master-data-management-implementation-styles/
    type: technical_blog
    published: 2024-10-01
    reliability: high
  - id: src6
    title: "Master Data Management (MDM) — The Complete 2026 Guide"
    author: Parseur
    url: https://parseur.com/blog/master-data-management
    type: industry_report
    published: 2026-01-15
    reliability: moderate_high
  - id: src7
    title: "Three Master Data Survivorship Approaches"
    author: Henrik Liliendahl (MDM List)
    url: https://mdmlist.com/2019/08/22/three-master-data-survivorship-approaches/
    type: community_resource
    published: 2019-08-22
    reliability: moderate_high
---

# Master Data Management Across ERPs: Golden Record, Survivorship Rules & Sync Patterns

## TL;DR

- **Bottom line**: Cross-ERP MDM requires a dedicated MDM hub (Informatica, Reltio, Profisee, or SAP MDG) that creates golden records via match/merge, enforces attribute-level survivorship rules, and synchronizes changes back to source ERPs through event-driven or batch integration. No ERP can serve as the MDM hub for another ERP's master data.
- **Key limit**: Survivorship must be configured per attribute, not per record — record-level survivorship discards valuable data from non-winning sources and is the #1 implementation mistake. [src2]
- **Watch out for**: Bidirectional sync without conflict resolution. If two ERPs update the same customer address simultaneously, the last-write-wins race condition corrupts the golden record. Design ownership rules per attribute per domain before enabling coexistence sync. [src1]
- **Best for**: Organizations running 2+ ERP systems (SAP + Salesforce, Oracle + NetSuite, D365 + legacy) that need consistent customer, vendor, or product master data across all systems.
- **Implementation timeline**: Single-domain consolidation: 3-6 months. Multi-domain coexistence: 12-18 months. Enterprise-wide centralized: 18-24+ months. [src6]

## System Profile

This card covers cross-ERP Master Data Management — the architecture, survivorship logic, and synchronization patterns needed to maintain a single golden record across multiple ERP and CRM systems. It is platform-agnostic but references the four dominant MDM platforms (Informatica MDM, Reltio, SAP MDG, Profisee) for concrete implementation details.

This card does NOT cover single-system data governance (e.g., SAP MDG used only within SAP), product information management (PIM), or one-time data migration. For those, consult vendor-specific documentation.

| System | Role | API Surface | Direction |
|---|---|---|---|
| MDM Hub (Informatica / Reltio / Profisee) | Golden record authority, match/merge engine | REST, GraphQL, Streaming | Hub <-> All systems |
| SAP S/4HANA | ERP — financial master, material master | OData v4, RFC/BAPI, IDocs | Bidirectional |
| Salesforce | CRM — customer/account master | REST v62.0, Bulk API, Platform Events | Bidirectional |
| Oracle ERP Cloud | ERP — financials, procurement | REST, FBDI | Bidirectional |
| NetSuite | ERP — mid-market financials, inventory | SuiteTalk REST/SOAP | Bidirectional |
| Microsoft Dynamics 365 | ERP/CRM — sales, finance, supply chain | OData v4, Dataverse API | Bidirectional |

## API Surfaces & Capabilities

MDM platforms expose APIs for match, merge, golden record CRUD, survivorship configuration, and event subscription. The integration layer between the MDM hub and ERP systems uses each ERP's native API surface.

| MDM Platform | Match API | Golden Record API | Event/CDC | Bulk Import | Latency (p95) | Auth |
|---|---|---|---|---|---|---|
| Informatica IDMC | REST /match | REST /entity CRUD | Kafka, webhooks | CSV batch, 300+ connectors | ~500ms | OAuth 2.0 |
| Reltio | REST /entities/match | REST /entities, GraphQL | Streaming API, webhooks | REST bulk, S3 ingest | <300ms | OAuth 2.0, API key |
| SAP MDG | RFC/BAPI match | OData entity CRUD, staging workflow | IDocs, AIF, CPI events | FBDI, batch input | ~1-2s (approval workflow) | SAP OAuth, X.509 |
| Profisee | REST /match | REST /records CRUD | Webhooks, Azure Event Grid | REST bulk, Azure Data Factory | ~400ms | OAuth 2.0, Azure AD |

### ERP-Side API Surfaces for Master Data Sync

| ERP System | Read API | Write API | CDC/Events | Bulk | Rate Limit |
|---|---|---|---|---|---|
| SAP S/4HANA | OData v4 | OData v4, BAPI | Business Events, AIF | IDocs batch | Fair-use, throttled |
| Salesforce | REST SOQL, Bulk API 2.0 | REST, Composite | Platform Events, CDC | Bulk API 2.0 (150MB/file) | 100K calls/24h (Enterprise) |
| Oracle ERP Cloud | REST | REST, FBDI | Business Events | FBDI (250MB/file) | Throttled per tenant |
| NetSuite | SuiteTalk REST/SOAP | SuiteTalk REST/SOAP | User Event Scripts, SuiteScript | CSV import, SuiteTalk lists | 10 concurrent requests |
| Dynamics 365 | Dataverse OData v4 | Dataverse OData v4 | Webhooks, Azure Service Bus | Data Import wizard | 6K requests/5min per user |

## Rate Limits & Quotas

### MDM Hub Limits

| Platform | API Calls | Concurrent Requests | Bulk Import Size | Match Throughput | Storage |
|---|---|---|---|---|---|
| Informatica IDMC | Tier-based (contract) | 50 concurrent (default) | 500K records/batch | ~10K matches/min | Contract-based |
| Reltio | Tier-based (contract) | 100 concurrent (Enterprise) | 1M records/bulk load | ~50K matches/min (FERN) | Unlimited (SaaS) |
| SAP MDG | No hard API limit (shared with S/4) | Work process pool (configurable) | Unlimited (batch input) | ~5K matches/min (HANA) | On-premise: hardware-dependent |
| Profisee | Tier-based (contract) | 25 concurrent (default) | 100K records/batch (REST) | ~8K matches/min | Azure-dependent |

### Per-Request Limits

| Limit Type | Informatica | Reltio | SAP MDG | Profisee |
|---|---|---|---|---|
| Max records per query | 1,000 | 10,000 | 500 (OData default, configurable) | 5,000 |
| Max payload size | 10 MB | 50 MB | 100 MB (IDoc) | 25 MB |
| Match candidates returned | 50 (default) | 100 (configurable) | 20 (default) | 50 (default) |
| Golden record merge limit | 10 records/merge | 50 records/merge | 5 records/merge (workflow) | 20 records/merge |

## Authentication

| Platform | Flow | Token Lifetime | Refresh? | Notes |
|---|---|---|---|---|
| Informatica IDMC | OAuth 2.0 client credentials | 30 min | Yes, refresh token | Service-to-service recommended |
| Reltio | OAuth 2.0, API key | 1h (OAuth), permanent (API key) | Yes (OAuth) | API key for dev; OAuth for production |
| SAP MDG | OAuth 2.0, X.509, SAML | Session-based (configurable) | Yes | X.509 for server-to-server; OAuth for cloud |
| Profisee | OAuth 2.0 / Azure AD | 1h | Yes | Azure AD integration native |

### Authentication Gotchas

- SAP MDG authentication differs between on-premise (X.509/basic) and cloud (OAuth 2.0) — migration requires credential rearchitecture. [src1]
- Reltio API keys grant full tenant access — use OAuth 2.0 with scoped permissions in production. [src4]
- Informatica IDMC tokens issued per pod — multi-pod deployments need separate auth per region. [src1]

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

- **Attribute-level survivorship is mandatory**: Record-level survivorship ("trust CRM for everything") loses valuable data. Each attribute (name, address, phone, email) must have independent survivorship rules. [src2]
- **Match key design determines quality**: Poor match keys cause over-merging (false positives destroying distinct records) or under-merging (duplicates persist). Requires iterative tuning with sample data. [src3]
- **Bidirectional sync requires ownership rules**: Without per-attribute data ownership, simultaneous updates from two ERPs create race conditions. Define which system "owns" each attribute before enabling coexistence. [src1]
- **Timezone mismatch corrupts temporal data**: SAP stores in user timezone, Salesforce in UTC, NetSuite in company timezone preference. All datetime fields must normalize to UTC at the MDM hub. [src1]
- **SAP MDG staging workflow adds latency**: MDG uses a change request + approval workflow before committing to master data — not suitable for <1s real-time sync without bypassing governance. [src5]
- **MDM hub is not an ESB**: The MDM hub manages master data (customer, vendor, product, employee). Transaction data (orders, invoices, shipments) should flow through iPaaS/ESB, not the MDM hub.
- **Poor data quality in sources propagates to golden records**: MDM is not a substitute for source-system data quality — garbage in, golden garbage out. Clean data before loading into the hub.

## Integration Pattern Decision Tree

```
START — User needs cross-ERP Master Data Management
├── What's the primary use case?
│   ├── Analytics / reporting only (no writeback needed)
│   │   └── CONSOLIDATION style
│   │       ├── Deploy Informatica / Reltio / Profisee in consolidation mode
│   │       ├── Batch ETL from all ERPs nightly
│   │       ├── Match/merge → golden records
│   │       └── Feed BI/analytics; source ERPs unchanged
│   ├── Cross-reference lookup (which records match across systems?)
│   │   └── REGISTRY style
│   │       ├── Deploy MDM hub as index/cross-reference
│   │       ├── No golden record persistence (federated queries)
│   │       ├── Minimal disruption, fast deployment
│   │       └── WARNING: Rarely viable in production — data quality stays poor [src5]
│   ├── Operational sync (golden records used in real-time operations)
│   │   ├── Can you designate one hub as sole master data author?
│   │   │   ├── YES → CENTRALIZED style
│   │   │   │   ├── All master data CRUD in MDM hub only
│   │   │   │   ├── ERPs become read-only consumers
│   │   │   │   ├── Strongest governance, zero sync conflicts
│   │   │   │   └── WARNING: 18-24+ months, most disruptive [src5]
│   │   │   └── NO → COEXISTENCE style
│   │   │       ├── MDM hub + source ERPs both author master data
│   │   │       ├── Bidirectional sync via CDC / Platform Events / webhooks
│   │   │       ├── MUST define per-attribute ownership rules
│   │   │       ├── MUST implement conflict resolution before go-live
│   │   │       └── Most common enterprise pattern [src4]
│   │   └── How many data domains?
│   │       ├── Single domain (customer OR product) → 3-6 months
│   │       ├── 2-3 domains → 9-12 months
│   │       └── Enterprise-wide → 12-18+ months [src6]
│   └── Hybrid (different styles per domain)
│       ├── Customer data → coexistence (operational)
│       ├── Product data → consolidation (analytics)
│       └── Vendor data → centralized (procurement-owned)
├── Which MDM platform?
│   ├── SAP-heavy landscape → SAP MDG (native integration)
│   ├── Multi-vendor, cloud-first → Reltio (<300ms, LLM matching) [src4]
│   ├── Enterprise, 100+ sources → Informatica IDMC (300+ connectors) [src1]
│   └── Microsoft/Azure stack → Profisee (Azure-native)
└── What middleware for ERP sync?
    ├── SAP CPI / Integration Suite → SAP-to-SAP + SAP-to-cloud
    ├── MuleSoft → Multi-vendor, API-led connectivity
    ├── Boomi → Cloud-to-cloud, rapid deployment
    ├── Workato → Low-code, business-user friendly
    └── Azure Integration Services → Microsoft ecosystem
```

## Quick Reference

### Survivorship Rule Types

| Rule Type | How It Works | Best For | Example |
|---|---|---|---|
| **Source priority** | Rank source systems per attribute; highest-rank wins | Regulated environments with clear data ownership | CRM owns email; ERP owns billing address |
| **Most recent** | Newest timestamp wins for the attribute | Frequently changing data (phone, email) | Customer changed phone in CRM yesterday; ERP has last year's phone → CRM wins |
| **Frequency** | Most common value across sources wins | Stable attributes with many sources | 3 of 4 systems say "New York"; 1 says "NY" → "New York" wins |
| **Completeness** | Most complete (non-null) value wins | Sparse data environments | CRM has name + email; ERP has name only → CRM email survives |
| **Aggregation** | Combine values from multiple sources | Multi-valued attributes | Merge all known phone numbers, deduplicate |
| **Conditional** | Apply different rules based on data context | Complex business rules | If country = US, trust ERP for tax ID; if country = EU, trust CRM |
| **Stacked (composite)** | Chain rules: try source priority first, fall back to recency | Production environments needing fallback logic | Trust CRM for email (priority) → if null, use most recent from any source |

[src2, src7]

### MDM Architecture Style Comparison

| Capability | Registry | Consolidation | Coexistence | Centralized |
|---|---|---|---|---|
| Golden record persistence | No (federated) | Yes (read-only) | Yes (read-write) | Yes (authoritative) |
| Source system changes | None | None | Writeback to sources | Sources become read-only |
| Sync direction | Read-only from sources | Sources → hub | Bidirectional | Hub → sources |
| Implementation time | 4-8 weeks | 3-6 months | 9-18 months | 18-24+ months |
| Governance strength | Low | Medium | Medium-High | Highest |
| Disruption level | Minimal | Low | Medium | High |
| Data quality improvement | Minimal | Moderate | High | Highest |
| Real-time operational use | Limited | No (batch) | Yes | Yes |
| Conflict resolution needed | No | No | Yes (critical) | No (single author) |
| Production prevalence | Rare | Common (starting point) | Most common | Aspirational |

[src1, src4, src5]

## Step-by-Step Integration Guide

### 1. Assess master data landscape and select MDM style

Map all systems that create or consume master data. For each data domain (customer, vendor, product), identify the current system of record and data quality issues. [src6]

```bash
# Inventory: list all systems with master data
# For each system, document:
# - Which master data domains (customer, vendor, product, employee)
# - Volume (record count per domain)
# - Data quality (duplicate rate, completeness %)
# - Current system-of-record designation
# - API capabilities (REST, SOAP, batch, CDC)
# - Update frequency (real-time, daily, weekly)

# Example assessment matrix (CSV format):
# system,domain,records,dup_rate,completeness,api,update_freq,sor
# SAP S/4HANA,vendor,150000,8%,92%,"OData v4, BAPI",real-time,yes
# Salesforce,customer,500000,15%,78%,"REST v62.0, Bulk API",real-time,yes
# NetSuite,customer,200000,12%,85%,"SuiteTalk REST",hourly,no
# Oracle ERP,product,80000,5%,95%,"REST, FBDI",daily,yes
```

**Verify**: You have a complete system inventory with duplicate rates and data quality scores for each domain.

### 2. Design match keys and survivorship rules

Define matching criteria (deterministic + probabilistic) and attribute-level survivorship rules before touching any technology. [src2, src3]

```yaml
# Match key design for Customer domain
match_rules:
  - name: "exact_match"
    type: deterministic
    keys: ["tax_id"]  # SSN/EIN/VAT — unique identifier
    action: auto_merge

  - name: "fuzzy_match"
    type: probabilistic
    keys:
      - field: "company_name"
        algorithm: "jaro_winkler"
        threshold: 0.85
      - field: "address_line_1"
        algorithm: "edit_distance"
        threshold: 0.80
      - field: "postal_code"
        algorithm: "exact"
    min_score: 0.90
    action: auto_merge

  - name: "possible_match"
    type: probabilistic
    keys:
      - field: "company_name"
        algorithm: "jaro_winkler"
        threshold: 0.70
      - field: "city"
        algorithm: "exact"
    min_score: 0.75
    action: manual_review  # Data steward reviews

# Survivorship rules for Customer domain
survivorship:
  customer_name:
    rule: source_priority
    priority: [CRM, ERP, legacy_system]
    fallback: most_recent

  billing_address:
    rule: source_priority
    priority: [ERP, CRM]
    fallback: completeness

  email:
    rule: most_recent
    require_valid_format: true

  phone:
    rule: most_recent
    fallback: completeness

  tax_id:
    rule: source_priority
    priority: [ERP]  # Financial system always owns tax ID
    fallback: null  # Never guess tax IDs

  credit_limit:
    rule: source_priority
    priority: [ERP]  # Only finance can set credit limits
    immutable_once_set: false
```

**Verify**: Every attribute in your golden record has an explicit survivorship rule with fallback. No attributes use record-level selection.

### 3. Configure the MDM hub and initial data load

Deploy the MDM platform, configure match/merge rules, and perform initial bulk load from all source systems. [src1]

```python
# Example: Reltio initial data load via REST API
# Input:  Source system extracts (CSV/JSON) from SAP, Salesforce, NetSuite
# Output: Golden records created in Reltio with cross-references

import requests
import json
from time import sleep

RELTIO_BASE = "https://{tenant}.reltio.com/reltio/api/{tenant_id}"
HEADERS = {
    "Authorization": "Bearer {access_token}",
    "Content-Type": "application/json"
}

def load_entities_bulk(entities, entity_type="configuration/entityTypes/Customer"):
    """Bulk load entities into Reltio MDM hub."""
    # Reltio bulk API: max 1000 entities per request
    BATCH_SIZE = 1000
    results = {"created": 0, "matched": 0, "errors": 0}

    for i in range(0, len(entities), BATCH_SIZE):
        batch = entities[i:i + BATCH_SIZE]
        payload = [
            {
                "type": entity_type,
                "attributes": {
                    "Name": [{"value": e["name"]}],
                    "Address": [{"value": e["address"]}],
                    "TaxID": [{"value": e["tax_id"]}],
                    "Email": [{"value": e["email"]}],
                    "Phone": [{"value": e["phone"]}]
                },
                "crosswalks": [
                    {
                        "type": "configuration/sources/" + e["source_system"],
                        "value": e["source_id"]
                    }
                ]
            }
            for e in batch
        ]

        resp = requests.post(
            f"{RELTIO_BASE}/entities",
            headers=HEADERS,
            json=payload
        )

        if resp.status_code == 200:
            result = resp.json()
            results["created"] += result.get("created", 0)
            results["matched"] += result.get("matched", 0)
        elif resp.status_code == 429:
            sleep(2)  # Rate limit — back off
            continue
        else:
            results["errors"] += len(batch)
            print(f"Error batch {i}: {resp.status_code} {resp.text[:200]}")

    return results
```

**Verify**: `GET /entities?filter=crosswalks.type==*&max=1` returns entities with cross-references from multiple source systems.

### 4. Implement ongoing synchronization

Set up event-driven sync between ERP systems and the MDM hub. [src1, src4]

```python
# Example: Salesforce CDC -> MDM Hub sync via Platform Events
# Input:  Salesforce Change Data Capture events for Account object
# Output: Golden record updates in MDM hub

import json
from simple_salesforce import Salesforce

# Subscribe to Salesforce CDC
sf = Salesforce(
    username="integration@company.com",
    password="***",
    security_token="***",
    domain="login"  # or "test" for sandbox
)

def process_cdc_event(event):
    """Process a Salesforce CDC event and sync to MDM hub."""
    change_type = event["event"]["type"]  # CREATE, UPDATE, DELETE
    record_id = event["event"]["replayId"]
    changed_fields = event["payload"]["ChangeEventHeader"]["changedFields"]
    entity_data = event["payload"]

    if change_type in ("CREATE", "UPDATE"):
        # Map Salesforce fields to MDM hub schema
        mdm_payload = {
            "attributes": {},
            "crosswalks": [{
                "type": "configuration/sources/Salesforce",
                "value": entity_data["Id"]
            }]
        }

        # Only sync changed fields (not full record)
        field_mapping = {
            "Name": "Name",
            "BillingStreet": "Address",
            "BillingCity": "City",
            "BillingPostalCode": "PostalCode",
            "Phone": "Phone",
            "Email__c": "Email"
        }

        for sf_field, mdm_field in field_mapping.items():
            if sf_field in changed_fields:
                mdm_payload["attributes"][mdm_field] = [
                    {"value": entity_data.get(sf_field)}
                ]

        # Upsert to MDM hub — match on crosswalk, survivorship determines golden record
        resp = requests.put(
            f"{RELTIO_BASE}/entities",
            headers=HEADERS,
            json=mdm_payload
        )
        return resp.status_code

    elif change_type == "DELETE":
        # Soft-delete: mark crosswalk inactive, don't delete golden record
        # Other source systems may still contribute to this entity
        pass
```

**Verify**: Update a record in Salesforce, wait <5s, verify golden record in MDM hub reflects the change (or queued for stewardship if conflict detected).

### 5. Implement conflict resolution and data stewardship

Configure automated and manual conflict resolution for bidirectional sync scenarios. [src1, src2]

```python
# Example: Conflict detection and resolution workflow
# Input:  Competing updates from two source systems within 60s window
# Output: Resolved golden record or stewardship task

def resolve_conflict(golden_record, update_a, update_b, survivorship_rules):
    """
    Resolve conflicting updates from two source systems.
    Returns resolved attributes or escalates to data steward.
    """
    resolved = {}
    escalations = []

    for attr in set(list(update_a.keys()) + list(update_b.keys())):
        rule = survivorship_rules.get(attr, {"rule": "most_recent"})

        if attr in update_a and attr not in update_b:
            resolved[attr] = update_a[attr]
        elif attr in update_b and attr not in update_a:
            resolved[attr] = update_b[attr]
        elif update_a.get(attr) == update_b.get(attr):
            resolved[attr] = update_a[attr]  # No conflict
        else:
            # True conflict — apply survivorship rule
            if rule["rule"] == "source_priority":
                priority = rule["priority"]
                src_a = update_a.get("_source_system")
                src_b = update_b.get("_source_system")
                if priority.index(src_a) < priority.index(src_b):
                    resolved[attr] = update_a[attr]
                else:
                    resolved[attr] = update_b[attr]
            elif rule["rule"] == "most_recent":
                if update_a["_timestamp"] > update_b["_timestamp"]:
                    resolved[attr] = update_a[attr]
                else:
                    resolved[attr] = update_b[attr]
            else:
                # Cannot auto-resolve — escalate to data steward
                escalations.append({
                    "attribute": attr,
                    "value_a": update_a.get(attr),
                    "value_b": update_b.get(attr),
                    "source_a": update_a.get("_source_system"),
                    "source_b": update_b.get("_source_system")
                })

    if escalations:
        create_stewardship_task(golden_record["id"], escalations)

    return resolved
```

**Verify**: Simulate a conflict (update same customer address in two ERPs within 60s). Confirm the survivorship rule resolves correctly or creates a stewardship task.

## Data Mapping

### Cross-ERP Field Mapping Reference (Customer Domain)

| MDM Golden Field | SAP S/4HANA | Salesforce | Oracle ERP Cloud | NetSuite | Gotcha |
|---|---|---|---|---|---|
| Customer Name | BP_NAME (BUPA) | Account.Name | HZ_PARTIES.PARTY_NAME | customer.companyName | SAP max 40 chars; SF max 255 |
| Address Line 1 | ADRC.STREET | Account.BillingStreet | HZ_LOCATIONS.ADDRESS1 | customer.defaultAddress.addr1 | SAP uses structured address (street + house#); SF is freeform |
| Postal Code | ADRC.POST_CODE1 | Account.BillingPostalCode | HZ_LOCATIONS.POSTAL_CODE | customer.defaultAddress.zip | Format varies by country — normalize |
| Country | ADRC.COUNTRY (ISO 2) | Account.BillingCountry (full name) | HZ_LOCATIONS.COUNTRY (ISO 2) | customer.defaultAddress.country (ISO 2) | Salesforce stores "United States"; others use "US" |
| Tax ID | DFKKBPTAXNUM.TAXNUM | Account.Tax_ID__c (custom) | ZX_REGISTRATIONS.REGISTRATION_NUMBER | customer.defaultTaxReg | Format validation per jurisdiction required |
| Email | ADR6.SMTP_ADDR | Account.Email__c or Contact.Email | HZ_CONTACT_POINTS.EMAIL_ADDRESS | customer.email | SAP may have multiple via ADR6 table; merge logic needed |
| Phone | ADR2.TEL_NUMBER | Account.Phone | HZ_CONTACT_POINTS.PHONE_NUMBER | customer.phone | International format (+country code) must be enforced |
| Credit Limit | KNKK.KLIMK | Account.Credit_Limit__c (custom) | HZ_CUST_ACCT_SITES.CREDIT_LIMIT | customer.creditLimit | Currency conversion required for multi-currency |
| Payment Terms | KNB1.ZTERM | Account.Payment_Terms__c (custom) | RA_TERMS.NAME | customer.terms.name | Code vs. description mismatch — map codes |

### Data Type Gotchas

- **Datetime timezone mismatch**: SAP stores datetimes in user timezone; Salesforce always UTC; NetSuite in company timezone preference; Oracle in database server timezone. Normalize all to UTC at the MDM hub before comparison. [src1]
- **Currency storage**: SAP stores amounts in smallest currency unit (cents for USD, yen for JPY); Salesforce stores as decimal; NetSuite stores as decimal with currency field. Currency conversion must happen at sync time, not at read time.
- **Address structure**: SAP uses structured addresses (separate street, house number, city, region fields). Salesforce uses freeform text lines. Bi-directional sync requires parsing/composing addresses, which is error-prone. Use a standardization service (Loqate, Google Address Validation) at the MDM hub.
- **Multi-value fields**: SAP Business Partner can have multiple addresses (ADRC entries) with usage types. Salesforce Account has only one BillingAddress and one ShippingAddress. MDM hub must map SAP usage types to SF address fields or store the full set and designate primary.
- **Null vs. empty string**: SAP returns initial values (e.g., "00000000" for empty dates); Salesforce returns null. MDM survivorship must treat these as equivalent "no data" to avoid false updates. [src2]

## Error Handling & Failure Points

### Common Error Patterns

| Error Pattern | Cause | Impact | Resolution |
|---|---|---|---|
| Over-merge (false positive) | Match keys too loose; fuzzy threshold too low | Two distinct customers merged into one golden record; orders attributed to wrong customer | Tighten match thresholds; add negative match rules; implement manual review for scores 0.75-0.90 |
| Under-merge (false negative) | Match keys too strict; missing normalization | Same customer exists as 3 golden records; analytics and reporting fragmented | Add fuzzy matching; normalize data before matching (uppercase, trim, standardize addresses) |
| Sync loop (ping-pong) | Bidirectional sync without change-origin tracking | Update from ERP A triggers sync to hub, which triggers writeback to ERP A, which triggers sync to hub... | Tag each change with source system origin; skip writeback to originating system |
| Stale golden record | Batch sync delay (24h consolidation) in operational scenario | Customer calls and agent sees yesterday's address | Move from consolidation to coexistence/centralized style; or add real-time CDC for critical attributes |
| Race condition | Two ERPs update same attribute within sync window | Last-write-wins may pick wrong value; golden record corrupted | Implement per-attribute ownership; use vector clocks or timestamp + priority for conflict resolution |
| Governance bypass | Developers call MDM API directly, skipping approval workflow | Unvalidated data enters golden record | API gateway with validation middleware; SAP MDG: enforce staging area for all changes |

### Failure Points in Production

- **Match key drift**: Match keys designed at go-live degrade as data patterns change (e.g., new country formats, acquired company naming conventions). Fix: `Schedule quarterly match key effectiveness reviews; monitor false positive/negative rates continuously`. [src3]
- **Survivorship rule gaps**: New attributes added to ERP but not configured in survivorship rules — defaults to "last writer wins" silently. Fix: `Alert on any golden record attribute without an explicit survivorship rule; block new field sync until rules are defined`. [src2]
- **Connector version mismatch**: MDM platform connector expects ERP API v61 but ERP was upgraded to v62 with breaking changes. Fix: `Pin connector versions; test in sandbox after every ERP upgrade before production cutover`. [src1]
- **Bulk load timeout**: Initial data load of 5M+ records times out due to match/merge processing. Fix: `Load in batches of 100K; disable real-time matching during initial load; run batch match/merge after load completes`. [src1]
- **Data steward bottleneck**: Too many records routed to manual review (>5% of total). Fix: `Tune match thresholds to auto-merge above 0.95 and auto-reject below 0.60; manual review only for 0.60-0.95 band`. [src2]

## Anti-Patterns

### Wrong: Record-level survivorship ("trust CRM for everything")

```yaml
# BAD — record-level survivorship discards valuable data
survivorship:
  customer_record:
    rule: source_priority
    winner: CRM  # CRM record wins entirely
    # Result: ERP's billing address, credit limit, payment terms all lost
    # CRM doesn't even have these fields populated!
```

### Correct: Attribute-level survivorship with fallbacks

```yaml
# GOOD — each attribute has its own survivorship rule
survivorship:
  customer_name:
    rule: source_priority
    priority: [CRM, ERP]
    fallback: completeness
  billing_address:
    rule: source_priority
    priority: [ERP, CRM]  # ERP owns financial data
    fallback: most_recent
  email:
    rule: most_recent
    fallback: completeness
  credit_limit:
    rule: source_priority
    priority: [ERP]  # ONLY finance system can set this
```

[src2]

### Wrong: Point-to-point sync between ERPs (no MDM hub)

```
# BAD — N ERPs = N*(N-1)/2 integrations; no golden record
SAP <---> Salesforce (custom sync)
SAP <---> NetSuite (custom sync)
Salesforce <---> NetSuite (custom sync)
# 3 ERPs = 3 point-to-point integrations
# 5 ERPs = 10 point-to-point integrations
# No single source of truth; conflicts resolved ad-hoc per integration
```

### Correct: Hub-and-spoke via MDM platform

```
# GOOD — N ERPs = N integrations; MDM hub is golden record authority
SAP ←→ MDM Hub ←→ Salesforce
              ↕
           NetSuite
# 3 ERPs = 3 integrations (one per system)
# 5 ERPs = 5 integrations
# Golden record in hub resolves all conflicts via survivorship rules
```

[src1]

### Wrong: Sync full records on every change

```python
# BAD — full record sync wastes bandwidth and triggers unnecessary survivorship evaluation
def sync_to_mdm(salesforce_account):
    # Sends ALL 150+ fields even if only email changed
    mdm_client.upsert_entity(salesforce_account.to_dict())
```

### Correct: Delta sync — only changed fields

```python
# GOOD — only sync changed attributes
def sync_to_mdm(cdc_event):
    changed_fields = cdc_event["changedFields"]
    delta_payload = {
        field: cdc_event["payload"][field]
        for field in changed_fields
        if field in MDM_FIELD_MAPPING
    }
    # Only changed attributes evaluated by survivorship
    mdm_client.update_entity(
        crosswalk=("Salesforce", cdc_event["recordId"]),
        attributes=delta_payload
    )
```

[src1]

## Common Pitfalls

- **Starting with coexistence when consolidation suffices**: Many organizations jump to bidirectional sync when they only need analytics-grade golden records. Start with consolidation, prove value in 3-6 months, then graduate to coexistence. [src5]
- **Ignoring data quality before MDM**: Loading dirty data into an MDM hub produces "golden garbage." Invest in source-system data cleansing (standardization, deduplication, enrichment) before initial load. [src6]
- **Underestimating data steward workload**: Plan for 2-5% of records requiring manual review during initial load. Staff data stewards before go-live, not after. Organizations report "poor data quality costs $12.9 million per year" — stewards are ROI-positive. [src6]
- **Single match key strategy**: Using only deterministic matching (exact tax ID) misses duplicates with typos. Using only fuzzy matching creates false positives. Combine both: deterministic for high-confidence auto-merge, probabilistic for candidate identification. [src3]
- **Not tracking change origin in bidirectional sync**: Without source-system tagging, updates from ERP A flow to hub, then back to ERP A, creating infinite sync loops. Every change event must carry a `source_system` tag; skip writeback to the originating system. [src1]
- **Treating MDM as a one-time project**: MDM is an ongoing operational capability. Match keys degrade, new systems join the landscape, survivorship rules need tuning. Budget for continuous operations, not just implementation. [src6]

## Diagnostic Commands

```bash
# Check golden record cross-references (Reltio example)
curl -H "Authorization: Bearer $TOKEN" \
  "$RELTIO_BASE/entities/{entity_uri}?options=crosswalks" | jq '.crosswalks'
# Expected: Array of crosswalks linking to SAP, Salesforce, NetSuite source records

# Verify survivorship rule application (check which source won for each attribute)
curl -H "Authorization: Bearer $TOKEN" \
  "$RELTIO_BASE/entities/{entity_uri}?options=sourceValues" | jq '.attributes'
# Expected: Each attribute shows source system and timestamp that won survivorship

# Check match candidates for a record
curl -H "Authorization: Bearer $TOKEN" \
  -X POST "$RELTIO_BASE/entities/match" \
  -d '{"type":"configuration/entityTypes/Customer","attributes":{"Name":[{"value":"Acme Corp"}],"PostalCode":[{"value":"10001"}]}}' | jq '.potentialMatches'
# Expected: List of potential duplicate entities with match scores

# Monitor data stewardship queue
curl -H "Authorization: Bearer $TOKEN" \
  "$RELTIO_BASE/tasks?status=OPEN&type=POTENTIAL_MATCH&max=10" | jq '.total, .tasks[].attributes'
# Expected: Count of pending manual review tasks and their details

# Verify sync status — check last sync timestamp per source system
curl -H "Authorization: Bearer $TOKEN" \
  "$RELTIO_BASE/entities?filter=crosswalks.type=='configuration/sources/Salesforce'&max=1&orderBy=-updatedTime" | jq '.[0].updatedTime'
# Expected: Timestamp within expected sync window (e.g., <5 min for real-time, <24h for batch)
```

## Version History & Compatibility

| Platform | Version | Release Date | Status | Key Changes |
|---|---|---|---|---|
| Informatica IDMC | 2025.3 | 2025-10 | Current | CLAIRE AI matching improvements; new Kafka connector |
| Informatica IDMC | 2024.3 | 2024-10 | Supported | GraphQL API GA; enhanced survivorship UI |
| Reltio | 2025.1 | 2025-03 | Current | FERN LLM matching GA; <300ms p95 latency |
| Reltio | 2024.2 | 2024-06 | Supported | Zero-shot learning matching; bulk API improvements |
| SAP MDG | S/4HANA 2023 FPS02 | 2024-04 | Current | Cloud-native deployment; improved OData APIs |
| SAP MDG | S/4HANA 2022 | 2023-10 | Supported | Business Partner consolidation |
| Profisee | 2024.1 | 2024-03 | Current | Azure-native rewrite; REST API v2 |

### Deprecation Policy

Informatica supports N-2 versions (approximately 18-month window). Reltio is SaaS-only — all tenants on latest version with backward-compatible APIs. SAP MDG follows SAP S/4HANA maintenance schedule (minimum 5 years mainstream support). Profisee supports N-1 versions (12-month window). [src1, src4]

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| 2+ ERP systems with overlapping master data domains | Single ERP with no external master data sources | Native ERP data governance (SAP MDG standalone) |
| Customer/vendor duplicates across systems cause operational issues | Data quality issues are within a single system only | Data quality tools (Informatica DQ, Trillium, Ataccama) |
| Regulatory compliance requires single view of customer (KYC, GDPR) | Compliance can be met with system-level controls | Per-system compliance tooling |
| M&A integration requires merging master data from acquired company | One-time data migration without ongoing sync | ETL migration with reconciliation |
| Real-time operational decisions need consistent master data | Batch analytics can tolerate 24h staleness | Data warehouse / data lake with ELT |
| 100K+ master data records with >5% estimated duplicate rate | <10K records with minimal duplication | Spreadsheet-based deduplication |

## Cross-System Comparison

| Capability | Informatica IDMC | Reltio | SAP MDG | Profisee |
|---|---|---|---|---|
| Architecture | Cloud-native SaaS | Cloud-native SaaS | On-premise + cloud | Cloud (Azure-native) |
| Matching Engine | CLAIRE AI (ML + rules) | FERN (LLM-powered, zero-shot) | HANA-based fuzzy match | Rules + ML |
| Match Latency (p95) | ~500ms | <300ms | ~1-2s (incl. workflow) | ~400ms |
| Pre-built ERP Connectors | 300+ | 50+ (API-first) | Native SAP, limited non-SAP | 30+ (Azure ecosystem) |
| Survivorship Rules | Attribute-level, stacked | Attribute-level, confidence-based | Field-level with workflow | Attribute-level |
| Multi-domain Support | Yes (customer, product, supplier, etc.) | Yes (connected graph) | Yes (BP, Material, Finance) | Yes |
| Governance Workflow | Built-in stewardship | Built-in stewardship | Full change request + approval | Built-in stewardship |
| Deployment Time | 3-6 months (single domain) | <90 days (single domain) | 6-12 months | 3-6 months |
| Pricing Model | Tier-based (records + API calls) | Tier-based (entities + users) | License + SAP infra | Tier-based (records) |
| Best For | Enterprise, 100+ sources | Cloud-first, real-time operational | SAP-heavy landscape | Microsoft/Azure stack |

[src1, src4, src5, src6]

## Important Caveats

- MDM platform pricing varies dramatically by vendor and tier — Reltio and Informatica are typically $200K-$1M+/year for enterprise; Profisee is generally lower; SAP MDG is included in S/4HANA Enterprise license but requires implementation services.
- Implementation costs typically exceed software licensing by 2-4x — budget $500K-$2M for a multi-domain enterprise MDM program including consulting, data quality remediation, and change management. [src6]
- "92% of businesses admit they have duplicate records in their systems" — the problem is universal, but the solution complexity varies dramatically by organizational maturity. [src6]
- Cloud-native MDM platforms (Reltio, Informatica IDMC) auto-upgrade — your survivorship rules and match keys must be regression-tested after each platform update.
- SAP MDG is strongest when the majority of your landscape is SAP. For multi-vendor ERP landscapes, platform-agnostic MDM (Informatica, Reltio) provides better coverage. [src5]
- Match key effectiveness degrades over time as data patterns change — plan for quarterly reviews and ongoing tuning, not set-and-forget configuration.

## Related Units
<!-- No related units currently published in this domain -->