Close Calendar
A close calendar is the schedule that runs a month-end close: which task happens on which day, who owns it, and what it depends on. It turns a close checklist into a dependency graph, showing the critical path that determines how fast the books can lock
- Accounting Operations & Financial Close
A close checklist says what has to happen during the month-end close. A close calendar says when, by whom, and after what. The difference is the whole point of building one: a close is a dependency graph wearing a to-do list's clothing, and a checklist alone does not show which slip on day two turns into a two-day slip by day five.
Most companies' closes share the same critical path, whatever their checklist looks like: subledger cutoff, then cash and balance sheet reconciliations, then accruals, then trial balance, then flux, then statements. Everything on that path is sequential by necessity, because each step consumes the prior one's output. Work that is not on that path, most schedules and most low-risk reconciliations, can run in parallel, and a calendar that lines everything up as if it all sat on the critical path is choosing to be slow.
A minimal working calendar fits in one table, using business-day notation (BD1 is the first business day after period end, BD-1 the business day before it):
| Day | Owner | Work | Depends on |
|---|---|---|---|
| BD-1 | Staff accountant | Recurring entries posted, suspense cleared | Nothing |
| BD1 | AP / AR leads | Subledgers closed, cutoff confirmed | Prior-period sweep |
| BD1-2 | Staff accountant | Bank and card reconciliations | Statements available, subledger close |
| BD2-3 | Senior accountant | Accruals, prepaids, depreciation | Subledger close |
| BD4 | Controller | Trial balance review, flux drafted | All entries posted |
| BD5 | Controller / CFO | Statements, sign-off, lock | Flux cleared |
Three rules separate a calendar that actually runs the close from one that just describes it. Every line needs one named owner, not a team, because a task owned by a team is owned by no one at 4pm on close day. Every line needs a stated dependency, so a slip shows up as a chain reaction instead of a surprise on day five. And completion times need to be recorded, not just planned, because those timestamps are the only dataset a team has for finding its real bottleneck rather than the one everybody already complains about.
A close calendar is one recurring instance of the larger cycle that record to report names: R2R is the whole tower from transaction capture through consolidated reporting, and the calendar is what sequences the close phase sitting inside it for a single period. The calendar also does not stop at the last signature. The best teams add a short post-mortem before the next cycle starts: what was late, what was reworked, which reconciliation had the same open item for the third month running. That review only works because the calendar recorded real completion times to review.
The calendar's most common failure is silent rather than obvious: it lists tasks finance owns and stays quiet about the ones it does not. Revenue recognition, commission calculations, and usage-based billing all depend on data that sales ops or a billing system produces on its own schedule, and a calendar that does not name those upstream owners and their deadlines is a wish, not a plan. The second most common failure is treating every account with the same rigor: reconciling every balance to the penny every month, on the same cadence as the highest-risk cash and revenue accounts, is how a calendar that looked reasonable on day one collapses under its own workload by month six.
Related terms: Record to Report (R2R)
Go deeper: The Month-End Close: The Complete Guide
Adopt's agents work the parallel tracks on a close calendar at the same time and stamp their own completion times as they go, so the post-mortem data a calendar needs is already there instead of something a controller has to reconstruct from memory. Sign up free.