Build your month end close calendar from the task list

Most finance teams have a month end close calendar. It is usually a spreadsheet: one row per task, a column for the working day, a column for the owner, and a colour for done. Someone copies last month's tab, changes the dates, and sends it round. By the second week of the close it no longer matches what people are doing, and by the following month nobody remembers why. The calendar is treated as a document someone maintains. It works far better as something produced from the task list, so that it stays true without anyone tending it.

What goes wrong with a copied-forward calendar

A close calendar copied forward each month drifts in quiet ways. None of them is dramatic, which is why they last.

• Tasks are added in the close and never written back. A new client, a new bank account, a new intercompany recharge. Someone does the work in the close, but the row never makes it onto the next tab.
• Tasks stop and the rows stay. A loan is repaid, an entity is closed, a report is no longer read. The row sits there, ticked every month by habit.
• Owners change and the names do not. Someone moves team or goes on leave. The calendar still says their name, and the actual owner works from memory.
• The dates are typed, not calculated. "Working day 3" becomes "the 4th" when someone retypes it, and the bank holiday month catches the team out.
• The dependencies live in people's heads. Everyone knows accruals wait for the purchase ledger cut-off. The spreadsheet does not, so when one task slips, nothing tells the next one.

The result is a calendar that describes roughly what the close looked like some months ago. People stop trusting it, and once they stop trusting it they stop updating it.

The month end close calendar is a view, not a document

Here is the shift. The close is a set of recurring tasks. Each task already has, or should have, a rule for when it happens, an owner, a backup, a checklist and the tasks it waits for. If those facts live on the task, the calendar is just those tasks laid out on next month's working days. You do not maintain it. You generate it.

That changes where the work goes. Nobody edits the calendar. When a new bank account is opened, someone adds a reconciliation task with its rule and owner, and it appears on every calendar from then on. When an entity is closed, the task is retired, and it disappears. When an owner changes, the task changes, and the calendar follows.

We made the case for keeping recurring work as a template plus its instances in recurring work is not a project. The close calendar is the most visible place that idea pays off.

What each close task needs to carry

For the calendar to be generated rather than typed, each task needs a small set of facts. Most teams have them scattered across the calendar, the manual and people's heads. Put them in one place.

1. A calendar rule. "Working day 2", "last working day", "third working day after month end", "15th, or the next working day". Written as a rule, not a date, so next month calculates itself.
2. An owner and a backup. Two names, not one. A task with one name is a key person risk, which we covered in what happens to your month end close if one person quits.
3. What it waits for. The tasks that must finish first. This is the piece most calendars leave out, and the one that matters most when the close runs late.
4. The checklist or manual. Attached to the task, so whoever picks it up has the steps in front of them.
5. A rough effort. Not a timesheet. Enough to see that working day 3 has eleven hours of work on one person.

Five facts per task. For a close of, say, 60 tasks, that is a long afternoon's work once, and then very little after.

What you get when the calendar is generated

It shows the critical path

Once tasks carry their dependencies, the calendar can show which chain decides when the close finishes. In a hypothetical close, that chain might run bank reconciliations, then accruals, then intercompany, then the management pack. A slip in a task off that chain costs nothing. A slip on it moves the whole close. Teams usually know this by feel. Seeing it written down lets you protect it, for example by giving the reconciliations a backup who actually does one now and then.

It shows the overloaded day

Lay effort on top of owners and days, and the bottleneck shows up before the close starts. One person with three tasks on working day 2 and a backup who has never done any of them is a risk you can fix in the third week of the month, not on the night.

It shows what was missed

When the calendar comes from tasks and each instance is ticked off, last month's close leaves a record: what ran late, what was skipped, what was done by the backup. That history is the basis for any conversation about shortening the close, and later about which steps are ready to hand to an agent. You cannot hand over a task that is not on the list, or one whose timing only one person understands.

What it means for the people running the close

A generated calendar is not a tool for watching people. Said badly, it can sound like one, so say it well. The point is that the close stops depending on someone remembering to update a spreadsheet at nine at night, and stops surprising the team with a task nobody knew had moved. The person who kept the old calendar alive gets that time back, and their knowledge of the close ends up on the tasks, where the next person can find it.

This is what we are designing Beaks to do: tasks with calendar rules, owners and checklists, and the calendar as a view of them. A well kept spreadsheet with a rule column and a dependency column will get a small team most of the way.

One thing to do this week

Take last month's close calendar and add two columns: "rule" and "waits for". Fill them in with the person who owns each task, and write the rule as a rule, not a date. Then check next month's dates against the rules. Every row where they disagree, or where nobody can say what the task waits for, is a place your close depends on memory.