Skill Hub — DAMA / Data

Reference Data Management Working Skill

Manage code lists, status values, and classification schemes. Prevent drift between systems. Design distribution and change control for reference data.

What this skill is for

This skill helps you manage the small data that controls big processes: country codes, order statuses, material groups, payment terms, and classification schemes. It provides a method to inventory reference data, detect drift between systems, define a single source of truth for each code list, and design change control that prevents integration failures. The output is a reference data governance model that keeps code values consistent across the landscape.

When to use this skill

An integration fails because a code value in the source system does not exist in the target.
A report groups data incorrectly because classification codes have diverged between systems.
A new country, product category, or business unit is added and the change must propagate to multiple systems.
A system migration requires harmonizing two code sets that evolved independently.
Users complain that dropdown lists show different values in different systems.
An audit requires documented reference data ownership, change history, and approval workflows.

Real work situations

Example 1: IDoc failure on country code

A customer master replication IDoc fails with status 51. The error is "Country code XK not defined." The source system added Kosovo (XK) last month. The target system and the EDI partner still use the old country list. The skill produces a reference data synchronization plan: identify all systems that maintain country codes, define the authoritative source, and design a change notification workflow.

Example 2: Material group divergence

Procurement reports spend by material group. The numbers do not match Finance's cost center reports. The skill traces the material group code from the material master through to the procurement system and finds that two different code lists are in use: one from 2019 and one from 2023. The skill produces a harmonization plan with mapping, migration, and governance rules.

Example 3: Order status confusion

The CRM shows orders as "Confirmed." The ERP shows them as "In Process." The warehouse shows them as "Ready to Ship." These are not the same status mapped differently; they are different status schemes maintained by different teams. The skill maps each status scheme, defines the canonical status list, and designs a synchronization rule.

Example 4: Post-merger chart of accounts

Two companies merge. Each has a chart of accounts. The consolidation system needs a unified view. The skill inventories both code sets, identifies overlaps and gaps, defines the target chart of accounts, and produces a mapping table with conversion rules and validation checks.

Inputs required

List of reference data domains in scope: country codes, status values, material groups, payment terms, etc.
Code values and descriptions from each system that maintains or uses the domain.
System landscape showing which systems create, modify, and consume each code list.
Integration documentation showing how code values are transmitted between systems.
Business process descriptions that depend on the reference data.
Change history or audit log showing recent additions, modifications, or deletions (optional).

Questions to ask

Which system is the authoritative source for this code list, and who approves changes to it?
What are the allowed values, and do all systems use the same set?
What happens when a code is added in the source but not yet in the target?
Are there deprecated codes that still exist in some systems but should not be used?
Which business process fails when a code value is missing or mismatched?
How are code changes communicated to downstream systems and teams?
Is there a mapping layer between code lists, and who maintains it?

Working method

Inventory reference data domains. List the code lists, status values, and classification schemes in scope. For each, identify the business purpose and the systems that use it.
Collect code values from each system. Extract the current values and descriptions from every system that maintains or consumes the domain. Include custom values, legacy values, and local extensions.
Compare and identify drift. Align code values across systems. Flag: values missing in one system, values with different descriptions, values with different meanings, and custom values that exist only locally.
Define the canonical code set. For each domain, decide the authoritative list of values, descriptions, and meanings. Document which system is the source of truth and which values are deprecated.
Design the mapping layer. If systems cannot use the same codes directly, define mapping tables with source value, target value, transformation rule, and owner.
Design change control. Define: who can request a change, who approves it, how it is tested, how it is communicated, and how it is deployed to all systems.
Design distribution. Define how code changes flow from the source of truth to each consumer: API, batch file, database replication, or manual update. Include frequency and failure handling.
Define monitoring. Design checks that detect drift: scheduled comparisons, integration validation, or report reconciliation. Define who is alerted and how they respond.
Produce the reference data governance model. Combine inventory, canonical set, mapping, change control, distribution, and monitoring into a single document.
Validate with a pilot change. Test the change control and distribution process on a low-risk code addition. Adjust before applying to critical codes.

Decision rules

If two systems use different code lists for the same business concept, define a canonical set and a mapping layer; do not force one system to adopt the other's codes unless agreed.
If a code is added to the source system, it must not be usable in downstream processes until the target systems have confirmed receipt.
If a code is deprecated, it must remain in the code list for historical reporting but be blocked from new transactions.
If a mapping table is required, assign an owner who reviews it quarterly; unmaintained mappings become a source of silent errors.
If a system maintains local extensions to a global code list, document the extensions and their business justification; unauthorized extensions are drift.
If a code change affects financial reporting, compliance, or integration, it requires approval from both business and technical owners.
If reference data drift is detected, treat it as a data quality incident; run root cause analysis before correcting.

Deliverables

Reference Data Inventory — domains, systems, values, and drift analysis.
Canonical Code Set Definition — authoritative values, descriptions, deprecation status, and source of truth.
Mapping Specification — source-to-target mappings with transformation rules and owners.
Reference Data Governance Model — change control, distribution, monitoring, and ownership.

Templates

Reference Data Drift Comparison (compact)

| Domain | System A Values | System B Values | Missing in A | Missing in B | Different Meaning | Action |
|--------|-----------------|-----------------|--------------|--------------|-------------------|--------|
| Country | 249 codes | 247 codes | XK, XZ | — | XK = Kosovo in A, not defined in B | Add XK to B; retire XZ in A |
| MaterialGroup | 45 groups | 52 groups | — | MG_NEW_1 to MG_NEW_7 | MG_10 = "Electronics" in A, "Hardware" in B | Harmonize definitions; update B |

Code Change Request (compact)

---
request: Code Change
id: CR-REF-001
domain: Country
date: 2026-06-09
---

## Proposed change
- Add: XK — Kosovo
- Deprecate: XZ — Temporary code for testing

## Business reason
XK recognized for tax reporting. XZ was a test code never cleaned up.

## Systems affected
- SAP S/4 (source of truth)
- CRM
- EDI gateway
- BW

## Approval
- Business owner: Finance Director
- Technical owner: Integration Lead

## Test plan
1. Add XK in SAP dev
2. Verify replication to CRM and EDI
3. Run sample transaction
4. Confirm BW load

## Rollback
- Remove XK from all systems if test fails

## Communication
- Notify: EDI partners, Tax team, Reporting team
- Method: Email + wiki update

Quality checklist

Every reference data domain in scope has a named source of truth system.
Code values have been collected from every system that uses the domain.
Drift has been documented with specific values, not just "some differences."
The canonical code set is defined and approved by the business owner.
Mapping tables have owners and review cycles.
Change control includes request, approval, test, communication, and rollback steps.
Distribution paths are documented with frequency and failure handling.
Monitoring detects drift and alerts a named owner.

Common mistakes

Mistake: Treating reference data as "just configuration" with no governance. Consequence: Codes diverge silently; integrations fail; reports are wrong; no one knows why.
Mistake: Adding a code in the source system without notifying downstream systems. Consequence: IDocs fail, APIs reject payloads, and business processes halt.
Mistake: Deleting deprecated codes instead of marking them deprecated. Consequence: Historical records lose meaning; reports break; audit trails are damaged.
Mistake: Maintaining mapping tables without ownership or review. Consequence: Mappings become stale; silent data corruption occurs.
Mistake: Allowing every system to maintain local extensions without documentation. Consequence: The "standard" code list becomes a patchwork; consolidation is impossible.

Agent instructions

When using this skill, an AI agent must:

Start with the failure. If an integration failed due to a code mismatch, name the exact code, the source system, and the target system. Do not generalize.
Inventory before harmonizing. Collect all code values from all systems before proposing a canonical set. Do not assume one system is correct.
Document drift precisely. List exact missing values, different descriptions, and different meanings. Do not write "codes are out of sync."
Design change control, not just codes. A canonical set without a change process will drift again. Always include request, approval, test, communication, and monitoring.
Produce artifacts, not advice. Output a Reference Data Inventory, a Canonical Code Set, and a Code Change Request in the templates provided.
Link to Atlas diagnostics. If reference data issues involve SAP, link to SAP Key Mapping Diagnostics or SAP IDoc Status Diagnostics.
Handle missing information. If code lists from some systems are unavailable, produce a collection checklist and ask the user to gather them.

Related skills

Data Integration & Interoperability — when reference data issues cause integration failures.
Master Data Management — when reference data is part of master data governance.
Data Governance — when reference data lacks ownership or change control.
Data Quality Root Cause — when a code mismatch needs root cause analysis.

Related Atlas pages

SAP Key Mapping Diagnostics — resolving key and code mapping issues.
SAP IDoc Status Diagnostics — when reference data causes IDoc failures.
SAP Master Data Quality — reference data as part of master data quality.
Data Quality Controls — controls for code validation.

Verification status and limitations

This skill is a public working interpretation of reference data management practice. It is not official DAMA-DMBOK or SAP documentation. It has been applied in SAP and multi-system integration contexts but may need adaptation for cloud-native applications, microservices with independent code lists, or heavily regulated environments.

Limitations: This skill does not cover advanced reference data platforms, semantic ontologies, or automated code synchronization tools. It focuses on governance, inventory, and change control suitable for project and operations contexts.