Month-end close in five days

Your close log is the cheapest system requirements document you will ever produce. Every journal you type by hand every month is an interface or a configuration rule you have not built, and the length of the close is the sum of those gaps. Measure it before you fix it, and before you buy anything.

Guide  ·  updated 2026-10-17

Define the finish line first

Three different events are called the close. Management numbers directionally right. The period locked for posting. The board pack issued. A company can do the first on day three, the second on day eight and the third on day twelve, and be honestly described as closing in three, eight or twelve days depending on who is asked. The advice written on this subject almost never says which of the three it is counting.

The unit is equally loose. Some published figures count calendar days, some count business days, and the pages quoting them rarely say which. That is the reason benchmark comparison does not work here, and it is a defect in the question rather than in anybody's bookkeeping: a figure that names neither the finish line nor the unit nor the size of company cannot be a figure you measure yourself against, however often it is repeated. This page therefore quotes no close-length benchmark at all. For the same reason it does not repeat the claim that a standard chart of accounts removes two days from the close: that number circulates widely with no traceable study behind it. The structural argument stands without it, in which chart changes are free and which are never reversible.

So write two lines down before measuring anything. Which event is the finish line. Calendar days or business days. Then compare your close only with itself, month over month. That comparison is the only one available to you that is honest, and it is also the only one that moves when you fix something.

The wait register

The advice on this subject starts with redesign: a new calendar, a new checklist, a tool. Start with instrumentation instead. For three consecutive closes, keep one row per close task with four fields.

• Start timestamp, when the work began, not when it was scheduled.
• Finish timestamp, when it was done rather than abandoned.
• Owner, one named person.
• Who or what you waited for. A name, a system, a document, or nothing.

The fourth field is the whole diagnostic. A finance team usually knows informally which handovers hold up every close, and knowing it informally is exactly why nothing changes. The register turns that from a grudge into a document with dates on it, which is the difference between a complaint and a requirement. One close is anecdote. Three is a pattern, and the pattern names a boundary where nobody owns the handover.

What each symptom indicts

Read the register against this table. The left column is the task that took too long. The right column is the person who can actually fix it, who is almost never in finance.

Each row is also a line in a future requirements document: an integration, an unowned module boundary, or a configuration rule. Three named boundaries are a better basis for a system scope than a feature list, and they make better demo scenarios that cross a boundary where two parts must agree about money already moved, because a boundary your own log indicts cannot be talked around.

Three causes, three different fixes

A long close is usually treated as one problem with one answer. It is three problems, and the register tells you which you have.

The consequence is uncomfortable. If most of your register entries are cause one, close software makes the wait visible and auditable without making it shorter. That is the same distinction between a process problem and a software problem set out in outgrown QuickBooks, or outgrown your process.

There is a political cause sitting under cause one, rarely named. Close length is created by departments that bear none of the cost of being late. Two mechanisms change that without a meeting. Name the wait in the close log, so lateness is attributed rather than absorbed. And charge the estimated accrual to the late department's own cost centre, so the estimate lands in their variance rather than a central account nobody reads.

The recurring-manual-journal test

List every journal entered by hand this close. Now mark the ones you typed last month and the month before. Anything you type every single month is a configuration gap with a name.

• A standing entry typed monthly is a recurring journal template you have not set up.
• A monthly split by headcount, floor area or revenue is an allocation rule.
• A monthly release of a billed-in-advance balance is a deferred revenue schedule.
• An accrual you reverse by hand on day one is an auto-reversing accrual.
• A monthly rent or lease split is a lease schedule.
• A monthly revaluation is an exchange-rate routine and a rate source.

Count them. That count, not the number of days, is the real backlog, and every line on it is a sentence you can put in a requirements list without a consultant's help.

A cut-off rule with teeth

Cut-off is described everywhere as a best practice and almost nowhere as a policy with consequences. A policy answers four questions.

When. Payables cut-off at close of business on the last calendar day of the period. Not when the post arrives.

What happens to the late invoice. An invoice for the prior period arriving after the cut-off is accrued if it exceeds the materiality line and booked to the current period if it does not. The decision belongs to the threshold, not the clerk, which is the point of writing the threshold down.

What closed means. Look for two period controls in your own system rather than one switch: a subledger closed to subledger entry while the general ledger stays open for adjusting entries. Dynamics, NetSuite, Sage Intacct and SAP each expose the two separately, under their own names, and the pair is what lets operational teams stop posting on day one while the controller keeps adjusting on day three. Write the policy in the names your system uses, because a policy that says only “closed” will be read as whichever control is easier to flip.

Who may reopen. A closed period reopens only for a restatement-level error. One named person, the controller, authorises it. Every reopen is logged with the reason and the entry it permitted. Then the diagnostic: more than one reopen a quarter means your cut-off is decorative, and the close length you are reporting is fiction, because the period is still moving after you declared it shut.

One threshold, used twice

Soft-close advice says skip immaterial items and never says what immaterial means. Set one figure, once, in writing, as a fixed percentage of monthly revenue or of pre-tax income rather than a round number that drifts. It is the controller's to set and the auditor's to see.

Then use it in both directions. Above the line, accrue, and chase what you need to accrue correctly. Below the line, do not accrue and do not chase. The second use saves the days, because chasing is what the register records as waiting.

One addition keeps this disciplined rather than sloppy. Items below the line go on a known and not booked schedule, one line each, carried into the next close. Nothing is forgotten, and the schedule is evidence the threshold was applied rather than used as cover.

The front-load list and the five days

Some close work does not need the period to have ended. It needs a rate, a schedule or a rule, and it can be computed and posted before day zero: depreciation, amortisation, recurring journals, prepaid releases, lease schedules, standing allocations, and exchange rates once published. None of it is on the critical path because the accounting requires it to be. It is there because nobody moved it, and moving it costs no software and no permission.

The parallelisation test

For every task on that calendar, ask one question. Does this task need a number another task produces, or merely the same underlying data? Only the first is a dependency. The second is a habit.

A close calendar can be serialised for two different reasons, and they have nothing in common. The accounting requires it, or one person does everything. Mark every task with which of the two applies, because the second kind cannot be shortened by software: either the work is split across more than one pair of hands, or the close stays as long as one person's working week, and no amount of configuration alters that arithmetic. A tool bought against that constraint buys a dashboard showing one person still doing everything. The same confusion between capacity and capability runs through where the cost curve breaks against headcount at 50 people.

The trade-offs nobody prices

Each of these improvements is presented as a free gain. Each has a cost, and the cost lands on a different team or in a different week from the benefit, which is why it goes unpriced. Four worth deciding explicitly rather than by default.

Metrics that are not days

Days are the headline and the worst single measure, because they improve when work moves later. Track five more.

• Post-close adjusting entries, count and value.
• Reopenings, per quarter, with reasons.
• Manual journals per close, and how many of them are recurring.
• Accounts whose reconciliation is a spreadsheet rather than a system match.
• Hours of close work completed before day zero.

Then the rule that makes the set worth keeping. A close that shortened while adjusting entries rose did not improve. It moved the error later. Two months of both numbers tells you which happened. Days alone never will.

§

When a long close is right

Five days is sold as a universal target. It is not. Where the binding constraint sits outside finance and cannot be removed without losing accuracy, the constraint sets the target.

• A third-party inventory count, or a warehouse run by someone else. The count date is the floor, and an estimate is not an improvement.
• Percentage-of-completion revenue that needs a project manager's sign-off. You can shorten the sign-off cycle. You cannot recognise progress nobody has confirmed.
• An external bookkeeper on a weekly cadence. Their calendar sets the floor, and changing it is a contract conversation.
• A foreign subsidiary consolidating in a different system and currency. Two closes, two calendars, one translation step between them.

In these cases publish two numbers: a soft-close date for management, and a later hard-close date for the record. Two honest dates beat one target quietly missed every month, and stating both forces you to say which of the three finish lines you meant.

What to do before you buy

No close-management tool and no system scope until three closes of wait-register data exist. Here is what each layer can and cannot do.

A scope written from a feature list is the first gate in the symptom lookup that runs each failure back to the gate that was skipped, and the reconciliations your close depends on every month are the same ones that have to tie before cutover, in the loading order and the reconciliations that must tie. If you can point at three boundaries your own log indicts, you are ready to have the conversation. If you cannot, you are about to pay someone to find them for you, using your register, which you have not kept.