Your Completeness Controls Are Probably Failing You, and Here's Why

Back to Topics

Most completeness controls fail at design for one reason: they examine the transactions that exist without establishing whether all of the transactions that should exist are actually there.

If your controls only determine whether individual transactions are accurate and valid, they may never tell you whether something is missing entirely.

That distinction sounds simple.

In practice, it creates one of the easiest blind spots to overlook in control design.

Why It Matters

The U.S. Government Accountability Office's Standards for Internal Control in the Federal Government identifies three information-processing objectives when management designs transaction control activities: completeness, accuracy, and validity.

According to GAO's 2025 Green Book, Principle 10, §10.18:

Accuracy and validity are relatively intuitive.

Completeness is different.

The problem is that we often use "complete" conversationally to mean that everything on a transaction has been filled out correctly.

But that's not necessarily the same question the completeness objective is asking.

A transaction can contain every required field and still exist within an incomplete population.

That distinction can create a blind spot — and false confidence in control design. Sometimes those weaknesses aren't discovered until a fresh set of eyes examines the control.

The Argument

Completeness Requires Looking Beyond the Transaction

When you review an individual transaction, you can determine a great deal about it. Is the amount correct? Was the activity properly recorded? Did the transaction actually occur? Was it appropriately authorized? Those questions can provide evidence about the accuracy and validity of the transaction you are reviewing.

But they cannot, by themselves, tell you whether another transaction is missing entirely.

That's the fundamental challenge with completeness: you cannot examine something that isn't there.

Completeness Often Requires an Independent Point of Comparison

When transactions originate in one system and interface into another, reconciliation can become a powerful completeness control. The concept is straightforward. Compare what should have moved from the source system against what actually arrived in the receiving system. If the populations do not reconcile, something requires investigation.

If one of your daily interfaces failed to run, would you notice?

That's one of my favorite questions when evaluating an interface. If the answer depends on someone eventually noticing that a report looks strange, the control may not be as strong as you think.

Field-Completeness Checks Don't Prove Population Completeness

Many organizations have controls that confirm required fields on a transaction are populated and describe those controls as completeness controls. There is nothing inherently wrong with checking required fields — it can be an important data-quality control. But consider what the control actually proves. It evaluates a transaction that already exists. A blank field may indicate a problem with the information captured on that transaction. It tells you nothing about a transaction that never entered the system.

Having complete information about the records you possess does not prove that you possess all the records you should.

The Objection Worth Taking Seriously

A reasonable pushback is: "If I check every field on every transaction, and I review every transaction that comes through, doesn't that catch missing records too?"

Not necessarily.

The reason is structural rather than semantic.

Transaction reviews examine the population available to you. A completeness gap may exist outside that population.

No amount of scrutiny applied exclusively to the records already in the system can independently establish that something never entered the system in the first place.

You need another point of reference. That might be a source system, an independent record, an expected population, or another control capable of establishing what should have occurred.

In many financial processes, that's exactly what a well-designed reconciliation provides.

A Simple Example

Suppose an agency records capitalized property in a property system and that information interfaces automatically with its financial system.

You can review every asset record in the financial system for accuracy. Every amount could be correct. Every field could be populated. Every transaction you inspect could appear perfectly reasonable.

None of those procedures, by themselves, tell you whether Tuesday's interface actually ran.

A reconciliation between the property system and the financial system can provide evidence that the expected population moved between the two environments — for example, by comparing relevant record counts and dollar balances.

But even that control has a boundary.

A reconciliation can only establish completeness between the populations being compared. If an acquisition was never captured in the property system in the first place, the property system and financial system could still reconcile perfectly.

And that's exactly why understanding what your control actually proves matters.

The Ask

Completeness controls should force you to ask a different question.

Not simply: "Is this transaction right?"

But: "Is anything missing?"

Those are different questions, and they may require different controls.

Take an hour this month and look specifically at the controls your organization identifies as addressing completeness. For each one, ask: does this control provide evidence that everything that should have been recorded was recorded — or does it only tell me that the records I already have look right?

The difference may seem small.

From a control-design perspective, it isn't.

The views expressed in this article are those of the author and do not necessarily reflect the views of any employer, client, agency, or organization. Examples referenced are intended to illustrate broader internal control design concepts.