The FY 2026-27 Compliance Calendar, Rebuilt Around Document Lead Time

Every compliance calendar lists the filing dates. None of them list the date your practice actually lives or dies by: the day the documents must be in your hands. Here's the FY 2026-27 calendar rebuilt around that number, plus the operational layer most calendars leave out: which events repeat unchanged every cycle, which ones need re-checking every year, and how to stop rebuilding the same checklist from scratch each time.

The calendar, with collect-by dates

Why the collect-by column changes everything

A deadline you see 10 days of runway on is a task; a deadline you meet with documents arriving the night before is a crisis. The collect-by column converts your compliance calendar into a collection calendar, and collection, unlike filing, can start weeks early and run on autopilot.

Put a rough number on it. Say your firm carries 60 clients through tax audit. The statutory window from 3CD to ITR is a month, so it feels generous. But if even half of those clients only send complete financials after two rounds of chasing, spread over ten days each, you're not really working with a month; you're working with the last week of September and the first week of October, for thirty clients at once. Move the internal collect-by date to 1 September instead of leaving it implied by 30 September, and the same thirty clients get chased across three unhurried weeks instead of one frantic one. Nothing about the statutory deadline changed. Only the date you started planning around did.

Recurring events vs. one-time annual events

Not every row in that table behaves the same way, and treating them identically is where a lot of firms lose the benefit of building a calendar at all.

GSTR-1, GSTR-3B, and the quarterly TDS returns are recurring events: the document list is nearly identical every single cycle for a given client, and it rarely changes year to year. Once you've written down what a client owes for GSTR-3B, you've written it down for the rest of the client relationship, not just this month.

ITR, tax audit, GSTR-9/9C, and ROC filings are one-time annual events: they happen once a year, and whether they even apply to a given client this year can change. A client's turnover can cross an audit threshold, drop below a GSTR-9C requirement, or add a new director who needs a fresh DIN. The checklist for a recurring event can be cloned forever. The checklist for an annual event has to be re-validated every year before it's cloned.

That distinction should drive how you build standing setups: automate the recurring events aggressively, and build the annual ones with a yearly review step baked in, not skipped.

Where the calendar looks the same but the entity doesn't

The single-row calendar above is accurate for the typical case, but "typical" hides real differences by entity type: exact thresholds move with each Finance Act, so treat the pattern below as the shape of the difference, and verify the current numbers before applying them to a specific client.

The practical consequence: a company client always has a ROC-filing collect-by date on your calendar, audit or no audit, while an individual client's tax-audit row can silently appear or disappear depending on this year's turnover. Your checklist logic needs to know which kind of client it's looking at, not just which event is coming up.

Standing checklists for recurring events

GSTR-1 needs the same documents every single month: sales register, credit/debit notes, e-way bills, export invoices if any. So does 3B, so does every TDS quarter. Firms that re-type the request every cycle are doing clerical work software finished years ago: the list should generate itself, per client, per period, and the follow-ups with it.

Once a client is tagged "files GSTR-1 monthly" or "deducts TDS, files 24Q quarterly," that tag should be enough. The document list, the collect-by date, and the reminder cadence should all fall out of it automatically, every single period, without anyone re-deciding what to ask for.

How to turn this calendar into a live tracker

A calendar on a wall or in a spreadsheet only tells you what's due. A live tracker tells you, for every client, exactly what's still missing right now. Getting from one to the other is mostly a mapping exercise, done once:

1. 1Tag every client with the events that actually apply to them: which GST returns, whether TDS applies, whether they're audit clients, whether they're a company with ROC obligations. Not every client touches every row in the calendar.
2. 2Write one standing document checklist per event, not per client, the checklist for "GSTR-3B, monthly" is the same shape for every client who has that tag; only the client's own numbers change inside it.
3. 3Attach the collect-by rule to the checklist, not to a specific month, "8th of next month" or "10 days before the statutory date" should regenerate the actual date every cycle without anyone recalculating it.
4. 4Route incoming documents against the right client, event, and period automatically, so a September GSTR-1 attachment doesn't need a human to file it under the right bucket before anyone can tell what's still missing.
5. 5Review the annual-event tags once a year, before the checklist clones itself for the next cycle, turnover crossed a threshold, a director changed, an AGM date shifted.

• Common mistake: one generic reminder for everything. “Please send your documents” gets a worse response than a dated, itemised list, clients respond to specifics, not general prompts.
• Common mistake: cloning last year's audit checklist without re-checking applicability. A client who fell below the threshold this year doesn't need the audit chase at all; sending it anyway trains clients to ignore your reminders.
• Common mistake: treating a company's ROC filing as optional busywork. It's due whether or not the tax audit is, and it has its own document set (board resolutions, AGM minutes) that the tax-audit ask won't surface.
• Common mistake: building the collect-by date only in your own head. If it only exists as a mental buffer, it evaporates the first time you're on leave; write it into whatever system tracks the client.

What if a client's turnover crosses an audit threshold mid-year?

Don't wait for the tax-audit deadline to find out. Check turnover position at least once a quarter for clients sitting near a threshold, and update their event tags the moment they cross it, not at year end. Once tagged, they inherit the tax-audit collect-by date and the extended ITR deadline automatically, alongside whatever recurring events they already had. Treat the new tag as the default going forward until a fresh check says otherwise.

How far ahead should recurring checklists be built?

As far ahead as the tag allows. A client marked "GSTR-3B, monthly" or "TDS, quarterly" can have every period's checklist and collect-by date generated for the entire year in one pass, because the document list itself won't change. Annual events are different: build the shell early, but don't finalise the checklist until applicability for that specific year, audit trigger, AGM date, director changes, is confirmed.

What's the safest way to treat rumoured deadline extensions?

Plan to the original date, always. An extension, if it comes, is a bonus buffer you get to enjoy after it's officially notified, not a discount you bake into your collect-by dates in advance. Firms that quietly assume an extension and relax their chase early are the ones caught out on the years it doesn't materialise. The calendar above should be read the same way: as the current standard dates, to be re-verified each cycle, not as a permanent fixture.