Journal Entries & Estimates

The report was right when it was built. That's the problem.

A report scoped to a specific list of accounts, vendors, or items doesn't fail loudly when the business adds a new one. It just doesn't include it — and everything downstream still looks complete.

A recurring journal entry usually starts with a report. Pull activity for a defined set of accounts, or vendors, or items, run it into a calculation, post the entry. The report's scope — which accounts, which categories, which population it's pulling — was correct when someone built it.

It stays exactly that scope forever, unless someone deliberately changes it. Which means when the business adds something new — a new account, a new vendor relationship, a new item that belongs in that same process — the report doesn't reject it. It just doesn't know it exists. The report was never wrong. It was scoped to a business that has since changed shape.

Why this is quiet

The report still runs. The calculation still completes. The entry still posts, and it looks exactly like it always has — because from the report's point of view, nothing changed. The only thing that changed is outside its field of view entirely.

A rule that evaluates something and excludes it leaves a trace. A report that never knew something existed leaves nothing. There's no rejected line to notice, because there's no line at all.

This is a different failure than a threshold or calculation being wrong. A miscalculated number is usually visible somewhere — it produces a variance, or fails a check, or looks odd against something else. A silently narrow population doesn't produce a wrong number. It produces a number that's internally consistent and simply incomplete, which is much harder to catch by looking at the output alone.

Where the gap actually opens

Almost always at the boundary between two things: something changes in one part of the business, and nobody connects that change to a report or process maintained somewhere else.

A new account gets added to the chart of accounts for an unrelated reason, and nobody thinks to check whether it should feed into an existing recurring calculation. A new vendor relationship starts, and the person setting it up isn't the person maintaining the report that would need to include it. A new item gets added to whatever population the business tracks — and the update happens in the system that manages that population, not in the report built to summarize it.

None of this requires anyone to make a mistake in the moment. It requires two things to be true at once: the change happens somewhere, and nobody in that moment is thinking about every downstream report that assumes a static population. Most of the time nobody could reasonably be expected to make that connection. That's exactly why it's a structural gap rather than a lapse in diligence.

How it usually actually gets caught

Rarely from inside the process itself, because the process has nothing to compare itself against. It's usually caught one of two ways, and both are social rather than systematic.

A reviewer notices it from somewhere else. Someone sees an update reflected in a different report, a different system, or a different conversation, and realizes it hasn't shown up in this one. That requires the reviewer to be tracking more than just this entry — connecting something they happened to see elsewhere to a gap in what's in front of them.

Someone outside the process notices an absence. A different department flags that something expected to happen didn't — a payment that should have gone out, an amount that should have been recorded — and tracing it back reveals the report never had that item in scope. The person who surfaces it usually isn't the person who prepares the entry. They just noticed the entry's effect was missing from the world.

Both routes depend on someone being sufficiently in tune with the surrounding business to make a connection the report itself can't make. Neither is dependable, and neither happens on a schedule.

Why this is worse than a threshold missing something

Elsewhere on this site, the point is made that a variance threshold can't flag an account that didn't move, because the review is built around movement. This is the layer underneath that. Before a threshold ever gets a chance to evaluate anything, the source report has already decided what exists to be evaluated — and anything outside that scope never enters the calculation at all. A threshold missing something is a review-design gap. A report missing something is a data-population gap, and it happens one step earlier, with no downstream check positioned to catch it.

What actually helps

Not more scrutiny at the calculation stage — the calculation is usually fine. What helps is a deliberate, periodic check of whether the report's population still matches the business, done separately from running the report itself.

Practically, that means occasionally asking a different question than the one asked every month. Not "does this calculation look right," but "has anything been added to the business since this report was built that should be flowing through it." That's a population question, not a math question, and nothing about preparing the entry monthly naturally prompts it.

It also means treating changes elsewhere in the business as a trigger worth checking against, rather than assuming someone would have said something if a report needed updating. Usually nobody thinks to say anything, because the report isn't the first thing that comes to mind when something new gets set up somewhere else.

Most of this surfaces again at flux review. The free flux template flags which balances moved enough to explain. The CloseOps Flux & Variance System ($79) starts from your trial balance instead: confirm each account's classification and it builds the income statement and balance sheet flux statements, then ranks what to investigate.

Found something wrong or missing? Tell me here — anonymous, thirty seconds.