Closing a Silent Gap in the Quarterly Submission Guard

Release v1.0.455 · Bug Fix

Background

Before a quarterly HMRC submission is sent, the platform runs a pre-flight check to block any submission that still contains uncategorised transactions. Submitting uncategorised data to HMRC would result in an incorrect tax return — so this guard is a critical safety net.

The platform has two code paths that can trigger a quarterly submission:

1. tRPC route — submission.submit, called from the UI.
2. Inngest function — hmrc-quarterly-submit, triggered by background events (auto-submit, retry, or direct event dispatch).

Both paths contain a check-uncategorised step. Until this release, they were not equivalent.

The Problem

When a transaction is created via the manual transaction form or imported through AgentOS, its hmrcCategory column is written with the sentinel value 'unused' to indicate it has not yet been categorised. A NULL value means the column was never set at all.

The tRPC route correctly blocked on both conditions:

// tRPC submission.submit router — correct
or(
  isNull(transactions.hmrcCategory),
  eq(transactions.hmrcCategory, 'unused')
)

The Inngest function, however, only checked for NULL:

// Inngest check-uncategorised step — incomplete
isNull(transactions.hmrcCategory)

This meant a transaction with hmrcCategory = 'unused' would pass the Inngest guard undetected and be included in the submission payload sent to HMRC.

The Fix

The check-uncategorised step in src/inngest/functions/hmrc-quarterly-submit.ts has been updated to use the same dual-condition check as the tRPC router:

// Inngest check-uncategorised step — fixed in v1.0.455
or(
  isNull(transactions.hmrcCategory),
  eq(transactions.hmrcCategory, "unused"),
),

or has also been added to the Drizzle ORM import list. No schema changes or new dependencies were introduced.

What This Means for You

• Submissions triggered via background events (Inngest auto-submit, retries, direct event triggers) now apply the same strict uncategorised-transaction guard as UI-initiated submissions.
• Any transaction left as 'unused' — whether created manually or imported via AgentOS — will correctly block the submission with a count error until it is categorised.
• There is no change to submission behaviour for transactions that were already properly categorised.

Recommended Action

No user action is required. The fix is applied automatically to all quarterly submission flows from v1.0.455 onwards.

If you have recurring Inngest-triggered submissions enabled, ensure all transactions within open quarter periods are fully categorised before your next submission window to avoid the (now correctly enforced) block.