Blog
Insights to Help Your Practice Work Smarter
- How it works
- Features
- Pricing
- About Us
- Blog
- FAQs
- Contact Us
- Start free trial
Tanvir Alam•Sep 16, 2026•8 min read•Tax & Compliance
MTD digital record compliance for non-standard receipt formats, subscriptions, foreign currency invoices, non-VAT-registered supplier receipts, informal payment confirmations, split costs, and refunds, requires deliberate, consistent treatment that generic MTD guidance rarely specifies, even though none of these formats are inherently non-compliant.
MTD digital record rules are clear on the standard case: a till receipt, three fields extracted, filed digitally, done. What HMRC's guidance is far less specific about is the growing share of business spending that never produces anything resembling a standard receipt in the first place. A SaaS subscription renewal, a foreign supplier invoice with no UK VAT treatment, a WhatsApp payment confirmation, a receipt for a purchase split between two clients sharing an account. These are the cases where practices actually get stuck, and where generic MTD explainers tend to wave a hand and move on.
This is a working reference for exactly those formats, part of the same broader question as what receipt capture software actually needs to handle for MTD compliance, not another walkthrough of the three required fields.
A software subscription typically generates an emailed receipt with a supplier name, an amount, and a date, but frequently without the itemised VAT breakdown a till receipt provides, and sometimes without a clear description of what was actually purchased beyond a plan name or product code. For MTD digital record purposes, the date, amount, and category are still capturable from this document, provided the category assignment is done deliberately, software subscription, rather than defaulted to a generic 'other' bucket that erodes the record's usefulness at review.
The genuine risk with subscriptions is not the individual record. It is drift: a subscription renews monthly without a human looking at the receipt each time, and a category assigned once, correctly, silently becomes wrong if the service or its use in the business changes months later without anyone revisiting the categorisation.
A receipt from a foreign supplier presents two separate questions: what currency was the transaction in, and what figure should the digital record actually show. The digital record should capture the transaction in its original currency alongside a clearly documented conversion to GBP, using a consistent, defensible exchange rate source (HMRC's published monthly rates are the standard reference point), rather than an ad hoc rate pulled from whatever conversion tool happened to be open at the time.
In short: a foreign currency receipt is not compliant as a digital record just because a GBP figure appears somewhere in your ledger. The original currency, the converted figure, and the rate source used all need to be part of the record, not just the final number.
A receipt from a small or non-VAT-registered supplier will not carry a VAT number or an itemised VAT breakdown, which sometimes leads to it being treated as a lesser or incomplete document. For MTD's core digital record requirement, date, amount, category, this is not actually a problem. VAT-specific documentation only matters where VAT reclaim is being made, which does not apply to a non-VAT-registered supplier's invoice in the first place. Do not hold this type of receipt to a VAT-invoice standard it was never meant to meet, and do not query it as incomplete on the assumption it should look like one.
An increasing share of small, informal purchases, particularly cash-adjacent ones like a market stall purchase or a small tradesperson payment, generate a payment confirmation through WhatsApp, SMS, or a payment app notification, rather than anything resembling a traditional receipt. These can support a valid digital record provided the same three fields are captured from them: date, amount, and category, with the message or notification itself retained as the supporting evidence behind the record, the way a photographed till receipt would be, which is exactly the workflow behind collecting receipts over WhatsApp deliberately rather than leaving it to chance.
The practical risk here is not compliance ambiguity so much as loss. A WhatsApp message documenting a business payment is easy to lose in an ordinary personal conversation thread, get deleted during a phone clear-out, or simply never get forwarded to the practice at all. Treating these confirmations as first-class receipt documents, worth forwarding and filing the moment they arrive, closes a gap that a policy focused only on 'proper' receipts misses entirely.
A single receipt covering a mixed personal-and-business purchase, or a cost genuinely shared between a client's sole trade and a separate rental property they also hold, needs to become more than one digital record, not one record with a note attached explaining the split. Each portion needs its own date, amount, and category, apportioned clearly, with the apportionment method documented, a percentage split, a specific itemised breakdown, rather than assumed and never written down.
This is one of the more common places a technically-present digital record still fails a closer HMRC review, because the record exists but does not actually reflect what was genuinely a business cost versus a personal or unrelated one.
Occasionally a business cost is paid in cash with no receipt issued at all, a small tip, a car park machine that does not print one, a market trader who does not carry a pad. HMRC's position on this is more permissive than practices sometimes assume: a contemporaneous note recording the date, amount, and purpose can serve as the digital record where no receipt exists, provided it is genuinely made at or close to the time of the transaction, not reconstructed later from memory.
The distinction that matters for MTD purposes is between an occasional, genuinely receipt-less transaction handled this way, and a pattern of it becoming the default method for anything a client finds inconvenient to document properly. A single contemporaneous note is a reasonable digital record. A quarterly submission built substantially on reconstructed notes is a different, weaker position that will not hold up as well if closely reviewed.
A client's cloud storage subscription is correctly categorised as a software cost when it is first set up. Eighteen months later, the client has repurposed the same subscription primarily for personal photo backup, while continuing to store a small amount of business documentation on it too. The monthly receipt looks identical to the one filed at setup. Nothing about the document itself signals that the underlying business use has changed.
Without a periodic review, this receipt continues to be filed as a full business software cost indefinitely, based on a categorisation decision that was correct eighteen months ago and has not been true since. This is precisely the kind of drift that a policy focused only on capturing receipts at the point of purchase misses, because the receipt capture itself never changes. Only the underlying facts do, quietly, with nothing in the document to flag it.
A refund or credit note is its own transaction requiring its own digital record, dated to when the credit note or refund actually occurred, not backdated to match the original purchase. Netting a refund against the original expense informally, adjusting a single record rather than creating a linked second one, breaks the same digital-link principle that governs manual re-keying: the record needs to reflect what actually happened, when it happened, traceably.
Receiptflow captures whatever format a receipt actually arrives in, email, forward, photo, or informal confirmation, and files it as a proper digital record rather than leaving the edge cases to manual judgement calls. Start a free trial and see how it handles the receipts that don't look like receipts.
Most MTD digital record guidance is written around the clean case: a legible till receipt with a clear VAT breakdown. Most of the actual risk in a busy practice sits in the formats that do not look like that at all, subscriptions, foreign invoices, informal payment confirmations, split costs, and refunds. None of these are inherently non-compliant. They just require a deliberate, consistent treatment that a generic 'scan your receipts' policy does not specify, and that gap is exactly where records quietly stop being defensible without anyone noticing until a review asks the question directly, a version of the same lesson practices are still absorbing from MTD's first year in practice.
Receiptflow handles the messy real-world formats, not just the clean ones. See how it fits your practice's receipt mix.
Yes, provided the date, amount, and category are captured and the category is assigned deliberately rather than defaulted, since subscription receipts often lack the itemised detail of a standard till receipt but still meet MTD's core content requirement.
The record should capture the original currency and amount alongside a GBP conversion using a consistent, documented exchange rate source, such as HMRC's published monthly rates, rather than just recording the final converted figure alone.
Yes, MTD's core digital record requirement only needs date, amount, and category, which a non-VAT-registered supplier's receipt can satisfy; VAT-specific documentation only matters where a VAT reclaim is being made.
Yes, provided the date, amount, and category are captured from it and the message itself is retained as supporting evidence, though these are easily lost if not forwarded and filed promptly, which is a practical risk worth addressing directly with clients.
It should be split into separate digital records for each portion, with the apportionment method clearly documented, rather than filed as a single record with an assumed or undocumented split.
A contemporaneous note recording the date, amount, and purpose, made at or close to the time of the transaction, can serve as the digital record, though this should remain occasional rather than becoming the default method for anything inconvenient to document properly.
Bridging software still works for a narrow slice of clients. For everyone else, it has quietly become the choice that defers a harder problem to a worse moment. Here is where the line sits.
HMRC's recognised software list is long and unhelpful for actually choosing anything. Here is the two-layer model that makes the decision straightforward for your practice, in one sitting.