+150 XP

Master data and reference data in utilities: assets, meters, and customers

A transformer gets replaced in the field. The crew logs it in the mobile work order app with asset ID TX-4471. Back in the office, the Geographic Information System (GIS, the mapping database that tracks where every pole, line, and transformer physically sits) still shows the old unit under ID TX-4471-A. The billing system, pulling meter-to-transformer relationships to calculate line losses, can't reconcile the two. Six months later, a reliability report flags "phantom" outages on a transformer that no longer exists, while the real one, invisible to the outage management system, keeps tripping. Nobody notices until a customer complaint traces it back.

This is what happens when master data breaks. This lesson covers what that data actually is, how utilities keep it clean, and the metrics that tell you whether it's working.

What master data means in utilities

Master data is the core, relatively stable data that describes the entities a business runs on: not transactions, but the things transactions happen to.

In utilities, three master data domains matter most:

  • Asset data: poles, transformers, substations, pipelines, meters, generation units. Lives primarily in GIS and CMMS (Computerized Maintenance Management System, which schedules and logs inspections and repairs).
  • Meter data: device identifiers, install dates, meter-to-premise links, and increasingly, interval data from AMI (Advanced Metering Infrastructure, the smart meter network that reports usage every 15 to 60 minutes).
  • Customer data: account holders, service addresses, rate classes, contact and billing details, typically housed in the CIS (Customer Information System).

Reference data is different: it's the standardized code sets these systems share, like voltage class codes, outage cause codes, or rate schedule identifiers. Reference data is what lets asset data from GIS mean the same thing as asset data in the CMMS.

The problem in the hook is a master data key mismatch: the same real-world transformer exists under two different identifiers in two systems that were never properly linked.

Where this data lives and why it fragments

Utilities typically run 5 to 15 systems that all claim a piece of the same physical or customer reality:

SystemOwnsTypical vendor examples
GISAsset location, network topologyEsri, Schneider Electric
CMMS/EAMMaintenance history, asset conditionIBM Maximo, SAP EAM
AMI head-endMeter reads, device statusItron, Landis+Gyr
CIS/billingCustomer accounts, rate plansOracle Utilities, SAP IS-U
OMSOutage events, restorationVarious, often integrated with GIS

Each system was procured separately, often decades apart, by different departments. GIS teams model the network as engineers see it. CIS teams model it as billing needs it. Nobody owns the translation layer by default, which is exactly why master data management (MDM) exists as a discipline: to designate one authoritative "golden record" per entity and govern how every other system references it.

The governance metrics that catch the problem

You cannot manage what you don't measure. Four metrics dominate utility MDM programs:

1. Match rate: the percentage of records across two systems that can be automatically linked to the same real-world entity using matching rules (exact ID, or "fuzzy" matching on name plus address plus geolocation).

*Worked example*: A utility has 2.1 million meters in AMI and 2.05 million premise records in CIS. An automated matching routine links 1.968 million pairs with high confidence.

Match rate = 1,968,000 / 2,050,000 = 96.0%

The remaining 4% (about 82,000 records) need manual review or field verification. That's not a rounding error; each unmatched record is a potential billing dispute or missed connection.

2. Duplicate rate: the share of records in a single system that represent the same entity more than once. Common cause: a customer moves within the same utility's territory and gets a new account instead of an updated one, or a field crew creates a new asset record instead of updating the existing one after a mid-life asset swap.

Industry MDM benchmarks across large enterprises commonly cite duplicate rates in customer databases of 5% to 15% before cleanup, dropping to under 2% after a mature MDM program is in place. These are general enterprise data-quality estimates, not utility-specific published figures, so treat them as directional.

3. Golden record coverage: the percentage of entities (assets, meters, customers) that have a single, designated, trusted master record that all downstream systems reference, as opposed to conflicting versions across systems.

4. Data quality dimensions, scored per attribute, typically including:

  • *Completeness*: is the field populated (e.g., every transformer has a manufacture year)?
  • *Accuracy*: does the value reflect reality (correct GPS coordinates)?
  • *Timeliness*: how stale is it (was the meter's install date updated within 24 hours)?
  • *Consistency*: does the same asset have the same voltage rating in GIS and CMMS?

A useful reference for how these dimensions are formally defined is the DAMA-DMBOK data quality framework, widely used as the baseline vocabulary for enterprise data governance, including in utilities.

Why this cascades into money and safety

Go back to the transformer mismatch. Concretely, it causes:

  • Billing errors: line-loss calculations misallocate costs across customers on the wrong transformer, distorting cost-of-service studies used in rate cases before state Public Utility Commissions (PUCs) in the US, or National Regulatory Authorities (NRAs) in Europe.
  • Reliability blind spots: SAIDI and SAIFI (System Average Interruption Duration/Frequency Index, the standard US reliability metrics reported to regulators) get calculated against the wrong asset, understating true outage exposure on the real transformer.
  • Safety risk: a crew dispatched to "de-energize TX-4471" for maintenance may isolate the wrong physical unit if GIS and the switching order system disagree.
  • Failed AMI integration: smart meter data cannot be aggregated correctly to the feeder or transformer level for load forecasting or grid modernization investment decisions, undermining the business case for grid-edge analytics.

A minimal matching logic example

Utilities often start deduplication with deterministic rules before layering in probabilistic matching. A simplified rule in pseudocode:

python
def match_asset(gis_record, cmms_record):
    if gis_record.asset_id == cmms_record.asset_id:
        return "exact_match"
    if (gis_record.gps_lat, gis_record.gps_lon) == (cmms_record.gps_lat, cmms_record.gps_lon) \
        and gis_record.asset_type == cmms_record.asset_type:
        return "probable_match_geo"
    if fuzzy_ratio(gis_record.description, cmms_record.description) > 0.85:
        return "probable_match_text"
    return "no_match"

Records landing in no_match or probable_match feed a manual stewardship queue, the human-reviewed backlog that every mature MDM program tracks as a workload metric in its own right.

Knowledge check

1. In the transformer scenario, the core problem was that GIS and the mobile work order app disagreed on the asset ID for the same physical unit. What category of data problem does this illustrate?

2. Which of the following best distinguishes reference data from master data in a utility context?

3. A utility wants to calculate accurate line losses by relating meters to the transformers they're served by. Which underlying condition is most critical for this calculation to work correctly?

MULTIPLE CHOICE

4. Select ALL correct answers about the three master data domains described for utilities.

Select all the correct answers.

MULTIPLE CHOICE

5. Select ALL correct answers about why the mismatched transformer IDs caused downstream problems described in the scenario.

Select all the correct answers.

Benchmarks worth anchoring to

Published, utility-specific MDM benchmarks are scarce (vendors rarely disclose client-level figures), so use these as industry-estimated ranges, not verified sector averages:

  • Match rates above 95% between GIS and CMMS are considered a mature program; many utilities starting MDM initiatives report initial match rates in the 70% to 85% range before cleanup, as commonly discussed in utility IT case studies and MDM vendor whitepapers (estimate).
  • Golden record coverage targets of 90%+ for customer master data are typical program goals in enterprise MDM rollouts (estimate, general enterprise benchmark, not utility-specific).
  • Data quality remediation projects in asset-heavy industries typically take 12 to 36 months to move from fragmented multi-system records to a governed single source of truth, per general MDM implementation literature.

Always ask, when you see an MDM benchmark cited: what's the source, what industry, and what year?

Key Takeaways

  • Master data (assets, meters, customers) is the stable core data utilities run on; reference data is the shared code sets (voltage classes, outage causes) that let systems agree on meaning.
  • A single mismatched identifier between GIS and CMMS can cascade into billing errors, distorted SAIDI/SAIFI reliability metrics, and safety risk during field switching.
  • Four core governance metrics to track: match rate (records correctly linked across systems), duplicate rate (redundant records within one system), golden record coverage (entities with one trusted master), and the four data quality dimensions (completeness, accuracy, timeliness, consistency).
  • Worked example: 1,968,000 matched pairs out of 2,050,000 CIS premise records yields a 96% match rate, the level generally associated with a mature MDM program.
  • Treat all MDM benchmark percentages as estimates from general enterprise or vendor sources unless a utility or regulator has published its own figures; always check source and recency before citing them.