Free demo
Industry guide
E-invoicing is planned for VAT invoices from April 2029: which of your systems will issue them?
Download the retail and wholesale guide (PDF, 13 pages)Working demo
One delivery record shared across office, driver and customer views.
Open the Route Control demoSuppliers and regulators set most integration deadlines.
What we do
Make the decisions that are currently made by default.
When two systems disagree about a customer and nobody can say which one is right, or an integration breaks because a supplier changed its interface, those decisions were made by default. Each system you add can bring another sign-in, another copy of the same records and another connection to maintain, and if the reasons behind earlier choices were never written down, they leave with the people who made them.
We map the systems you run and the data that moves between them, set out the options for each open decision with its trade-offs, and record each significant choice in an architecture decision record your team keeps. We also build software, including the integrations this work plans.
The plan says where a recommendation could lead to work for us, and the recommendation may be to buy a product, configure one you already pay for, or change nothing.
What you get from an architecture review
An architecture review runs all six; commission one on its own when a single question is open, such as which system should own customer records. Every diagram, record and table is left in a format your team can edit.
System context and data-flow mapping
Map every system you run, its owner and the data that moves between them, in diagrams your team can keep current. List the spreadsheets, shared inboxes and scheduled exports that carry data between teams as connections in their own right.
- System context and container diagrams, drawn in the C4 model
- Data-flow diagrams showing where personal data is stored and sent
- An integration catalogue: each connection, its method (API, webhook, file transfer or re-keying), its schedule and who is alerted when it fails
- A system register with owner, supplier, contract end date and support status
Architecture decision records
Record each significant choice, the options rejected and what would make you revisit it, in a short architecture decision record kept beside the code or in your policy library. Write the first records with the people who made the decisions, so your team can carry on the practice.
- A template following the government's Architectural Decision Record Framework (DSIT and GDS, November 2025)
- Two added fields: options considered and revisit when
- The first records, written with you
- A decision log indexed by system, with superseded records kept
- A rule for which decisions need a record
Target architecture and transition plan
Set out where your systems should be in two to three years and the order of change that gets them there. Replace one part at a time, with the old part left running until its replacement is ready and a decision point before each step.
- Current and target diagrams, side by side
- Incremental replacement in the strangler fig pattern, in place of a single cut-over
- A technical-debt register, ranked by risk and cost
- An exit plan for each supplier: data export format, contract notice period and end date
- For public bodies, a check against the 13 points of the Technology Code of Practice
Source-of-truth and integration planning
Decide which system owns customers, jobs, products and money, and how each connection will be built, monitored and owned. Set the rule that applies when two systems disagree.
- A data ownership table: each record type, its owning system and who may change it
- Reconciliation rules for when two systems hold different values
- The pattern for each connection: API, webhook, scheduled file or a shared integration layer
- Failure handling for each connection: retries, alerts and a named owner
- Which system will issue structured e-invoices under the mandate planned for VAT invoices from April 2029
Identity and access architecture
Plan one sign-in across your systems, a role model, and a joiners, movers and leavers process before the number of systems grows. Decide what each system must log, so access can be checked later.
- Single sign-on through your identity provider, using SAML 2.0 or OpenID Connect
- Account provisioning with SCIM where a system supports it
- A role model mapping each job role to access in each system
- Admin accounts separated from day-to-day accounts
- Audit logging each system must keep, set against the NCSC's zero trust design principles
Resilience and hosting requirements
Set the availability, recovery point and recovery time each system needs, then check each design and supplier against them. Record where each system stores and processes its data, for the person who answers for data protection.
- A table of every system against its availability, recovery point objective (RPO) and recovery time objective (RTO)
- Backup coverage and a restore test plan for each system that holds data you cannot recreate
- Hosting location, with UK-region options where residency matters
- Supplier checks against the NCSC's 14 Cloud Security Principles
- Monitoring requirements: what is watched, and who is told when it fails
What you get
What the maps and records decide
- Customers, jobs, products and money each have one owning system, and a rule says what happens when two systems disagree.
- Your team can look up why each significant choice was made, which options were rejected and what would make you revisit it.
- Plan change one part at a time, with the old part left running beside the new until you decide to switch.
A sample
A sample architecture decision record
One record, on sample data, in the fields we use. A fictional wholesaler decides which of its systems issues VAT invoices.
Sample, on sample data
- Title
- ADR-012: The finance system issues every VAT invoice.
- Date and status
- Accepted on 14 September 2026. Supersedes ADR-004, which let the order system print trade-counter invoices.
- Context
- Invoices come from two systems: the order system prints them at the trade counter and the finance system raises them for account customers. Credit notes total differently in each, and finance re-keys trade-counter invoices every week. The government plans to mandate e-invoicing for all VAT invoices from April 2029 and has named Peppol as the core interoperability network. No legislation or technical specification has been published.
- Options considered
- 1. Keep both and reconcile each week. 2. Make the order system authoritative and copy each invoice to finance through its API. 3. Make the finance system authoritative, with the order system sending each completed order to it.
- Decision
- Option 3. Only the finance system issues VAT invoices and credit notes. The order system posts each completed order to the finance system's API and stores the invoice number it receives.
- Consequences
- Trade-counter invoices now depend on the finance system being available. During an outage, orders queue and retry, and the counter issues a receipt until the invoice number returns. When the specification is published, one system needs a structured e-invoicing route, not two.
- Stakeholders consulted
- Finance manager, trade-counter supervisor, warehouse lead and the order system's supplier.
- Revisit when
- HMRC publishes the e-invoicing technical specification, which it has committed to do by the end of 2027 to 2028, or either supplier announces an end-of-support date.
- Links to supporting documents
- System context diagram, version 3. Integration catalogue entry INT-07. HMRC, Tax update 2026: simplification, modernisation and fairness, 23 June 2026. HMRC, Transformation Roadmap: progress update 2026, 2 July 2026.
Sample data: the organisation, systems and people are fictional. The fields follow the government's Architectural Decision Record Framework (DSIT and GDS, 4 November 2025), with two added: options considered and revisit when. The e-invoicing facts are public, taken from HMRC and current at September 2026; no legislation has yet been published for the mandate.
How it runs
What happens in an architecture review
- 01
Scope and inventory
List every system, supplier contract and connection in scope, including the spreadsheets and exports that carry data between teams.
- 02
Walk-throughs
Sit with the people who run each system and follow a customer, a job and an invoice from start to finish, marking where data is re-keyed or waits.
- 03
Options and decisions
Set out the options for each open question with cost, risk and exit route, then record each choice in an architecture decision record.
- 04
Plan and handover
Sequence the changes into a transition plan, walk your team through it, and hand over every diagram and record in a form you can edit.
Read and try
Read the research. Open the demo.
Industry guide
Retail and wholesale: a practical technology guide
The government plans to mandate e-invoicing for all VAT invoices from April 2029, which are typically issued on sales to businesses and public bodies, and has named Peppol as the core interoperability network. No legislation or technical specification has been published. The guide asks the architecture question underneath: which system is authoritative for what an invoice says, and can it produce a structured one?
Download the retail and wholesale guide
Working demo, on sample data
- One delivery record shared by the Office, Driver and Customer views: capture a delivery in the Driver view and follow its status in the other two.
- A route comparison that shows its constraints: time windows, vehicle capacity, load compatibility and a break policy.
- Its limits stated on the page: fictional depots and stops on a Birmingham street map, straight-line distances and no live tracking.
Worth asking first
- If two systems disagree about a customer record today, which one wins?
- Which supplier could change its product next year and break a process you depend on?
- If your finance system were unavailable this morning, how much data could you lose, and how long could you wait?
- Could you list every system, the data it holds and who can reach it? The first of the NCSC's zero trust design principles is to know your architecture, including users, devices, services and data.
- Who could explain, in two years' time, why your systems connect the way they do?
Talk to us if
- You are about to buy, renew or replace a system whose required connections have never been listed.
- Staff re-key the same customers, orders or jobs from one system into another.
- The person who set up your integrations has left, or is about to.
- Staff sign in to each system separately, and leavers are removed from each one by hand.
- You issue VAT invoices and cannot yet say which system will send structured e-invoices.
- Your board has asked where your data is held and how long you could run without each system.
Questions
Questions buyers ask
Would you build the integrations this plan specifies?
We can, and the plan says so wherever a recommendation could lead to work for us. We build software, including integrations. The plan also sets out the other routes: configuring a product you already pay for, buying one, or leaving a system as it is. The diagrams and records are yours to take to any supplier.
Is an architecture review an audit or a security test?
No. It is a design review. We do not certify designs, audit against ISO 27001 or run penetration tests. Where a design needs one of those, the plan says so, and our Cyber security page points to the public registers of testing providers. Decisions under UK GDPR and your sector's rules stay with you and your advisers.
Do we have to use a particular cloud or product?
No. We plan against open standards, including OAuth 2.0, OpenID Connect, SAML 2.0 and SCIM, and connect systems through their published APIs and webhooks. Where a decision depends on one product, the decision record names it, the options rejected and what leaving it would involve.
Who keeps the diagrams and records up to date?
Your team. We write them in formats that can be edited and versioned beside your code or in your document library, and we write the first records with the people who will maintain them.
Is this only for organisations with many systems?
No. The same records apply to five systems as to fifty: an owner for each record, a map of each connection and a written reason for each choice. The size of the review follows the number of systems and connections in scope.
Your team can look up why, a year from now.
We map the systems you run today, record each decision still open and set the order of change, in diagrams and records your team keeps.
Request an architecture review