Making Tax Digital for Income Tax (April 2026): how bank statement records need to change

From April 2026, Making Tax Digital for Income Tax becomes mandatory for sole traders and landlords with qualifying income over £50,000. For every qualifying period from that point on, HMRC expects digital records of business income and expenses kept as the year goes, not a shoebox of receipts sorted out at deadline time. Practices preparing client files this year keep hitting the same question: what actually counts as a compliant digital record, and where do bank statements fit into that.

What changes on 6 April 2026

The mandation date does not reach backwards. Clients who cross the £50,000 threshold need digital records for the qualifying period that starts on or after 6 April 2026, and quarterly updates built from those records. It does not require anyone to go back through five years of paper or PDF statements and turn them all into transaction-level entries retroactively. The obligation attaches to the period, not to the account's whole history.

That distinction matters for planning. A practice with twelve clients above the threshold needs each of them keeping digital records from their first qualifying period onward, and a workflow that can produce a quarterly update on time. It does not need a project to reconstruct 2019 through 2025 into spreadsheets. Confusing the two creates work nobody is required to do and distracts from the part of the deadline that is actually fixed.

What counts as a digital record

HMRC's guidance on digital record-keeping is specific about the shape of the record, even if it leaves some latitude on the tool. Each business transaction needs a date, an amount, and a category, held digitally rather than jotted in a notebook or bundled into a single month-end figure. Outside a small number of named exceptions, such as recording daily gross takings as one line in certain retail-style trades, summarised or grouped totals generally do not satisfy the requirement.

This is where the old approach breaks. A landlord who has been keeping one line per month, "rent received: £4,200", has a total, not a digital record of each qualifying transaction. A sole trader who lets six months of expenses sit as a single card statement, categorised once at year end by a bookkeeper skimming the PDF, is doing the same thing further along the year. Both need to move to entries that exist individually, as they happen or shortly after, with a category attached to each one.

Where bank statements fit into the workflow

Bank statements are usually the richest source for this, and usually the least convenient format to work from. A statement document lays transactions out for a human to read: dates in one column, descriptions abbreviated to fit the page, amounts split across debit and credit columns that shift position from one bank's layout to the next. None of that is structured for import into bookkeeping software, and copying it by hand line by line is the exact habit MTD is meant to move practices away from.

Scanned statements add a second layer. If a client photographs a paper statement or receives one as an image-based PDF, there is no underlying text to select at all, only pixels, and the file needs to go through OCR before any transaction can be extracted. Knowing which kind of file you are holding matters before you choose a workflow, and it takes about five seconds to tell a scanned statement from a text one once you know what to look for.

Converting a statement into a clean set of transaction rows solves the structural half of the problem: it gets each transaction onto its own line, with a real date and a real amount instead of text a spreadsheet formula cannot read. The categorisation and business-versus-personal split still has to happen afterwards, by a person or by consistent rules in the software, before that row is a finished digital record rather than raw bank data with a header row on top.

Building the workflow before the first update is due

Most of the practical work between now and a client's first qualifying period is workflow, not history. The steps below cover the part that actually needs doing before the deadline bites.

1. 1

   Confirm which clients are in scope

   Check qualifying income against the £50,000 threshold for each sole trader and landlord client, and note the date their first qualifying period starts.
2. 2

   Choose MTD-compatible software

   Settle on the package each client will use for digital records and quarterly updates, and confirm it accepts imported transaction data in the format you plan to produce.
3. 3

   Convert the current period's statements

   For the qualifying period itself, convert the statement documents into individual transaction rows rather than retyping figures from the PDF.
4. 4

   Categorise every row

   Assign a business income or expense category to each transaction, separating personal activity out of mixed accounts before anything is imported.
5. 5

   Reconcile before you file

   Check the imported total against the figure printed on the statement for that period, so a misread digit or a duplicated row does not carry through into the quarterly update.

The table below sets out the contrast that trips people up most often: what a record looked like under the old approach, and what the same information needs to look like now.

None of this changes what a bank statement can prove. It still shows that money moved, on a given date, for a given amount; it does not show why, and it will not sort personal spending from business spending on its own. What your accountant actually wants from your statements generally comes down to that same distinction: clean, individual rows with enough context attached to categorise them correctly, delivered on a schedule that keeps pace with the reporting period rather than arriving all at once at deadline time.

Clients who genuinely have nothing but bank statements to work from, no invoices, no separate expense log, face a related but distinct problem. Filing from bank statements alone is workable, but it means every categorisation decision has to be inferred from a description line and a counterparty name, which is slower and more error-prone than working from source documents. Getting a client onto a habit of digital records now, even a simple one, is cheaper than reconstructing categories from bank descriptions later.