What Making Tax Digital actually mandates
Making Tax Digital for VAT is not a filing format. It is a requirement about how the numbers move. Under MTD, VAT-registered businesses must keep their VAT records in digital form and submit returns to HMRC through an approved API — not by typing figures into the government gateway by hand.
Two obligations sit underneath that headline. The first is digital record-keeping: the required VAT data must be held digitally, in software, from the point the transaction is recorded. The second is the digital link. Where data moves between systems on its way to the VAT return, that transfer must be a digital link — an API call, a linked cell, an import — not a manual re-key or a copy-paste. HMRC treats a broken digital link as a compliance failure even when the final number is correct.
This is where spreadsheet-based VAT processes fall down. A business can keep immaculate records in a spreadsheet and still fail MTD if the path from that spreadsheet to the return involves retyping a figure. Bridging software exists to paper over that gap, but a bridge is a symptom: it means the system of record and the system of filing are two different things held together by an export.
MTD for VAT now applies to all VAT-registered businesses regardless of turnover. MTD for Income Tax Self Assessment is being introduced on a phased basis for sole traders and landlords above defined income thresholds, with the first mandated group expected in April 2026 and subsequent thresholds following. If your ERP touches income that will fall under ITSA, the same digital-link logic will apply there.
PAYE, RTI, and the payroll side
VAT gets the attention, but for most UK businesses the more frequent HMRC conversation is payroll. Real Time Information requires that PAYE data — pay, tax, National Insurance, student loan deductions — is reported to HMRC on or before the day employees are paid, through a Full Payment Submission. An Employer Payment Summary reconciles adjustments such as statutory pay recovered.
The on-or-before rule is the part that trips up businesses running payroll in a system disconnected from the rest of finance. If payroll lives in a separate application, someone has to run it, submit the FPS, and then re-enter the resulting journal into the accounting ledger. Every one of those handovers is a place for the numbers to diverge and for a late or missing submission to generate a penalty.
Auto-enrolment pension obligations compound this. Contributions must be assessed, deducted, and reported to the pension provider on schedule, with the employer contribution tracked against the same payroll run. When payroll, the general ledger, and pension reporting are one system, the FPS, the journal, and the pension file all derive from a single payroll calculation. When they are three systems, month-end becomes a reconciliation exercise before it becomes a review.
The question to ask is not whether your ERP can produce payroll numbers. It is whether the RTI submission and the ledger posting come from the same calculation, or whether a human sits between them.
Where UK e-invoicing is heading
The UK does not currently mandate structured e-invoicing for domestic B2B trade. That is the accurate position as of 2026, and any vendor telling you otherwise is overstating the requirement. But the direction of travel is visible, and finance teams that plan for it will not be caught reacting.
The government has run a consultation on standardising electronic invoicing and promoting its adoption across UK businesses and the public sector. The public sector already accepts structured e-invoices through the Peppol network, which is the same framework used across much of the EU. A future move toward broader e-invoicing and digital reporting — following the pattern being set by the EU's ViDA reforms and by individual member states — is plausible rather than announced.
What this means practically is measured, not urgent. You do not need a UK e-invoicing mandate solution today because there is no firm mandate today. What you need is an architecture that would not have to be rebuilt if one arrives: the ability to generate structured invoice data, to connect to a network like Peppol, and to produce the kind of transaction-level digital reporting that these regimes require. A platform already doing real-time compliance elsewhere — clearance models in the Gulf, IRN generation in India — has that capability in its foundations, whether or not the UK switches it on.
Questions to ask a UK ERP vendor
Before you accept a claim of MTD compliance, put these questions to the vendor directly.
First: is the VAT return submitted through HMRC's API from within the system, or does it export to bridging software? If the answer involves a bridge, ask what the digital link is between the ledger and that bridge, and whether it survives an HMRC audit of the record-keeping chain.
Second: where do the VAT figures originate? A compliant system holds the digital records from the point of transaction. Ask to see the path from a posted invoice to the box on the return without a manual step in between.
Third: does payroll RTI submission share a calculation with the ledger posting? Ask for the FPS and the payroll journal to be produced from one run, and ask what happens if payroll is corrected after submission — the EPS handling and the ledger adjustment should both follow automatically.
Fourth: how would the platform handle a future UK e-invoicing or digital reporting mandate? You are not buying that capability today, but you are buying an architecture. Ask whether structured invoice output and Peppol connectivity already exist in the platform for other markets, or whether they would be net-new development if the UK moves.
Fifth: MTD for Income Tax is arriving in phases. If any part of your operation falls under ITSA, ask how the platform handles quarterly updates and the digital-link requirement for income as well as VAT.