All Docs
FeaturesMaking Tax DigitalUpdated March 20, 2026

Fixing Stale Totals in the Quarterly Submission Dialog

Fixing Stale Totals in the Quarterly Submission Dialog

Release: v1.0.433
Date: 2025-07-14
Severity: High — could cause users to submit HMRC figures that didn't match their on-screen view

What happened

The quarterly submission flow in MTD Comply has two key moments where financial totals are displayed:

  1. The QuarterTotalsGrid card — the main dashboard view of your quarter, showing income, expenses, and net profit.
  2. The SubmitConfirmDialog — the confirmation step you see just before figures are sent to HMRC.

These two components were reading from different fields on the same data object, and that difference mattered.

The dashboard card was already using live running totals (runningTotalIncome, runningTotalExpenses) — figures that update as you categorise transactions, whether or not you have clicked Compute recently. The confirm dialog, however, was reading the stored compute values (totalIncome, totalExpenses, netProfit) — figures that are only updated when you explicitly click Compute.

Why this is a problem

The typical quarterly workflow looks like this:

  1. Import transactions from your bank feed or property management software.
  2. Categorise transactions into HMRC income/expense categories.
  3. Click Compute to calculate your quarter totals.
  4. Review and click Submit to send to HMRC.

In practice, steps 2 and 3 aren't always done in a single sitting. A user might compute their totals, then categorise a few more transactions that arrived from a bank feed sync, and then submit — all without clicking Compute again. In that scenario:

  • The dashboard card correctly showed the updated figures (using running totals).
  • The confirm dialog showed the old figures from the last compute run.
  • The figures ultimately submitted to HMRC were the stored compute figures — not what the user was looking at.

This is a meaningful data-integrity issue for MTD ITSA compliance, where the figures sent to HMRC must match the taxpayer's records.

The fix

The SubmitConfirmDialog in quarterly-summary-dashboard.tsx now uses the same live running total fields that QuarterTotalsGrid uses. The fix follows the existing pattern already established in the codebase:

// Before — stale stored values
<div>Total Income</div><span>{formatGBP(summary.totalIncome)}</span>
<div>Total Expenses</div><span>{formatGBP(summary.totalExpenses)}</span>
<div>Net Profit / Loss</div><span>{formatGBP(summary.netProfit)}</span>

// After — live running values (mirroring QuarterTotalsGrid)
<div>Total Income</div><span>{formatGBP(summary.runningTotalIncome ?? summary.totalIncome)}</span>
<div>Total Expenses</div><span>{formatGBP(summary.runningTotalExpenses ?? summary.totalExpenses)}</span>
<div>Net Profit / Loss</div><span>{formatGBP((summary.runningTotalIncome ?? summary.totalIncome) - (summary.runningTotalExpenses ?? summary.totalExpenses))}</span>

The fallback to summary.totalIncome / summary.totalExpenses ensures backwards compatibility for any quarters where running totals haven't yet been computed.

What this means for you

  • Going forward, the figures you see in the submission confirm dialog will always match the figures shown on your quarterly dashboard card. What you confirm is what gets submitted.
  • No action is required for future submissions — the fix is live and applies automatically.
  • If you submitted recently and noticed a mismatch between your dashboard card and the confirm dialog, we recommend checking your submission record. If the submitted figures differ from your categorised transactions, you may need to file an amendment with HMRC.

A note on server-side validation

The server-side submission guard already blocks submissions if there are uncategorised transactions present. This release does not change that behaviour. The guard and the underlying computeBusiness logic in quarterly-summary.ts remain unchanged — this fix is isolated to the user-facing display in the confirm dialog.

This fix was shipped as a priority patch given the potential for users to unknowingly submit incorrect figures to HMRC. We apologise for any inconvenience caused.