Journal Entries & Estimates

"Fix it next month" is not a schedule

You find something wrong with a recurring entry while you're closing. Correcting this period's number and rebuilding the process that produced it are two different decisions — and only one of them can wait.

It shows up mid-close, usually in one of two ways.

You're rechecking a calculation in a workbook you've run for months and something doesn't tie the way it should. Or someone from another part of the business mentions something new in passing, and it becomes clear your process doesn't account for it yet.

Either way, the discovery lands in the middle of a close, when the schedule is fully committed and there is no room to reopen a process. So you do two things that look like one decision but aren't: you get the current period's number to the best-supported figure you can, and you set the actual rebuild aside for later.

Two different things get deferred, and only one of them should be

This is where the phrase "fix it next month" hides a distinction worth making explicit.

The amount in the current period. If what you found means this month's balance is wrong, that's not a process-improvement item. It's a misstatement question, and it gets evaluated on materiality rather than on whether there's time left in the close. Sometimes that means going back with the time you have and booking the best-supported number you can arrive at, even if it isn't the number a fully rebuilt process would produce. For SEC registrants, the materiality framework for identified misstatements is SAB Topic 1.M. The point is that "we ran out of time" isn't the test. Materiality is.

The process that produced it. Rebuilding the calculation, rescoping the report, restructuring the workbook — that genuinely can wait, and usually should. Close is time-boxed, dependencies are stacked, and a process change made under deadline pressure gets less scrutiny than the same change made deliberately.

Correct the number now if it needs correcting. Defer the rebuild. Collapsing those two into one decision is how a real misstatement ends up filed under "process improvement."

So the deferral that follows is the second kind: you've booked what you can support for this period, and what's left is making the process right so the same thing doesn't recur.

That deferral is reasonable. The problem is where it lands.

What the between-closes window actually looks like

Every other part of the cycle has structure. Close has a calendar, a task list, dependencies, and people waiting on outputs. Review has a sign-off. Reporting has a deadline.

The middle of the month has none of that. It's the window where process work is supposed to happen — fixing the calculation, updating the report, adding the new item to the schedule — and it's also the window most exposed to whatever else comes up. There's no forcing function, because nothing downstream breaks this month if the fix doesn't happen. The entry still posts. The close still completes.

Which means the deferred work competes against everything urgent, and it always loses that comparison honestly: nothing bad happens this month if it slips.

How it compounds

The same defect resurfaces at the same point next close. You notice it again, recognize it, and defer it again — for the same reason as last time.

Two things happen when that repeats.

The first is that it stops registering as a defect. It becomes a known quirk. Everyone who touches the entry knows to expect it, works around it, and no longer sees it as something to fix. The discovery gets absorbed into the process rather than resolved by it.

The second is more consequential, and it's the reason repeated deferral is worth treating differently from a single deferral. If the same item has been noted three times, the question stops being "when will we get to the process work" and becomes "has each of those periods been recorded correctly." A recurring defect that keeps getting deferred is, at minimum, worth a deliberate look at whether the amounts landed in the right periods along the way — and whether the effect, individually or accumulated across those periods, is large enough to matter.

Materiality governs the answer, and it won't be the same answer everywhere. But the count itself is information. A first deferral is a scheduling decision. A third one is a signal that something should be assessed rather than rescheduled again.

Why this is worse for the things you find yourself

A defect someone else raises has a second person aware of it. There's an implicit follow-up, even if nobody schedules one: the person who flagged it may ask about it.

Something you find in your own workbook has no such backstop. You're the only one who knows, the note is in your own file or your own head, and there's nothing external creating pressure to close it out. The findings most likely to disappear are the ones you caught yourself, which is the opposite of what you'd want — those are usually the ones you understand best and could fix fastest.

What helps, concretely

The useful move is to give deferred items the one thing they're missing: a place that persists and gets looked at.

Write it where you'll see it during the next close, not just where you'll see it later. A note in the workbook itself, at the point where the defect appears, resurfaces exactly when it's relevant. A note in a separate list gets read only if someone remembers the list exists.
Capture the reason, not just the symptom. Two weeks later, "check the accrual calc" means much less than a sentence saying what specifically looked wrong and what you'd already ruled out. The version you write while you still understand the problem is worth more than the version you reconstruct later.
Record when you first noticed it, and count the deferrals. A date makes the pattern visible. An item carried across three closes is a different thing from one carried across one — not just older, but a prompt to check whether each of those periods was recorded correctly rather than to reschedule it again.
Do the small ones immediately after close, not later in the month. The window right after close ends is the closest thing to protected time this work gets, and the problem is still fresh.

None of this is a control. It's bookkeeping about your own bookkeeping, and it works only to the extent you actually revisit it. But the alternative — carrying deferred fixes in memory across a month that's designed to fill up with other things — is where these quietly go.

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.