How to measure when your month-end close actually finished

Your close finished when value stopped moving into the period, which is almost never the day you signed off. Sign-off is a decision someone makes on a calendar. Whether entries kept landing against that period afterwards is a separate question, and it has an answer sitting in your ledger right now: every journal carries both the period it hits and the moment it was keyed. The gap between those two dates is the only unflattering measure of a close there is.

Why is the six-day close benchmark unreliable?

The benchmark is unreliable because it is self-reported, roughly nine years old, and quoted inconsistently by nearly everyone who cites it. Almost every close-timing figure in circulation traces back to a single APQC benchmarking survey of around 2,300 organisations, which measured cycle time in calendar days from running the trial balance to completing consolidated financial statements. That study is variously reported as a median of six days, 6.4 days, and eight days, depending on which article you read — the same survey, three different numbers.

The deeper problem is not the age or the inconsistency. It is that the figure was self-reported. Asking a finance team how long its close takes measures the point at which the team considered itself finished. It cannot capture the accrual someone posted three weeks later, the reclass that landed after the board pack went out, or the supplier invoice that arrived in the following quarter and was correctly dated back. Those entries change the period after everyone agreed the period was done, and a survey has no way of seeing them.

This matters more for groups than for single companies. A survey response describes one team’s impression of one process. A group running fifteen entities has fifteen closes feeding one set of numbers, and the group’s real completion date is set by whichever entity finished last.

Which two dates tell you when a period really settled?

Every journal in Xero carries a journal date, which is the period the entry hits, and a creation timestamp, which is when someone actually keyed it. Subtract one from the other and you have posting lag: how long after the period it belongs to an entry was recorded.

Posting lag is worth measuring for three reasons.

It requires no new process. Nobody fills in a form, updates a status board, or remembers to stop a clock. The measurement is a byproduct of work the team was doing anyway, which means it costs nothing to adopt and cannot be gamed by anyone wanting the number to look better.

It is immutable in the right way. The creation timestamp records when the entry first existed, not when it was last touched. A correction posted in March against January’s numbers shows up correctly as a January entry recorded sixty days late, rather than being quietly reclassified as recent activity.

It is weighted by value, not just count. Fifty small coding corrections arriving late tell you little. One large accrual arriving late tells you the period’s result changed after publication. Counting entries and summing absolute values give different answers, and the value view is the one a CFO should look at.

A caveat worth stating plainly: because entries can arrive at any time, the current period’s posting lag is always incomplete. A month that is two weeks old will look far better than it eventually turns out to be, simply because the late entries have not arrived yet. Any figure for a recent period is provisional by construction, and comparing a recent month against an old one will always flatter the recent one.

What does late value actually look like once it is measured?

The pattern that emerges when you plot it is not a single number but a curve. Value arrives steeply in the days immediately after period end, then continues to trickle in for weeks. The interesting question is not where the curve starts but where it flattens — the point past which additional entries stop meaningfully changing the period’s result. That flattening point, not the sign-off date, is when the close actually finished.

For most groups the two dates are further apart than anyone expects, and the gap is largest exactly where it matters most: at financial year end, when the entries arriving late are the material ones.

Which entity is holding up the group close?

The group close is gated by its slowest entity, and a group-level average hides which one that is. This is the question posting lag answers that nothing else does, and it is the reason the measurement matters more for a group than for a standalone company.

A group figure of, say, seventy percent of value landing within five days sounds tolerable. Split by entity, it often turns out that twelve entities are at ninety-five percent and three are at thirty, and that it is the same three every month. That is a different problem with a different fix. The group number suggests a process improvement programme. The entity split suggests a conversation with three specific bookkeepers, or a look at whether those entities are under-resourced, or the discovery that one of them depends on a supplier who invoices six weeks in arrears.

Rank stability is the detail that turns this from an observation into an action. If the slowest entities rotate month to month, you have normal variation and nothing to fix. If the same entities sit at the bottom every period, you have a structural problem that a faster group-level process will never solve, because the group was never the bottleneck.

Does measuring posting lag replace an audit or internal controls?

No. Posting lag is a detective measure, not assurance. It tells you that entries arrived after a period was considered closed; it does not test whether your controls are designed correctly, whether the entries were authorised, or whether the numbers are right. It shortens the distance between something slipping through and somebody noticing, which is useful and is not the same thing as an audit opinion.

It is also silent on causes. A long lag might mean a disciplined team correctly dating a late supplier invoice back to the period it belongs to, which is good accounting. It might mean a team that closes on paper and keeps posting for a month, which is not. The measurement tells you the period kept moving. Working out why is still a human job.

Treat it as an instrument, not a verdict. Its value is that it is observed rather than asserted, and that it is uncomfortable in a way self-reported figures never are.

How do you measure posting lag in your own Xero entities?

You can do this yourself without buying anything, and for a small group it is genuinely worth an afternoon.

Pull the journals for each entity from Xero’s Journals endpoint, which returns both the journal date and the creation timestamp for every entry. For each journal line, calculate the days between period end and the creation timestamp — entries created before period end simply count as zero. Sum the absolute value of the lines rather than the net, since net movements cancel to roughly nothing.

Then apply the discipline that makes the result trustworthy: only compare periods of the same age. Take periods that ended at least twelve months ago, so every one of them has had a full year to accumulate late entries, and plot the cumulative proportion of value landed by day five, fifteen, thirty, sixty, ninety and one hundred and eighty. Comparing a period from last month against one from two years ago will always show apparent improvement, and that improvement is an artefact of the recent period not having finished arriving.

Do this per entity, not just for the group, or you will miss the finding that matters.

If you would rather not build it, APBuddy’s close controls compute posting lag continuously across every connected Xero entity, alongside duplicate journal detection, missed recurring entries and amount outliers. The mechanics above are the same either way — the measurement is not proprietary, and a group that builds it in a spreadsheet learns exactly as much as one that buys it.