Every Chief Data Officer (CDO) owns a data quality scorecard. Completeness of fields, validity of values, duplication rates, master data conformance: the metrics are mature, the tooling is established, and the numbers mostly trend green.

Here is what has troubled me across more than 15 years inside enterprise ERP implementations: the most expensive data failures I have personally encountered never appeared on those scorecards. They could not, because the scorecards measure the records that exist. 

The failures that cost the most, in my experience, were records that should have existed and were never created. Gartner research estimates that poor data quality costs organizations at least $12.9 million per year on average.  The process-level gaps I am describing sit outside even that accounting, because nothing measures them.

Three questions expose the gap. In the organizations I have worked with, few data teams could answer any of them on the first ask.

Question 1: Did every document our processes promised actually get created?

Enterprises run on document chains:

• Order → delivery
• Delivery → invoice
• Goods receipt → supplier bill
• Return → credit

Every arrow in that chain is a place where money is supposed to move. And every arrow can silently fail.

Let me describe a pattern I have seen repeatedly, anonymized from real implementation work. A manufacturer runs its quoting and ordering through a front-end sales platform integrated with the core ERP. A new customer is created in the front-end system, and the quote and order process smoothly. But the customer master in the ERP is incomplete: the financial views, tax details, or payment terms that billing depends on were never fully replicated. The integration may have published the transaction before the master data finished syncing, or an update succeeded locally while the notification to the ERP was lost in transit. 

The orders process. Deliveries ship. Every individual record passes validation. And the billing documents those deliveries were supposed to trigger quietly never get created.

Why did the organization’s existing controls not catch it? Because the controls that exist are periodic and person-dependent. Open-order and open-delivery reports get reviewed when someone remembers to run them. Credit checks block transactions correctly, but the blocked items age while awaiting a manual release that competes with everything else on someone’s desk. The gaps live in the time between check-runs, and the scorecard was green the entire time.

What finally surfaced these cases, in my experience, was never a data quality alert. It was reconciliation pressure: a financial close that would not tie out, an aging report that raised questions, a customer asking why they had never been billed. Detection by accident, months late, with the value already stranded.

Answering this question systematically requires a different measurement: reconstructing document flows end to end and checking every promise against what materialized. In my view, completeness at the business-process level belongs on the CDO scorecard next to the classical record-level dimensions. One practical measure is a process completeness rate: the share of initiated flows that produced every expected downstream record within its window, tracked alongside accuracy and freshness.

Question 2: Who owns the gaps between our data domains?

Ask who stewards customer master data, and a name appears. Ask who stewards billing data, and another name appears. Now ask who owns the promise that every completed shipment produces an invoice.

In the organizations I have worked with, that question is usually met with silence, because cross-domain promises rarely have an owner.

The reason is structural. Data ownership follows system ownership, and every steward can certify their own domain as complete. The chain running through three domains is not a dataset, so it appears on no ownership map. When it breaks, each team’s view stays internally consistent, each dashboard stays green, and the gap becomes nobody’s row on nobody’s report. I have watched a front-end team, an ERP team, and a finance team each demonstrate, correctly, that their own data was fine, while the value leaked in the handoffs between them.

The gap between data domains is a leadership problem before it is a technology problem, and the CDO is its natural owner. Three moves make that ownership practical: 

• Inventory the promises. Document which record commits the organization to which next record, and within what window. Most enterprises I have encountered have never written this list down; the knowledge lives with senior process people and surfaces only during audits and disputes.
• Name the seams. Treat cross-domain document flows the way modern data organizations treat data products: assign each a named owner with explicit accountability for the gap itself, regardless of which team’s process caused it. 
• Report absence in currency. A missing invoice is not a quality percentage. It is a specific amount, and in my experience, findings denominated in money change executive conversations in ways quality scores never have.

Question 3: Is our data complete enough for the AI we are deploying on it?

AI initiatives now touching enterprise data carry a quiet assumption: that the data tells the whole story. Copilots summarizing receivables assume the receivables are all recorded. Agents drafting decisions assume the document flows are whole.

Whether an AI system can recognize that something is missing depends on what it has been given. A system with access to encoded process rules, cross-system context, or explicit expectations about document flows may well flag a gap. But in the deployments I have observed, most systems are grounded on the records that exist, without a representation of the records that should exist. Given incomplete chains and no encoded expectations, such a system will fluently describe whatever is present, and the description will be confident, coherent, and partial.

The practical implication for data leaders is not that AI fails on incomplete data, but that AI readiness deserves one more question than it typically gets. Assessments today ask whether data is clean, governed, and accessible. Adding a process-level completeness check tells you which questions your AI can be trusted to answer and which it cannot yet. Ask:

• Are the flows this system will reason over actually whole?
• Does the system have the context to know when they are not?

Start with one flow, and treat it as a diagnostic 

Process-level completeness does not diminish the importance of the classical quality dimensions. Clean, conformant, well-stewarded records remain the foundation. The argument, drawn from years of watching green scorecards coexist with real losses, is that the foundation has been mistaken for the whole building.

A practical starting point: pick one flow (order-to-cash is a natural candidate) and reconcile the chain end to end for a recent quarter. Count what never got created. Whatever the exercise surfaces, treat it as a diagnostic rather than a windfall. The findings will show you:

• Where your process gaps concentrate
• Which master data and integration root causes drive them
• Where ownership of the seams is missing

That map, in my experience, is the most useful artifact a data leader can bring to a conversation about where the data program goes next.