What a Digital Link Actually Is, and Where Yours Breaks
Everyone checks that the submission is electronic. The submission is almost never the problem — the problem is a step three stages earlier where somebody read a number off one screen and typed it into another, and the fact that the last step was an API call does not repair it.
There is a specific way that Making Tax Digital compliance fails, and it is not the way people prepare for. Teams check that their VAT return leaves through software rather than through a browser form. That box gets ticked, correctly, and then the actual requirement goes unexamined — because the rule is not about the last step. It is about the whole chain.
A digital link is a transfer of data between systems without manual intervention. Not without difficulty, and not without review — without transcription. The moment a figure is read off one screen and typed into another, or copied from one spreadsheet cell into an unlinked one, the chain is broken at that point. It stays broken no matter how sophisticated everything downstream of it is.
Nothing here is tax advice, and the specifics of what HMRC accepts are HMRC's to set and to change — check the current position with them or with your adviser. What follows is about where chains break in practice, which is a question about how your systems are wired rather than a question about tax.
The chain is five steps and the break is almost always in the middle
Draw the path a single figure takes to reach a return. Most organizations have never drawn it, and the drawing is the whole exercise — it usually takes twenty minutes and finds the break immediately.
-
The transaction is recorded
An invoice is issued, a purchase is approved, an expense is entered. This step is nearly always fine, because it is the step everybody thinks of as "the system".
-
The transaction is summarised
Somebody or something produces a total per tax rate, per period. If this is a report the system generates, the link holds. If it is a spreadsheet that someone maintains alongside the system, look closely at how the numbers get into it.
-
The summary is adjusted
And here is where most chains break. Partial exemption, a correction from last quarter, a reclassified expense, an accrual. Adjustments are legitimate and unavoidable. The question is whether the adjusted figure is derived by a linked calculation or typed over the top of the original.
-
The adjusted figures are assembled into boxes
Nine of them. If this happens in a workbook where some cells are formulas pointing at the summary and some are hard-typed values, the chain holds for the first kind and not the second — and nothing visually distinguishes them.
-
The boxes are submitted
The step everybody audits, and the one least likely to be wrong. A compliant submission of figures that arrived by transcription is a compliant submission of a broken chain.
A compliant final step does not repair a typed middle one. The chain is only as digital as its weakest link, and the weakest link is usually an adjustment nobody thought of as data entry.
What counts, and what only looks like it counts
The distinction that matters is not electronic versus paper. Both columns below are entirely electronic. One transfers data and the other re-creates it.
| This is a link | This is transcription wearing a link's clothes |
|---|---|
| An export from one system imported by another, in a format the second system reads | An export opened in a spreadsheet, where the relevant figure is then read and typed into a different workbook |
| A formula in cell B7 pointing at another sheet or another file | A value in cell B7 that was correct when somebody typed it last quarter |
| An API call, a scheduled file transfer, a database view | An emailed PDF report that a person works from |
| A linked pivot or query that refreshes from source | A screenshot pasted into a pack, however carefully labelled |
| Copy-and-paste of a cell reference between linked workbooks | Copy-and-paste of a value, which loses its origin the moment it lands |
The uncomfortable one
Copy-and-paste is the case people argue about, and the honest test is not the keystroke — it is whether the destination can still be traced to the source afterwards. A pasted value cannot. Once it lands it is indistinguishable from a number somebody invented, which is exactly the property the rule exists to remove.
Why this is really a question about your purchase ledger
Chains break where data is thin, because a thin record forces a person to supply what the record cannot. On the sales side, most systems are fine: an invoice carries its own tax rate per line, so the output figures are derivable and the link holds without anybody trying.
The input side is where the typing happens. If your purchase records hold an amount but not the rate that produced it, and not the kind of tax it is, then no calculation can decide what is recoverable — so a person decides, and their decision arrives in the return as a typed number. The break is not a process failure. It is the only thing the person could have done, given a record that had already thrown the answer away.
One quarter, traced back
Illustrative rather than surveyed, and deliberately unremarkable — this is not a badly run finance function. It is an ordinary one where the sales side flows and the input side is reconstructed each quarter by somebody competent. Note which two boxes they are: input tax and total purchases, the two the purchase ledger owns. The fix is never "be more careful". It is to hold the rate at the point the purchase is recorded, so there is something for a calculation to work from.
Five questions that find the break in one meeting
Ask these of your own stack first and of any vendor second. They are answerable in minutes, and vague answers are themselves the finding.
Take one figure and follow it
Show me last quarter's input tax figure and take me back to the individual purchases behind it, without opening a spreadsheet.
What a good answer sounds like
A drill-down, or an export whose rows sum to the figure.
What a bad answer is telling you
If a spreadsheet has to be opened, the spreadsheet is part of your compliance chain and nobody has been treating it as such.
Which cells in the return workbook are formulas and which are typed values?
What a good answer sounds like
Somebody knows, or can find out in five minutes.
What a bad answer is telling you
Nobody knowing is the answer. A workbook nobody can characterise is a workbook where the chain state is unknown.
Where is the tax rate stored on a purchase — not the amount, the rate?
What a good answer sounds like
A named field on a named record.
What a bad answer is telling you
If the answer is that the amount is stored and the rate is understood, then recoverability is being decided by a person every quarter.
What happens to the chain when an adjustment is made?
What a good answer sounds like
The adjustment is itself a record, with its own reason, that the total derives from.
What a bad answer is telling you
If adjustments are typed over the top of derived figures, the chain breaks at exactly the point where the numbers change most.
If we changed accounting systems next year, which of these links would survive?
What a good answer sounds like
A short honest list.
What a bad answer is telling you
The links that would not survive were never links to your data — they were links to one product's way of exporting it.
The architectural conclusion, which is duller than it sounds
Let the system that owns the purchase ledger own the return. That is not a concession, it is the shape of the requirement: the return is mostly a question about input tax, input tax is a property of purchases, and the system holding the purchases is the only one that can answer it without a person in the middle.
It follows that "one system for everything" is worth much less here than it sounds, and is worth actively distrusting when the single system does not hold tax on the purchase side. A vendor offering an end-to-end VAT story over records that cannot distinguish a recoverable input from a blocked one is offering a spreadsheet with extra steps and a nicer submission button.
The one-line version
Audit your chain from the transaction forward rather than from the submission backward. The submission is almost certainly fine. The adjustment three steps earlier probably is not, and the reason is usually a purchase record that never held a rate.
