The rules sit in the Income Tax (Digital Requirements) Regulations 2021 — specifically Regulations 4 to 7, which between them define what counts as a digital record, what “functional compatible software” means, and what HMRC consider a “digital link”. The drafting is short. The downstream operational consequences for a firm onboarding hundreds of clients are not.
Most partners we speak to have read the topline: “records must be kept digitally.” What catches firms out is the second half — that the digital record has to exist from the point of transaction, in a structured form, and that any movement of that data between systems before submission must travel by a digital link. A receipt photo isn’t a record. A spreadsheet copy-pasted into bridging software isn’t compliant. The detail matters.
What HMRC actually requires per transaction
Regulation 6 of the Digital Requirements Regulations sets the minimum data fields. For property and self-employment income within MTD ITSA, every transaction must be captured digitally with at least:
- Amount — the gross figure for the transaction.
- Date — the date of the transaction itself, not the date it was recorded.
- Category — the income or expense category the transaction belongs to (rent received, repairs, insurance, mortgage interest, and so on).
- Source — which business the transaction relates to. For landlords with multiple properties, this means the specific property, because the property business as a whole is the source but per-property breakdown is needed for accurate categorisation and adjustment.
These four fields are the floor, not the ceiling. A firm running a useful MTD-ITSA workflow will want notes, supporting evidence links, and a reviewer’s sign-off field on top — but the four are what HMRC will look for in a compliance check.
“From the point of transaction” — what that means
Regulation 4 requires records to be kept and preserved in a digital form. HMRC’s guidance on MTD ITSA, mirroring the MTD VAT approach in VAT Notice 700/22, is that the digital record must exist contemporaneously with the transaction — not reconstructed at quarter end from a shoebox.
In practice HMRC have signalled they will accept a digital record created within a reasonable period after the transaction settles — bank-feed reconciliation the next working day, or a weekly batch, is fine. What is not fine: rolling everything up on 5 July from bank statements, with no contemporaneous structured record in between. The points-based penalty regime covers late submissions; the record-keeping regime sits beneath that and can be tested independently in a compliance check.
The digital link rule
Regulation 7 — borrowing the language used in MTD VAT — is the one that quietly drives most firm tooling decisions. A digital link is an electronic transfer of data between software programmes, products or applications, where the data moves without manual intervention. HMRC’s examples of acceptable digital links include:
- API transfers between two pieces of software (the cleanest case).
- CSV or XML import/export between systems, where the file is produced by one system and imported by another without manual editing.
- Linked cells in a single spreadsheet — including cells linked to a separate sheet within the same workbook, or to another workbook by formula reference.
- An emailed file consumed by bridging software, provided it is imported without re-keying.
What is not a digital link: copy-paste, re-typing a figure from one system into another, manually adjusting totals in a spreadsheet before they reach the bridging tool, screenshots, or printed reports re-keyed by a junior.
The compliance test is end-to-end: from the record at point of transaction, through any intermediate systems, into the functional compatible software that submits to HMRC. If any one step in that chain involves a human re-keying a number, the chain breaks.
The spreadsheet route — allowed, with conditions
Spreadsheets remain allowed under MTD ITSA, which surprises firms expecting the regulations to push everyone onto cloud bookkeeping. Regulation 5 defines “functional compatible software” as software (or a set of compatible software programmes) that can keep digital records, preserve them, and provide HMRC with information by API. A spreadsheet plus bridging software counts — provided the bridge imports by digital link.
The catch: the bridging step is where most spreadsheet workflows fall over. If a junior opens the spreadsheet, runs a SUMIF, and types the quarterly totals into the bridging tool, that is not compliant — even though both ends are digital. The bridge has to read the spreadsheet itself.
Receipt photos: evidence, not record
One of the most common misreadings of the regulations is that a photo of a receipt counts as a digital record. It does not. A photo is unstructured: there is no machine-readable amount, date, category or source field. It is supporting evidence, not a digital record in the Regulation 6 sense.
The compliance position is that a structured digital record must exist alongside the photo. Most modern bookkeeping tools — and Otto itself — handle this by running OCR on the receipt, populating the four required fields automatically, and presenting the photo as attached evidence on the same line. The photo is preserved (HMRC’s general record-retention period applies); the structured record satisfies MTD; the firm has both for a compliance review.
If your workflow today is “client WhatsApps a photo of a receipt and we file it in Dropbox”, that does not meet the digital-record standard, even though the file is digital. The transaction has to be captured as data.
Penalties for falling short
The headline penalty regime under MTD ITSA is points-based — covered in detail in our HMRC penalty points guide — and it targets late or missed quarterly submissions. One point per missed deadline; £200 fixed penalty at the threshold (four points across a 12-month cycle for quarterly obligations); £200 per subsequent miss until points reset.
Record-keeping failures sit alongside that regime. A submission made on time but built on records that don’t satisfy Regulation 6 — missing fields, no digital link, reconstructed at quarter end — exposes the taxpayer to inaccuracy penalties under the existing FA 2007 Schedule 24 regime if the inaccuracy leads to under-stated tax. The points system does not protect against this. A clean quarterly submission cycle built on broken records is worse than a late submission built on clean ones.
For firms, the operational read is that the time to test record-keeping is at onboarding, not at submission. By the time a Q1 update is being prepared on 1 August, the records either exist properly for the period 6 April to 5 July or they don’t.
Worked example: a landlord with two properties
Take a landlord — call her J — with two residential lets. She tracks Property A in a spreadsheet she’s used for years. Property B she onboards onto Otto via her accountancy firm in May 2026. The 2026/27 tax year is her first under MTD ITSA. How does compliance look across the two?
Property A — spreadsheet route. The spreadsheet captures every transaction with date, amount, category, and (implicitly, because the workbook is for Property A) source. So far so compliant. To meet MTD ITSA, the spreadsheet has to feed into bridging software via a digital link — meaning the bridge imports the file directly, or pulls from a linked range, with no manual re-keying of quarterly totals. The firm needs to confirm the bridge is one of HMRC’s recognised MTD-compatible products and that the import is automated.
Property B — Otto. Transactions flow in from J’s bank feed; Otto categorises them, the firm reviews and confirms. Each line carries amount, date, category, and source (Property B). The submission to HMRC is via API from the firm’s tax software, with the prepared data delivered to that software by digital link. End-to-end digital chain.
Combined Q1 update. J’s firm submits a single quarterly update for her UK property business, covering both properties. The Property A numbers travel: spreadsheet → bridge → tax software → HMRC. The Property B numbers travel: bank feed → Otto → tax software → HMRC. Both chains are digital. The quarterly figures might be, say, £14,200 of rent received and £3,850 of allowable expenses across the two — the point is not the numbers, it’s that the firm can demonstrate, on request, a Regulation 7-compliant link from every original transaction to the submitted total.
Where this commonly breaks in real firms: the spreadsheet half. A partner reviews the spreadsheet at quarter end, eyeballs the totals against the bridge, and adjusts a couple of figures manually because something looks off. Those adjustments are re-keys. The chain is broken. The firm’s defensive position — that the numbers are right — does not address the record-keeping failure.
What firms need to test before Q1
The minimum due-diligence checklist on each client:
- Are records being created at point of transaction? Bank feeds, OCR on receipts, real-time categorisation — or a shoebox?
- Do the records carry all four required fields? Amount, date, category, source per transaction.
- Is the chain from record to submission unbroken? Walk the data path. Identify every system boundary. Confirm each crossing is a digital link.
- Is the bridging or submission tool on HMRC’s list? Functional compatible software, in Regulation 5 terms.
- Are receipt photos paired with structured records? Not stored alone in a folder.
For firms running this across a book of even fifty clients, this is the work. It’s less glamorous than the quarterly submission itself, and easier to defer. The clients whose records were already clean will be fine. The ones where there’s a spreadsheet, a bridging tool, and a partner who “just tidies it up at the end” are where the regulatory risk sits.
Otto closes the digital-record gap at intake
Otto captures records at the point of transaction with all four Regulation 6 fields, links receipt photos to the structured line, and hands your tax software a clean, MTD-compliant dataset by API. If your firm is onboarding MTD ITSA clients this year, book a 30-minute demo.
Book a demo