Why your second MTD update looks twice as big as your first

Why is my second update roughly double the first?

Because it covers twice as long. This is the single most misunderstood mechanic in Making Tax Digital, and almost every landlord meets it for the first time in November, staring at a number that looks like they have accidentally counted their rent twice.

They have not. HMRC is explicit about it.

“Each time you send a quarterly update it will cover from the start of the tax year to the end of the update period, not just the previous three months.”

So the second update is not the July-to-October quarter. It is April to October. The third is April to January. The fourth is the whole year. Where your rent accrues evenly, each one looks proportionally larger than the last, and the last one looks like your annual figure, because it is.

What a year of updates actually looks like

The chart below shows the same landlord under both models: what people expect (four separate quarters) against what MTD actually asks for (a running total). Figures are illustrative, at £2,000 of rent a month.

How do I correct a mistake in an earlier update?

You do not. You just file the next one correctly. This is the part that turns the cumulative model from a curiosity into the best thing about MTD.

Because every update restates the year from 6 April, and because, in HMRC's own words on its developer hub, “each update invalidates the previous submission”, a wrong figure in your first update is simply overwritten by the right one in your second. There is no amendment form and no separate route for fixing an earlier quarter, because the design does not need one.

Two caveats worth having. You must also fix the underlying digital records, not just the submitted total. And if the error is in your fourth update, there is no fifth to overwrite it, so you resend the fourth. GOV.UK is explicit about this: you may need to resend your fourth quarterly update to correct an error, to add jointly-let property expenses you left out of earlier updates, or to record Rent-a-Room income, and you should do it before you make any tax adjustments and before you submit your tax return. Mechanically it is the same PUT to the same record. It is only “an amendment” in the sense that you are writing the year again.

What this looks like from inside the HMRC API

Here is the part almost nobody writes about, and it is the clearest possible proof that the cumulative model is real rather than a presentational quirk.

For 2025-26 onwards, HMRC does not have a quarterly submission endpoint. In the Property Business (MTD) API v6.0, the old period-summary endpoints (create and amend a UK property income and expenses period summary) stopped accepting data for tax years 2025-26 onwards. They still exist, and still serve the years up to 2024-25, but for the current regime they are dead. They were replaced by a single cumulative period summary, released to production on 14 April 2025. (v6.0 is published as beta, last updated 9 July 2026.)

What replaced them is one path, supporting exactly two verbs:

Read that path again. It is keyed by National Insurance number, business ID and tax year. The quarter is not part of the key at all. There is one record per tax year, and every update is an idempotent PUT that overwrites it. Amending is not a different operation. It is the same operation, again.

We know this because it is what our own software does four times a year. When people describe MTD as “four submissions”, the API disagrees: it is one record, written at least four times. You can send an update whenever you like; it always restates the year.

A practical note if you are watching for it. HMRC can take up to an hour to mark an obligation as fulfilled after you submit. Filing on the afternoon of 7 August and seeing “open” ten minutes later is not necessarily a failure.

The update periods, written the way HMRC actually means them

Most published deadline tables still show discrete quarters. They are describing the pre-2024 regime. The Income Tax (Digital Requirements) (Amendment) Regulations 2024 replaced “quarterly periods” with “quarterly update periods”, each of which begins on the first day of the tax year.

If you elect calendar update periods instead, the data periods shift to 1 April to 30 June and so on, but the deadlines do not move. That quietly buys you about five extra days. The election is made per income source, inside your software, and once you have sent your first update for the year you cannot change it.

What actually goes in an update, and what does not

Totals, by category, and nothing clever. GOV.UK is blunt about it: “You do not need to make any accounting or tax adjustments before sending a quarterly update.” Reliefs, capital allowances and private-use adjustments all belong to the Final Declaration.

There is one trap here that a great deal of published advice gets wrong, including, until yesterday, an article on this blog.

The practical consequence: any in-year tax estimate you see will not reflect mortgage interest relief the way your final bill does. A lot of coverage says finance costs are “excluded from quarterly updates” and handled only at year end. That conflates reporting with relief. You report quarterly. You get relieved annually.

Common questions

Sources

Primary sources first. Where the market disagrees with HMRC, we have cited HMRC.

• GOV.UK: Use MTD for Income Tax, send quarterly updates (updated 2 June 2026, the cumulative rule)
• GOV.UK: Making Tax Digital for Income Tax Update Notice (27 March 2026, the quarterly category list)
• HMRC Developer Hub: making updates during the tax year (“each update invalidates the previous submission”)
• HMRC Developer Hub: Property Business (MTD) API (v6.0, the cumulative period summary)
• The Income Tax (Digital Requirements) (Amendment) Regulations 2024 (SI 2024/167) (update periods begin on 6 April)
• ATT: Making Tax Digital FAQs (correcting an earlier update)

Related

No, you will not be fined for missing the 7 August MTD deadline covers the penalty position for 2026-27, which is not what most of the market is telling you either.