What belongs on a grant compliance calendar

Most organisations have something they call a grant calendar. Usually it is a list of report due dates, kept by one person, in a spreadsheet. That covers perhaps a quarter of what an award actually obliges you to do, and it fails in a specific, predictable way: it captures the obligations that arrive on a schedule and misses the ones that are triggered by an event.

Why most calendars fail

Three failure modes account for almost all of it.

They only hold dates that were easy to find. Reporting deadlines are stated plainly near the front of an award letter. Prior-approval requirements, drawdown windows and audit triggers are buried in terms and conditions that are frequently incorporated by reference rather than attached — so they never make it onto the calendar at all.

They have no owner. A date on a shared calendar that belongs to everyone belongs to nobody. When the deadline arrives, three people each assume one of the others has it.

They live in one person’s head, with a spreadsheet as a partial backup. This works until that person is on leave, or leaves. The institutional knowledge of why a date matters — which is the part that lets someone judge whether a slip is survivable — is rarely written down anywhere.

The five categories

A calendar that actually protects you holds five different kinds of thing.

1. Scheduled reporting

Progress reports, financial reports, final reports. The easy category — these have explicit dates. Note that programmatic and financial reports frequently have different deadlines and different owners, and get collapsed into one calendar entry by mistake.

2. Financial and drawdown windows

Periods during which you may request funds, invoice, or draw down. These are often expressed as windows rather than deadlines (“within 30 days of quarter close”), which makes them easy to leave off a date-based calendar. Missing the window can mean waiting a full quarter for cash you have already spent.

3. Conditional and threshold triggers

Obligations that activate when something becomes true rather than when a date arrives: an audit requirement that triggers above a spending threshold, a reporting requirement that starts once a programme reaches a participant count, matching-fund documentation due once you draw a certain proportion. These need a monitored condition, not a date.

4. Prior approvals

Things you must ask permission for before doing: moving money between budget lines beyond a stated tolerance, changing scope, changing key personnel, extending the period of performance, subawarding. The deadline here is “before you act”, which no calendar naturally represents — so it belongs on the calendar as a standing rule attached to the award, surfaced whenever someone proposes one of those actions.

5. Record retention and closeout

Closeout tasks after the period of performance ends, and record-retention periods that run for years afterwards. These are the most commonly dropped obligations, because by the time they matter the programme staff have moved on and the grant feels finished.

The owner rule

A useful test: for every obligation on your calendar, can you name the person who will be asked about it if it slips? If not, it is not tracked — it is merely written down.

Ownership should be a named individual, not a team or a role. “Finance” is not an owner. It also needs a deputy, because the single most common time to miss a deadline is when its owner is away.

Working backwards from due dates

The date a report is due is not the date work on it starts. A quarterly financial report due 30 days after quarter close may need the ledger closed, programme numbers gathered from delivery staff, and a review by someone who did not write it. That is three upstream dependencies, each with its own realistic lead time.

Calendars that hold only the due date generate a predictable pattern of last-minute scrambles and small errors. Adding a start date and a review date to each significant deliverable costs very little and removes most of that.

Building one

Whatever tool you use, the sequence is the same. Read each award document and extract every obligation it creates — see how to read an award letter for obligations for a method. Classify each into the five categories above. Give every one an owner and a deputy. Add lead times to anything that needs upstream work. Then put the result somewhere your team already looks, rather than in a system they must remember to check.

That last point decides whether the calendar works. A compliance calendar nobody opens is a filing cabinet. Grantwell publishes each organisation’s calendar as a subscribable feed for exactly this reason — the deadlines appear in the calendar application your team has open anyway, and reminders reach owners by email before the date rather than after it.

This guide is general information about how grant compliance work is commonly organised, not legal, audit or accounting advice. Grant rules change, and terms vary by funder and award — always check your own award documents and the current regulation, and talk to your auditor about your specific circumstances.