Reporting calendar: keeping packs on schedule

A reporting calendar is not a list of deadlines. It is a dependency map that starts with the date the pack must be read and works backwards through sign-off, commentary, analysis, close, and data extraction. Change the meeting date and every date before it should move.

Publish the calendar before the period starts, with the meeting date fixed for the next twelve months where possible. A moving review date makes every upstream deadline negotiable, and the finance team ends up compressing the same work into fewer days.

The offsets below are a starting point for a monthly management pack. They assume a close that takes a week and a review that takes place two working days after issue. Adjust them once, then hold them.

Every source needs a cut-off and a named owner. When data arrives late, choose one of two responses: accrue the amount if it is material and can be estimated, or disclose the omission and its expected effect. Never rebuild the pack silently after issue without changing the version and telling readers.

A useful rule: if late data would change a headline number by more than the agreed materiality threshold, issue a revised version with a change note. If it would not, record it and correct it next period. The rule removes the argument in the moment.

A pack with five contributors and no owner will be late. Name one person who chases inputs, reviews the draft, and signs off the issue. Name a deputy who can run the process during leave or illness. Access, passwords, and handover notes belong to the role, not to the individual.

The owner does not write every section. The owner guarantees that every section has a named author, a deadline, and a reviewer. That distinction keeps the role manageable.

Stop structural changes to the pack before issue. A new chart, a changed mapping, or an extra schedule two days before the review creates rework and undermines the numbers readers have already seen. Put changes into the next cycle unless they correct an error.

If an urgent change is unavoidable, log what changed, why, and who approved it. A short change log is enough. The point is to make the exception visible rather than normal.

Track the process, not only whether the pack was sent. Four measures are enough: the percentage of milestones met on time, the cycle time from cut-off to issue, the number of late sources, and the hours spent on rework. Review them monthly and investigate the largest miss. Publish the next three months of dates with owners, and reissue the calendar whenever the meeting date moves.

A calendar that is never measured becomes a wish list. A calendar with dates, owners, and a short review becomes a control.