MTD VAT has been live for the bulk of the VAT-registered population since April 2022. The submission mechanism is stable. The most common failures now are not technical bugs in MTD-recognised software, but data and authorisation issues at the practice end - issues that present as cryptic error codes when the submission fires and that consume disproportionate time to resolve under deadline pressure.
This is a practitioner-level summary of the rejection codes most agents encounter monthly, what each one actually means in plain language, and the upstream workflow change that prevents the next occurrence.
CLIENT_OR_AGENT_NOT_AUTHORISED
The most common rejection by volume. It means HMRC does not recognise your firm as the authorised agent for that VAT registration. The cause is almost always one of three things: the client has not completed the MTD-specific digital handshake (a 64-8 alone is not enough for MTD VAT), the authorisation was set up under a different agent services account, or the client has cancelled the authority in their HMRC online account.
Upstream fix: every VAT-registered client should have MTD VAT authority confirmed before the first quarter you act for them. Add it to the new-client checklist as a discrete tracked item, separate from the general 64-8. Run a quarterly reconciliation between your client list and your agent services account authorised list to catch silent revocations.
VAT_REGISTRATION_NUMBER_NOT_FOUND
HMRC cannot match the VRN supplied in the submission to a live VAT registration. Causes: typo in the client record (one transposed digit is the classic), the client has deregistered, or the VAT registration is suspended pending an HMRC compliance check. Less commonly, a recently-issued VRN has not yet propagated to the MTD systems - a 24-48 hour delay is occasionally observed.
Upstream fix: validate VRNs at the point of client onboarding using the HMRC VAT Number Checker service. Re-validate annually as part of the AML review cycle. For deregistered clients, archive the record rather than leaving it active - accidentally attempting to file for a deregistered client is a wasted hour every time it happens.
BUSINESS_ERROR / INVALID_REQUEST
These are generic catch-alls returned when the submission payload fails HMRC validation. The most common underlying issue is a period mismatch - the firm is trying to submit for a period that is not yet open, has already been submitted, or does not align with the client's actual VAT stagger. The submission software will usually give a more specific message under the headline code if you drill in.
Upstream fix: pull the client's open obligations from HMRC before preparing the return, rather than assuming the stagger you have on file is correct. MTD-recognised software does this automatically; bridging tools sometimes do not. If a client is on monthly returns having previously been quarterly, your records may still show quarterly.
DUPLICATE_SUBMISSION
HMRC has already accepted a submission for this period. Usually triggered when a return was filed manually in HMRC online, then a colleague tries to fire it again through the MTD software. Occasionally caused by genuine software duplication where a network timeout left the firm uncertain whether the original attempt succeeded.
Upstream fix: every VAT return should have a single named owner from preparation through to filing confirmation. Two people should never be in a position to fire the same submission. Practice management software is the natural home for this - Accupe surfaces every open VAT job with a clear owner, so the question of "did anyone already file this?" has an answer before the second attempt happens.
INVALID_DATE_RANGE
Period start or end dates in the submission do not match the obligation HMRC is expecting. Sometimes a calendar versus VAT-period mismatch (March 31 versus March 30 cutoffs), sometimes a typo, occasionally a software defect when handling short periods following deregistration or stagger changes.
- Always pull period dates from the HMRC obligations API rather than typing them
- Treat short periods (registration, deregistration, stagger change) as separate exceptions requiring extra review
- Reconcile period dates against the client's VAT certificate during onboarding
- Flag any period that does not match a standard quarterly or monthly cadence for manual sign-off
INTERNAL_SERVER_ERROR and HMRC outages
HMRC's MTD platform has good but not perfect uptime. Genuine outages do occur, particularly around month-end and the 7th of the month following a quarter. Check the HMRC online service status page before assuming an internal error is a problem at your end. If HMRC has a confirmed outage, document the time, the reference number, and your retry schedule - useful evidence if a deadline subsequently slips and a penalty needs to be appealed.
Build a 24-hour buffer into your filing schedule for this reason. Targeting submission by the 5th rather than the 7th of the month means HMRC outages on the 6th do not become your problem.
The workflow fix nobody talks about
Every rejection above shares a root cause: the firm finds out about the problem after attempting to submit, often under deadline pressure, with limited time to investigate. The single highest-leverage fix is pre-submission validation a week before the deadline - pull obligations, validate authority, validate VRN, validate period dates, and only then prepare the return.
Practice management software can drive this as a workflow stage. Stage one: pre-submission validation due by deadline minus seven. Stage two: preparation due by deadline minus three. Stage three: review and client approval due by deadline minus one. Stage four: submission. Accupe orchestrates the visibility - which client is at which stage, which has slipped, who owns each - while the actual MTD submission happens in the client's bookkeeping software or your bridging tool.
Closing
MTD VAT rejections are predictable. Authorisation, registration number, period dates, duplicates - the same handful of failure modes account for nearly every issue. Treat them upstream by validating before you prepare, by giving every return a single named owner, and by building a calendar buffer for HMRC outages. The hours you save in fire-fighting at the 7th-of-the-month are hours you can reinvest in the work clients actually pay for.