What Is Enterprise Data?
(And Why Should You Care?)

 

By Greg Briscoe, Senior Solution Architect — Enterprise Data Management

 

Most organizations can’t agree on what “enterprise data” actually means, which is a significant part of the problem. Ask the CFO, and you’ll hear about the chart of accounts. Ask IT, and you’ll hear about master data management. Ask the data warehouse team, and you’ll hear about dimension tables. Ask the planning team, and they’ll show you their member lists. Everyone’s right. Nobody’s aligned. And if you can’t define it, you can’t govern it.

I’ve watched organizations spend months building data governance programs without ever settling on a shared vocabulary. The result is predictable: governance that means different things to different teams, technology decisions made against different requirements, and a platform that solves one group’s problem while ignoring everyone else’s. So let’s fix the vocabulary first.

 

The Definition That Works

Here’s the definition I use in every engagement, because it’s precise enough to be actionable and broad enough to be complete:

 

Enterprise data encompasses the measures of value. How an organization classifies and measures value across the enterprise. It’s how you slice and dice reports: by customer, by product, by entity, by region, by cost center. Enterprise data must be shared and aligned across applications, functions, systems, and platforms. It includes hierarchies, attributes, mappings, and reference data.

 

Notice what that definition does not say. It doesn’t say “transactional data.” It doesn’t say “the data in the GL.” Enterprise data is the structural data — the scaffolding that gives transactional data meaning. A journal entry is transactional data. The chart of accounts segment that tells you what that journal entry represents? That’s enterprise data. The hierarchy that rolls it up into a reporting line? Enterprise data. The cross‑reference that maps it from the legacy system to the target? Enterprise data.

This is the data that determines whether your reports reconcile, whether your close cycle runs on time, and whether your consolidation actually consolidates. It’s the most important data in the enterprise, and in most organizations, it’s the least governed.

 

Four Categories, One Platform

Enterprise data isn’t monolithic. It falls into four distinct categories, each with different governance requirements, ownership models, and change frequencies:

 

Category	What It Includes
Financial Data	Charts of accounts, legal entities, business units, cost centers, intercompany segments, product lines, project codes — the structural backbone of financial reporting and compliance.
Business Data	Sales territories, companies, locations, customers, vendors, employees — the operational dimensions that drive business process and CRM/ERP functionality.
Analytical Data	Dimension member lists, alternate rollups, cross‑dimensional mappings, intercompany elimination structures — the reporting and planning scaffolding that EPM and BI depend on.
Reference Data	Type codes, value sets, market segments, geographic codes, industry taxonomies, currency codes — the lookup values and classifiers that standardize data across systems.

 

The critical insight is that these four categories are inter‑dependent. Your financial chart of accounts references your entity master. Your analytical hierarchies roll up financial and business dimensions. Your reference data codes classify everything else. Governing them in isolation — which is what most organizations do by default — guarantees misalignment.

 

Five Types EDM Manages

• Application Metadata: Structural definitions for dimensions, segments, and attributes in downstream applications — the templates that define what data can exist and how it’s structured.
• Reference Data: Standardized code sets, type classifications, and lookup values shared across applications.
• Master Data: Authoritative records for core business objects — customers, vendors, products, employees, entities.
• Data Mappings: Cross‑references and transformation rules between systems — the glue that holds multi‑system environments together.
• Hierarchies: Reporting structures, organizational rollups, and dimensional relationships that give flat data meaning.

 

Why This Matters

The reason your consolidation doesn’t reconcile, your planning models don’t align with actuals, and your reporting takes three weeks to close isn’t a system problem — it’s an enterprise data problem.

I’ve seen organizations implement world‑class ERP platforms and still struggle with fifteen‑day close cycles because the chart of accounts in the GL doesn’t match the dimension structure in the planning tool, which doesn’t match the hierarchy in the consolidation system, which doesn’t match the segments in the data warehouse.

Governing enterprise data means governing the structural foundation that every financial and analytical application depends on. Get that right, and everything else gets easier. Get it wrong, and no amount of application spending will fix the downstream symptoms.

 

Enterprise data isn’t the data in your systems. It’s the structural scaffolding that makes the data in your systems meaningful. When the scaffolding is misaligned, every report, every close, and every transformation inherits the misalignment.

 

Next: The five‑step MDM process that turns this chaos into a governed operation.