The Extension You Assumed You Had: Lodgment Dates That Shift
Concession dates, agent extensions and quarterly cycles all move on their own logic. Here's how to stop treating one deadline as if it were another.
Ask any practice owner when a company tax return is due and you'll get a confident answer. Ask them when this company's return is due — the one that lodged late two years ago, or the one that just came off another agent — and the confidence tends to fade. The honest answer is: it depends. And "it depends" is exactly where compliance deadlines slip.
The ATO and ASIC don't run on a single, fixed calendar. They run on overlapping cycles, concessions and conditions that shift the date under your feet. If your practice treats every obligation as though it lands on the same day every year, you'll eventually be caught out — usually on the one client where it matters most.
Why "the due date" is rarely one date
Consider how many things quietly move a lodgment date:
- Tax agent concessions. A return lodged through a registered agent often attracts a later concessional date than a self-lodger — but only if the client is on your lodgment program and up to date.
- Prior-year lodgment status. Clients with overdue returns can lose their concessional dates entirely, defaulting to earlier deadlines you may not expect.
- BAS vs IAS cycles. Quarterly BAS, monthly IAS, PAYG instalments and GST instalments each roll on their own rhythm, and a single client can be on more than one at once.
- New clients mid-cycle. A client who joins in March brings deadlines already in motion — and possibly a history that changes their dates.
- ASIC review dates. Annual company reviews fall on the anniversary of registration, not 30 June, not a quarter-end — a genuinely client-specific date that never aligns with your tax rhythm.
Each of these is manageable in isolation. The trouble is the assumption underneath: that once you know what type of obligation it is, you know when it's due. You don't. You know a starting point that the client's specific circumstances then modify.
The extension that wasn't there
The most common version of this failure is the assumed extension. A staff member sees a company tax return, mentally applies the concessional date agents usually enjoy, and diarises accordingly. What they didn't check was that the client had two prior years overdue when they walked in — which means the concession doesn't apply, and the real date was months earlier.
Nobody made a careless mistake. Someone applied a general rule to a specific case where the rule didn't hold. That's not a training problem you can drill away; it's a data problem. The date should be attached to the client, derived from their actual status, not reconstructed from memory each time.
The spreadsheet can't tell you what changed
Plenty of practices track deadlines in a shared spreadsheet, and for a small book it holds together. The weakness shows when a date moves. A spreadsheet records what someone typed on the day they typed it. It doesn't know the client came off overdue status last week, or that their ASIC review anniversary shifted because of a re-registration, or that their BAS cycle changed from quarterly to monthly after crossing a turnover threshold.
So the cell keeps showing the old date, confidently wrong, until someone notices. Usually that someone is the ATO.
This is where accounting client management software earns its place. The point isn't to store dates — a spreadsheet stores dates. The point is to derive and update them from the client record, so that when a client's circumstances change, the obligations recalculate rather than sitting frozen. Client accounting is as much about tracking moving obligations as it is about the numbers themselves.
Building deadlines that move with the client
A few principles keep shifting dates under control:
1. Tie obligations to the client, not the calendar
Each recurring obligation — quarterly BAS, monthly IAS, annual return, ASIC review — should live against the specific client, with its own cycle and its own conditions. When you onboard a client, you set up their obligations once, and the system generates each instance on the right rhythm. You're not rebuilding a spreadsheet row every quarter.
2. Track the status that changes the date
Lodgment concessions depend on whether a client is up to date. If your system knows a return is overdue, it can flag that the concessional date for the next one may not apply — before you diarise the wrong one. This is where account practice management software and tax return software overlap: the workflow and the compliance logic need to see the same client record.
3. Give ASIC reviews their own place
Company review dates are the ones most often forgotten, precisely because they don't line up with anything else. They need to sit on the same board and the same calendar as BAS and tax, so the June-heavy season doesn't hide a March review anniversary.
4. Surface deadlines by proximity, not by client
You don't want to open a client to find out what's due. You want to open your practice and see everything due in the next fortnight, across every client, ranked by date and risk. That view is only trustworthy if the underlying dates are live.
Where Finye fits
Finye tracks ATO and ASIC obligations as recurring items against each client, generating BAS, IAS, tax return and company review work on the right cycle and surfacing them on one calendar and on your boards. Because those obligations live alongside the client record, the work item, and the two-way Xero sync, the date you see reflects the client you actually have — not the general rule you half-remember. Finye isn't a lodgment tool and it doesn't file returns for you; it makes sure the right obligation lands in front of the right person, on time, with the context they need to check whether the date is really the date.
The habit worth building
The next time someone in the practice says "that's due in May," the useful follow-up is: due for whom, and what would move it? Concessions, prior-year status, cycle changes and registration anniversaries all shift lodgment dates on their own logic. Treat every deadline as client-specific until proven otherwise, keep it attached to a record that updates, and you'll stop discovering extensions that were never yours to assume.