Blog: Clearer feedback when an archived quarter blocks tax year finalisation

Release: v1.2.0
Area: Quarterly Submissions → Finalise Tax Year

---

We shipped a small but meaningful UX fix this release. If you've ever stared at a disabled Finalise Tax Year button and wondered why it wouldn't activate — even though you were sure you'd dealt with all your quarters — this one's for you.

The problem

The Finalise Tax Year section on /dashboard/quarterly checks whether all four quarters are in a submittable state before enabling the finalisation button. The check was simple:

const allSubmitted = submittedCount === 4;

That's fine as a gate, but it said nothing about why the count might fall short. The scenario that caused the most confusion: an archived quarter.

When a quarter is archived, it's no longer counted as submitted or accepted. The button stays disabled. Previously the UI showed only a generic "not all quarters submitted" message, with no pointer to the archived quarter that was the actual blocker. Users had to mentally audit each quarter row themselves to figure out what was wrong.

To be clear — the server-side validation also rejects archived quarters during finalisation (archived status is not in the set of ready statuses), so no incorrect submissions were possible. This was purely a communication gap in the UI.

What's fixed

The FinaliseTaxYearSection component now:

1. Detects archived quarters specifically — distinguishing them from quarters that are simply incomplete or not yet computed.
2. Surfaces a targeted message — when an archived quarter is the blocker, the UI names it directly, so you know exactly what to address before re-attempting finalisation.

What this means for you

If the Finalise Tax Year button is disabled and one of your quarters has been archived:

• You'll now see a clear explanation in the UI rather than a generic disabled state.
• To proceed, un-archive or re-submit the flagged quarter, then return to the finalisation screen.

If all four quarters are submitted or accepted, behaviour is unchanged — the button enables and finalisation proceeds as normal.

Background: how finalisation works

Finalisation (also known as the End of Period Statement / Final Declaration under MTD ITSA) requires that all four quarterly submissions for the tax year be in an accepted or submitted state. The platform enforces this both on the client (button state) and on the server (finaliseTaxYear mutation). This dual validation ensures that even if a UI state gets out of sync, an invalid finalisation cannot reach HMRC.

The v1.2.0 fix brings the client-side messaging up to the same level of precision as the server-side validation, so you always know exactly what's needed to move forward.