MTD for practices:
a capacity plan.

The arithmetic, done once

It is worth writing the numbers down, because the shape of the problem is not obvious until you do. For every client in scope, a year now contains four quarterly updates per income source plus one year-end final declaration. Self-employment and UK property count as separate income sources, so a client with a trade and a rental property is not five events — it is nine.

Run that across a book:

• 100 clients, one income source each — 500 filing events a year, against roughly 100 before.
• 300 clients, one income source each — about 1,500 events.
• 300 clients, a third of them with two income sources — closer to 2,000.

None of these events is individually difficult. That is precisely what makes the problem hard to see coming: every single task looks trivial, and the aggregate is a different business.

Where the hours actually go

The instinct is to price the work as "time to prepare and submit a return." In practice that is the smallest part of it. The hours concentrate in three places, and only one of them is filing.

1. Chasing records

The clients newly in scope are the ones whose books have historically arrived in January, in a carrier bag. Quarterly reporting asks them to produce something usable four times a year. Whatever your practice does about that — a portal, a bookkeeping subscription, a firm deadline before HMRC's — is a client-behaviour problem, and no software solves it for you.

2. Reconciling what arrives

Records that arrive are not automatically records you can file from. Categorisation is wrong, periods overlap, a figure moved between quarters. Someone has to look. This is real professional work and it does not disappear.

3. Assembly, checking and transcription

This is the part that scales badly and adds no professional value: taking reconciled figures and turning them into a correct submission, then checking the arithmetic and the identifiers. It is repetitive, it is where typos enter, and it is the part that is almost entirely mechanisable.

The re-keying problem is also a compliance problem

There is a second reason to remove transcription from stage 3: HMRC requires an unbroken digital link from the client's records to the figures you file. Typing a number from one screen into another breaks that link, and so does copy-and-paste. The manual step that feels like a time problem is simultaneously a compliance defect — which means automating it is not merely an efficiency choice.

What to automate first

In order of return on effort, for a practice with a book of clients rather than a single taxpayer:

1. Batch assembly across the book. The unit of work should be "this quarter, all clients," not "this client, this quarter." If your tooling makes you open each client in turn, your cost scales linearly with the book and so does the chance of missing one.
2. A cross-client deadline view. The failure mode of quarterly reporting is not a hard filing — it is a client nobody noticed until the week it was due. One board showing every obligation across every client, with reminders that arrive before the deadline rather than on it.
3. Computed figures with refused contradictions. Totals should be derived by software from the underlying figures, and a supplied total that disagrees with its own inputs should be rejected rather than quietly accepted. This converts a class of error from "spotted if someone checks" to "cannot occur."
4. Per-client approval that records who signed. Every submission carries a declaration. At four times the frequency you want that to be evidenced automatically — a name and a timestamp against each filing — rather than remembered.
5. Per-client metering. If you cannot see what was produced per client, you cannot bill the book accurately or spot the client consuming triple the average effort.

What automation will not do

Being honest about the boundary matters more here than usual, because the temptation is to buy software and consider the capacity problem solved. It will not chase your clients. It will not decide what is allowable. It will not turn a shoebox of receipts into a digital record — something has to do the bookkeeping before any filing tool is relevant. And it will not carry the declaration: a named person in your practice still approves each submission, which is exactly as it should be.

What it can do is ensure that once a client's figures exist in a system that can export them, nothing between there and HMRC is done by hand.

A note on pricing your own service

Practices frequently re-price for MTD by multiplying the old annual fee. That tends to lose the clients you most want to keep and under-price the ones consuming the most effort. The more durable approach is to price the book and the service level: what does a client cost you per year across five touchpoints, given the state their records arrive in? That question needs per-client visibility of what was actually produced — which is the same requirement as item 5 above.

How Qgentic fits

Qgentic MTD is built for the book rather than the single taxpayer: each client is an isolated tenant with its own data, audit chain and named approver, and the book is driven in bulk — your connector stages every client's figures the same way, one scheduled job drives cycles across them through our API, and per-client metering means your billing reconciles to what was produced. Figures are computed from the client's own records — a supplied total that disagrees with its inputs is refused rather than absorbed — so the digital link stays intact end to end. It is priced per taxpayer rather than per seat, so cost tracks the client book instead of how many of your people need to log in.

Two things we state plainly. Qgentic is not yet listed on HMRC's find-software page, so we do not describe it as "HMRC-recognised" — the software is complete and available; the listing is a separate claim we will make when it is earned. And on item 1 and item 2 of the list above: today you get bulk drive through the API, but the consolidated on-screen practice roster and cross-client deadline board are on our roadmap rather than in your hands. We would rather write that here than let you find out after signing.