Designing a Close Calendar for the Company You Actually Have

A close calendar is the output of a dependency map. It is not a template, and the reason a borrowed one falls apart in the first month is not that it was written for a bigger company. It is that its rows describe somebody else’s suppliers, somebody else’s systems and somebody else’s people, and roughly a third of them are inapplicable to you while an entirely different third is missing.

The published month-end close checklist is the finished artefact, day by day, with owners against every task. This piece is the method that produces one. If you already have a calendar that works, you do not need this. If you have one that keeps slipping, the slip is almost always a dependency that was never mapped, and no amount of chasing fixes a sequencing error.

The claim, stated up front so the rest of this can be checked against it: you shorten a close by removing dependencies, not by working faster. Every close remediation that starts with “we need to be more disciplined” ends where it started. Every one that starts with “what are we waiting for, and why” gets somewhere.

Map the dependencies before you write a single day

Four steps, in this order, and the order is not negotiable because each step is built from the output of the previous one.

Step one: list the outputs

Start at the end. What actually leaves the finance function at the end of a close?

Write them down individually rather than as “the reporting pack”, because they have different dependencies and some of them can be issued at different times. A typical list at this size: the statements with comparatives, the variance commentary, the cash summary, the receivables and payables aging, the covenant calculation if you have lending that requires one, the departmental reports if managers get them, and whatever the owner personally reads first.

Then do the thing that makes this step useful. Against each output, write who receives it and what they do with it. An output nobody acts on is a candidate for removal, and removing an output removes its dependencies, which is the cheapest possible way to shorten a close.

Step two: work backwards to inputs

For each output, ask what has to be true before it can be produced. Then ask the same question of each of those answers. Keep going until you reach something that arrives from outside the finance function.

The chains are shorter than people expect. Statements require a locked trial balance, which requires the balance sheet reconciliations complete, which require the sub-ledgers agreed and the bank data in. Variance commentary requires the statements and the owners of the lines. The covenant calculation requires the statements plus whatever definitions the agreement uses, some of which need information nobody else in the close needs.

Two things fall out of this step reliably. The first is at least one output whose chain includes something nobody had noticed was a dependency, usually a schedule maintained by one person outside finance. The second is at least one task in the current calendar that no output depends on at all. Both are worth the exercise on their own.

Step three: name the supplier of every input, including the ones outside the company

Every input at the end of a chain has a supplier and the supplier is a person or an organisation, never a system. “The bank feed” is not a supplier. The bank is, and the bank has a schedule.

This is the step that sets your floor, and it is the one that copied calendars get wrong most damagingly, because external suppliers are exactly the thing that differs between two companies of the same size. Payroll registers arrive when your provider produces them. Merchant and payment processor settlement reports arrive on their own cycle. Statements for some accounts arrive later than others. A landlord’s variable charge might arrive in the second week or in the following quarter. A subcontractor’s invoice arrives when they get to it.

For each external input, record two things: the earliest it can arrive, and how reliably it does. Then draw a line on your map at the latest of the earliest arrivals. Nothing downstream of that input can be scheduled before it, and no discipline programme will change that.

The internal suppliers matter for a different reason. Cut-off information, timesheets, expense claims, job costing entries and stock counts all come from people whose main job is not this. They will be late, not because they are unreliable but because your close is not their priority, and a calendar that treats them as though it were will fail every month and blame them.

Step four: find the critical path and read what it says

The critical path is the longest chain from the first thing that can start to the last output. It is the only part of the calendar whose length actually is the length of your close.

It is almost never the bank reconciliation, which is what most companies believe. In a company of this size it is usually one of three things: an external input that lands late, one person outside finance who owes a schedule and does it in the evenings, or a review step scheduled after something it did not have to wait for.

Once you can name your critical path in a sentence, the calendar practically writes itself, and so does the improvement plan, because there is only one chain worth working on. Effort spent shortening anything off the critical path buys nothing at all, and a great deal of close remediation is exactly that: three people working hard on tasks that were never the constraint.

Schedule backwards from the last dependency

Here is where the design departs from the usual template, and it is the practical trick in this whole piece.

Do not number the days from day one. Number them from L, the last dependency to land: the point at which everything the close needs is in the building. Everything before L is arrival, and its timing belongs to the supplier. Everything after L is work, and its timing belongs to you.

Position	What sits here	Whose timing it is
Before L	Cut-off notices, chase list, the pre-close tasks that can be done on data already in hand, and waiting	Suppliers, internal and external
L	The last input arrives. The close, in the sense of work you control, starts here	The slowest supplier
L plus one block	Capture and posting of everything that arrived, sub-ledgers agreed	Yours
L plus two	Reconciliation, every balance sheet account to its evidence	Yours
L plus three	Judgement entries, accruals, cut-off decisions	Yours, and the reviewer’s
L plus four	Review, in full, with nothing outstanding beneath it	The reviewer’s
L plus five	Issue and lock	Yours
After the lock	Carry-forward, next month’s open items, and the one process change from this close	Yours

Two things become obvious when it is drawn this way and neither is obvious on a day-numbered calendar.

The first is that the part you control may be short while the close is long. A company whose finance work takes a few days and whose close takes three weeks does not have a close problem. It has a supplier problem, and every hour spent on the finance side is wasted effort.

The second is that pulling L earlier is worth more than compressing anything after it, hour for hour, because everything downstream moves with it. That single observation redirects most close remediation programmes away from the work and towards the arrivals, which is where the time actually is.

Where review sits, and the mistake everybody makes

Review goes after the last thing it depends on. Not on the day that suits the reviewer.

This is the most common design error I see, and it is committed by companies doing everything else well. The reviewer, who is often part-time or fractional or the owner, has a day of the week that works. The calendar puts review on that day. Then reconciliations run half a day over, review happens anyway on the appointed day, and the reviewer reviews an incomplete file. Everything they find is a thing that was going to be finished anyway, everything they miss is unreviewed, and the sign-off means nothing.

Two rules keep it honest.

Review has an entry condition, written down. A defined list: reconciliations complete, open items list clear or explicitly carried, judgement entries posted, recurring register checked. If the condition is not met, review does not start. It moves. A review that starts on an incomplete file is not a review with a caveat, it is a different and much weaker activity wearing the same name.

If review keeps moving, the calendar is wrong, not the reviewer. Three consecutive months of a deferred review means the work before it does not fit where it was placed. Re-map, do not exhort.

There is a corollary worth stating for smaller companies. If the reviewer genuinely has only one available day and the work genuinely cannot be complete before it, then the close is designed around the reviewer’s availability and the honest response is to move work out of the close so that it can be. Which is the next section.

Move work out of the close

The fastest closes at this size are not the ones with the most efficient close. They are the ones with the least in it.

Four categories belong in the month rather than at the end of it, and none of them require any new capability.

Reconciliations of accounts that do not move. An account with two transactions a month can be reconciled the day the second one posts. Nothing is gained by waiting for month end, and it takes a task off the critical path permanently.

Coding and categorisation. If transaction categorisation happens weekly, capture at close is a check rather than a job. If it happens at close, it is the job, and it sits on the critical path in front of everything.

Schedules maintained by people outside finance. Deferred revenue, project status, stock counts, unbilled work. If these are updated as events happen, the close consumes them. If they are assembled at close, the close waits on somebody who is busy.

Anything reconciled to a third party you can obtain early. Some external documents are available before month end or shortly after in a portal rather than by mail. Getting one input two days earlier moves L, and moving L moves everything.

The test for whether a task belongs in the close: does it require the month to be over? If not, it does not belong in the close, and the fact that it has always been done there is not a reason.

Setting a target you can hit in month one

I am not going to tell you how many days your close should take. Anyone who publishes a number for that is guessing at your suppliers, your systems and how many people you have, and a target set from outside is a target that gets missed and then quietly abandoned.

Derive it instead. The first target is the length of your critical path, as mapped, plus a genuine buffer for the parts that have never been measured. That will be longer than you want. Publish it anyway, because a target you hit in month one establishes that the calendar means something, and a target you miss in month one teaches everybody that the calendar is aspirational.

Then improve it in this sequence, over three closes.

Close one: measure, do not change anything. Run the calendar as mapped and record when each thing actually happened against when it was meant to. This is a dull month and it is the one that makes the next two work, because almost every close remediation plan I have seen starts by fixing whatever was most annoying last month rather than whatever was actually on the critical path.

Close two: attack the critical path only. One item. Usually an arrival rather than a task. Move it earlier, remove the dependency, or change the supplier arrangement. Leave everything else exactly as it is, so that you can tell whether the change worked.

Close three: re-time and commit. With two months of measurement, re-cut the calendar to what the evidence supports, publish it with owners against every row, and hold it. Now it is a commitment rather than a plan, and it is a commitment to a number your own data produced.

After that, one change per close, permanently. Not a programme, not a project, one change a month. Over a year that is twelve improvements chosen with evidence, which beats any redesign.

The calendar has three shapes, not one

The monthly calendar is the base. Two variants come off it and both need to exist before the year starts.

The quarter-end variant. Longer, because of whatever your reporting or lending arrangements require at a quarter: a covenant calculation, a report to a lender or a shareholder, a deeper review. Map its extra dependencies separately. The mistake is treating a quarter close as a monthly close with more effort, which puts the extra work on the critical path by accident.

The year-end variant. Longer again, and it has a different purpose, because its output is not the reporting pack. It is the file that somebody outside the company will look at. It carries a hard cut-off, a clean-up pass, and the schedules that an external practitioner will ask for, none of which appear in a monthly close.

The connection between the three that people miss: the quality of the monthly close determines the length of the year-end one. A year of clean monthly closes turns the year end into an extended month. A year of closes where balances were carried forward unexplained turns it into an investigation, and it happens at the point in the year when everyone has the least appetite for one.

What we do not do

I do not hand a company a close calendar on day one of an engagement. The calendar is the output of the mapping, the mapping takes a cycle, and a calendar delivered before it is a template with a client’s name on it. What arrives on day one is the dependency map in progress and a list of the arrivals that need to move.

I do not promise a number of days. The number falls out of your critical path, and the honest first answer to “how fast can our close be” is “let me see what you are waiting for”.

And I do not schedule a review step around anybody’s availability, including my own. If the file is not ready, the review moves, and if the review moves three months running then the design is wrong and we go back to the map. The monthly close engagement is worth what it is worth because the sign-off at the end of it means the file underneath it was complete, and a sign-off that does not mean that is worth nothing at all.