Ready to send and receive Peppol e-invoices by 1 April 2029: every invoice flow mapped, supplier and customer records cleaned with a person approving each change, the ERP mapping tested against the rules, and the paper and PDF tail handled until it goes.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
From 1 April 2029, VAT invoices between UK VAT-registered businesses, and to VAT-registered public bodies, must be issued and received as structured e-invoices over Peppol, through a certified access point. A PDF attached to an email won't count, and neither will a scan or a Word file. HMRC and the Department for Business and Trade published the roadmap on 28 October 2026. The detailed UK standards, the business identifiers and the exemptions are still to come, between spring 2027 and April 2028.
Most of the work isn't technical. A typical business of this size has thousands of supplier and customer records built up over years: duplicates, VAT numbers that are missing, mistyped or belong to a company that has since been sold, addresses that no longer match, and no record of who can send or receive an e-invoice. Every one of those records becomes a delivery address on a network. If it's wrong, the invoice goes nowhere, or to the wrong place.
Meanwhile the old world carries on. Paper and PDF invoices will keep arriving until 2029 and, from suppliers who are exempt or slow, for a while after. EDI with large customers can continue, but the business must also be able to exchange e-invoices over Peppol. And the ERP has to produce invoices that pass the new rules first time, including credit notes, self-billing and the odd VAT cases nobody has looked at in years.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Active suppliers and customers with a verified VAT number, a matched company record and a known e-invoicing status.
ExampleFrom around 60% to over 98% of invoice volume
The share of invoice volume, in and out, where the other party has confirmed it can send or receive e-invoices.
ExampleOver 90% by summer 2028
Test e-invoices from the ERP that pass every validation rule first time, including credit notes.
ExampleOver 99% before readiness testing
Inbound invoices still arriving as PDF or paper.
ExampleFalling every quarter, tracked by supplier
Master data changes made with a recorded human approval.
Example100%, always
How often the master data team accepts the AI's proposed corrections unchanged. Very high can mean nobody is checking; very low means it isn't helping.
ExampleStable, and sampled weekly
Cross-sector rules are on the UK regulation map.
VAT-registered persons, including VAT-registered public bodies, must be able to issue and receive e-invoices for taxable supplies to other UK VAT-registered persons. There is no size-based phasing. Exemptions will be tightly limited, for the digitally excluded and some narrow technical cases, with details by April 2028. Cross-border supplies aren't in scope, and non-established businesses are treated like UK ones. The government plans to legislate in the Finance Bill following Budget 2026, expected to become law in spring 2027, subject to Parliament.
Peppol is the core framework. Businesses connect through a certified access point, directly or through their software provider. HMRC will become the UK Peppol Authority; the role currently sits within NHS Supply Chain. UK-specific rules, business identifiers and access point certification will be set out after a technical consultation in spring 2027. The Peppol Authority won't receive copies of business invoices. A separate consultation on digital reporting of e-invoice data was launched at Budget 2026, and no decision has been taken, so don't design for real-time reporting yet, but keep the data ready.
Data must move between the parts of your VAT system through digital links, not copy and paste or re-keying. E-invoices received through the access point go into the ERP through its API, and the VAT return still comes from your MTD-compatible software. The roadmap says e-invoicing builds on MTD for VAT.
The content rules for a VAT invoice still apply, and the invoice remains the evidence for reclaiming input tax. VAT records are kept for at least six years. Until 2029, PDF invoices are acceptable where the customer agrees and authenticity, integrity and legibility are assured. VAT treatment, tax points and invoice corrections are decided by the tax team, not by the AI.
Public sector buyers must already accept and process e-invoices that comply with BS EN 16931-1:2017 and a listed syntax (GOV.UK guidance, updated 20 July 2026). Peppol is widely used in the NHS. If you sell to public bodies, your public sector invoices are the natural first flow to move.
Sole traders' and partnerships' names, VAT numbers, addresses and bank details are personal data, as are supplier contacts in outreach. That means a DPIA, processing in UK regions, a clear retention period, access by role, and a contract that stops providers training their models on your data.
Only relevant if you have EU establishments. ViDA brings e-invoicing and digital reporting for intra-EU B2B supplies from 1 July 2030, and member states can now mandate domestic e-invoicing earlier. Belgium has required structured B2B e-invoices since 1 January 2026; Germany has required businesses to receive them since 2025, with issuing phased in over 2027 and 2028. Those entities may need to be ready before the UK ones.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Peppol access pointAccess points must be certified before they operate on the network. Buy the service, don't build one. Your ERP or software provider may offer it. | Your certified access point provider, connected by API | Your certified access point provider, connected by API | Your certified access point provider, connected by API |
| Intake: email, scans, filesKeep the original file and its arrival time, whatever the channel. | Amazon SES, API Gateway, Amazon S3 | Logic Apps connectors, API Management, Blob Storage | Your mail server, Kong, Ceph or IONOS S3 Object Storage |
| Reading legacy invoicesOnly for PDF and paper. Structured e-invoices skip this step. Day-to-day AP matching is in the invoice processing playbook. | Amazon Textract (AnalyzeExpense); Bedrock Data Automation is an alternative and processes London requests in eu-west-2 | Azure Content Understanding (includes Document Intelligence's invoice model) | Open-source parsing (e.g. Docling) plus an open-weight vision model |
| Validation against the standardDeterministic. Today: the EN 16931 and Peppol BIS Billing 3.0 rules. When HMRC publishes the UK-specific rules, add them. The model explains failures; it never decides validity. | AWS Lambda running the published Schematron rules | Azure Functions running the published Schematron rules | A validation service on Kubernetes running the published Schematron rules |
| Master data checksLookups run as code, with the result and date stored as evidence against each proposed change. | AWS Lambda calling HMRC's VAT number check and the Companies House API | Azure Functions calling HMRC's VAT number check and the Companies House API | A small service on Kubernetes calling HMRC's VAT number check and the Companies House API |
| Canonical invoice modelOne internal shape for invoices and credit notes. The ERP maps to it; it maps to Peppol, EDI or the PDF the business still sends. | JSON schemas in your code repository | JSON schemas in your code repository | JSON schemas in your code repository |
| Reasoning and draftingProposes mappings and corrections, explains failures and drafts outreach. Both clouds offer a choice of models, including Claude. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Standards and mapping knowledge (retrieval)Indexed from the standards, HMRC guidance as it's published, your ERP's data dictionary, your VAT treatment notes and past decisions. | Bedrock Knowledge Bases | Foundry IQ, built on Azure AI Search | OpenSearch, or PostgreSQL with pgvector |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| WorkflowTracks each counterparty through outreach, and each master data change through approval. | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Events and queuesInbound e-invoices and delivery receipts from the access point arrive as events. | Amazon EventBridge, SQS (with dead-letter queues) | Event Grid, Service Bus (with dead-letter queues) | Apache Kafka or RabbitMQ |
| Link to the ERP and master dataApproved changes are written by the master data team's own process. This is also your MTD digital link. | API Gateway, plus your existing integration platform | API Management, plus your existing integration platform | Kong or your existing API gateway, plus your existing integration platform |
| Human reviewPeople approve where they already work. The readiness tracker is a status list, not master data. | In your ERP's master data and AP workflows, and the readiness tracker | In your ERP's master data and AP workflows, and the readiness tracker | In your ERP's master data and AP workflows, and the readiness tracker |
| GuardrailsInvoice text and supplier replies are untrusted input. A reply saying 'update our bank details' changes nothing. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protectionThe agents' identities have no write access to master data, invoices or the access point's sending API. | IAM Identity Center, KMS, Macie | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every proposal, approval, validation result and message sent, with who and why. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. | eu-west-2 (London) | UK South / UK West | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
Your ERP, supplier and customer master data, the billing run and the bank connection stay where they are. Many businesses run these on their own servers, and nothing in this design moves them.
Uses cloud AI
Legacy invoice reading, the standards index and the two agents can run in a UK cloud region, or on your own GPUs with open-weight models if supplier and customer data must stay in your estate. The access point is your provider's service either way.
How they connect
A private link (AWS Direct Connect or Azure ExpressRoute) and the API layer. Master data extracts and sample invoices go out for analysis; proposals come back as change requests, never as direct writes.
If the link drops
Invoicing carries on: the ERP bills, the access point sends and receives, and inbound invoices queue on your side. Clean-up and outreach pause, and catch up when the link returns.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Readiness agent (master data and outreach)
Where a person signs offThe master data team approves every change to a supplier or customer record, and a second person approves any change to bank details after a call-back to a number already held. AP, AR or procurement send every message. The agent's permissions are enforced by the platform's identity and policy controls and the ERP's own roles, not by instructions in a prompt.
Mapping and exception agent
Where a person signs offThe tax team signs off the VAT mapping and every VAT treatment question. Mapping changes go through the ERP team's change control and test pack. Invoices are issued by the ERP's normal billing run and sent by the access point; credit notes are raised by AR under finance's control. The agent's permissions are enforced by the platform, not by the prompt.
Treat the access point as the transport, and keep it at the edge. Your ERP produces an invoice in your canonical model, a deterministic step turns it into the e-invoice format, the validation rules check it, and only then does it go to the access point's API. Inbound, the access point delivers e-invoices and delivery receipts as events onto your queue, and they're validated again before they reach the ERP.
Validation is code, not judgement. The EN 16931 and Peppol BIS Billing 3.0 rules are published as Schematron, and HMRC will publish the UK-specific rules after the 2027 consultation. Run them as a versioned service, so every invoice records which rule set it passed. The model's job is to explain a failure to a person and propose a fix, never to wave an invoice through.
One canonical invoice model makes the next three years manageable. Large customers stay on EDI, some suppliers move to Peppol early, and others keep sending PDFs. Each format maps to and from the same internal shape, so the ERP integration is built once, and a supplier moving channel is a configuration change, not a project.
Idempotency matters more on a network. Each invoice carries a key made from the sender's identifier, the invoice number and the issue date. If the same invoice arrives by Peppol and by email, or the access point redelivers, it posts once.
Everything queues, and the AI is optional. If the agents are switched off, invoices still flow, master data changes still go through the normal process, and outreach is done by hand. If the ERP is down, inbound e-invoices wait safely and post in order when it returns.
Inventory every invoice flow in and out by counterparty, channel and volume; profile master data quality; check what your ERP and current software providers already support; start shortlisting access point providers.
Gate · must be true to passBaseline agreed, flows and owners mapped, master data access confirmed, DPIA started, tax involved.
The readiness agent works through the top 200 suppliers and customers: checks, proposed corrections, readiness status and drafted outreach. The master data team approves; AP and AR send. One flow, such as invoices to public sector customers, goes through a test access point.
Gate · must be true to passProposal acceptance and evidence quality within agreed limits, every change approved and logged, test invoices passing the current rules.
Map the ERP to the standard as HMRC's technical requirements are published, test every invoice type including credit notes and self-billing, and choose the access point provider. Extend outreach to the rest of the base.
Gate · must be true to passFirst-time pass rate above target on the current rule set, tax sign-off on the VAT mapping, access point contracted.
Take part in readiness testing, switch willing counterparties to e-invoicing early, run EDI and Peppol side by side, and keep reading the remaining PDFs.
Gate · must be true to passCounterparty readiness above target, rollback plan for each flow, support model in place by early 2029.
| Activity | Finance director | Financial controller (product owner) | Tax | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Master data team | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and readiness plan | Accountable | Responsible | Consulted | Consulted | Consulted | Informed | Consulted | Informed |
| Scope and VAT treatment decisions | Informed | Consulted | Accountable and Responsible | Consulted | Informed | Informed | Informed | Informed |
| Target architecture | Informed | Consulted | Consulted | Accountable and Responsible | Consulted | Consulted | Consulted | Consulted |
| Access point provider selection | Accountable | Responsible | Consulted | Consulted | Consulted | Informed | Informed | Consulted |
| Master data clean-up and approvals | Informed | Accountable | Consulted | Consulted | Consulted | Responsible | Responsible | Informed |
| ERP mapping and validation | Informed | Consulted | Consulted | Accountable | Consulted | Responsible | Informed | Informed |
| Supplier and customer outreach | Informed | Accountable and Responsible | Consulted | Informed | Responsible | Informed | Consulted | Informed |
| Go-live decision for each flow | Accountable | Responsible | Consulted | Consulted | Responsible | Informed | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the canonical invoice model, how your ERP connects to the access point, the validation service, the agents' permissions, and the plan that gets you from today's PDFs to April 2029. I'd work closely with your financial controller and tax team, and report to your programme board.
Option B
If your partner, your ERP supplier or your own team already has an architect, I'd take on the master data clean-up, the agents and the validation and integration work under their lead, and give them a second senior opinion on the mapping, the controls and the cut-over plan.
Goes wrong
The programme starts in late 2028, and master data that took ten years to get messy has six months to get clean.
How the design avoids it
Start the clean-up and outreach now. It needs no final UK standard, and every corrected record helps today's AP too.
Goes wrong
The AI 'fixes' a supplier's VAT number or bank details in bulk, and payments or invoices go to the wrong place.
How the design avoids it
Proposals only, with evidence. The master data team approves each change, and bank details need a call-back and a second approver.
Goes wrong
A model is used to decide whether an invoice is valid, and it passes one the rules would reject.
How the design avoids it
Validation is a versioned rule service. The model explains failures; it never overrides them.
Goes wrong
The mapping is tested on standard invoices, then credit notes, self-billing and reverse charge fail on day one.
How the design avoids it
A test pack built from twelve months of real invoices, every type and VAT case, signed off by tax.
Goes wrong
A supplier email saying 'please update our details for e-invoicing' is used to change bank details.
How the design avoids it
E-invoicing outreach never collects bank details. Any change request goes through the normal procedure, whatever the channel.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Respond if the standards affect you. Keep validation as a versioned rule service, so the UK rules can be added without rework.
Collect VAT and company numbers now, and add the chosen identifier to every record once it's confirmed. Plan for EDI customers to need Peppol as well.
Contract your access point provider well before testing starts, and move willing counterparties early so the switch is gradual.
Don't build for reporting yet, but keep every e-invoice as structured data with its validation result, so a reporting feed could be added later.
If you have EU entities, check their local deadlines now. One canonical model can serve UK, EU and EDI formats.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
