ERP and accounting software for UK businesses — Making Tax Digital, VAT and multi-entity accounting

We are not going to invent a deadline

Several of the market pages on this site are organised around a compliance deadline, because in Saudi Arabia, Egypt, Jordan and much of the region there genuinely is one. The United Kingdom is not that market. There is no business-to-business e-invoicing mandate in force here, no clearance platform your invoices must pass through, and no format your customers can insist on because the law says so.

A Peppol-based four-corner model has been planned, with a target around 2029. That is a real direction of travel and it is worth knowing about, but a target several years out is not a reason to buy software this quarter. It is a reason to prefer a system that can produce structured invoice data when the time comes, and to ignore anyone who describes 2029 as though it were next month.

So the honest British argument for changing systems is the ordinary one, and it is a good enough reason on its own: fewer places for the same number to be entered, a month-end that closes without a week of reconciliation, VAT computed once from the transactions rather than assembled in a spreadsheet, and a set of records you can put in front of HMRC without a scramble.

If a vendor tells you that the UK is about to mandate e-invoicing and that their product is the way to comply, ask them to name the legislation and the commencement date. The answer will tell you a great deal about how the rest of their claims should be read.

• No B2B e-invoicing mandate is in force in the United Kingdom
• No clearance step sits between you and HMRC when you raise an invoice
• A Peppol-based model is planned, targeted around 2029
• Making Tax Digital for VAT is the obligation that does apply
• Ask any vendor claiming otherwise to name the legislation

Making Tax Digital is the obligation that actually exists

Making Tax Digital for VAT changed the mechanics of the VAT return. Records that support the return are kept digitally, and the return itself is submitted from compatible software through HMRC's API. The point of the regime is not the submission button; it is that the numbers arrive at HMRC from the records rather than from somebody's memory of the records.

That has a practical consequence for how a finance system is put together. If VAT is computed inside the system from the transactions, then the return, the transaction list behind it and the documents behind those are the same chain. If VAT is exported, adjusted by hand and then re-entered, the chain breaks at the adjustment, and the adjustment is exactly what an enquiry will ask about.

The practical test to apply to any system is simple: can you take a single figure on a submitted VAT return, click through to the transactions that make it up, and from there to the invoice or receipt behind each one, without leaving the system or opening a spreadsheet. If the answer is no, the regime is being satisfied by effort rather than by design.

Whether your business is in scope, from which period, and what your submission obligations are, is a question for HMRC. Thresholds and phasing have changed over the life of the regime and continue to be set by HMRC rather than by anyone selling software. Confirm your position with HMRC or your accountant before you plan around it.

• VAT records held digitally rather than reconstructed at quarter end
• Returns submitted from the software through HMRC's API
• Each return figure traceable to the transactions behind it
• Adjustments recorded as entries with a reason, not silent overwrites
• Supporting documents attached to the transaction, not filed separately

What actually makes UK finance work difficult

Take the mandate question off the table and the real difficulty comes into view, and it is not the VAT rate. It is that a typical UK business of any size runs several sales channels, buys in more than one currency, holds stock in more than one place, employs people on more than one basis, and has to produce one coherent set of numbers from all of it every month.

Each of those is manageable alone. Together, and spread across a till system, an online store, a stock spreadsheet, a payroll bureau and an accounts package that receives a monthly journal from each, they produce the familiar British month-end: a week of reconciliation, a set of numbers that nobody quite trusts until the accountant has been through them, and a management report that arrives too late to change any decision.

The alternative is not a better spreadsheet. It is one place where a sale, the stock it consumed, the VAT it generated and the cash it eventually produced are the same record seen from four directions. That is a structural choice about where data lives, and it is the choice that determines whether the month-end is a review or a rebuild.

None of this is unique to the UK, but the UK has an unusual concentration of small and medium businesses running exactly this patchwork, largely because there was never a mandate forcing the question. The absence of a deadline is precisely why the operational case has to carry the argument here.

• Several sales channels feeding one set of accounts
• Purchases in more than one currency, settled at a different rate
• Stock in more than one place, counted on more than one basis
• Payroll on more than one arrangement, often run outside the ledger
• A month-end that rebuilds the numbers rather than reviewing them

VAT: the rate is easy, the treatment is not

Applying 20% is arithmetic. Deciding whether 20% is the right answer is the work. The treatment of a supply depends on what is being supplied, to whom, where they are, and sometimes on how the transaction is structured, and the rules that govern that are HMRC's rather than a software vendor's.

What a system owes you is that once a treatment has been decided, it is applied consistently and recorded where you can find it. Tax should be determined and stored at line level, not derived at the document total, because the same invoice can legitimately carry more than one treatment. Change a product's treatment and the change should be dated, so that historical invoices continue to show what was actually charged.

Cross-border adds another layer. Sales to and purchases from outside the UK, and movements involving Northern Ireland, do not automatically follow the domestic answer. The system should let you record the treatment you have been advised to apply and report those transactions separately, rather than quietly folding them into a domestic total.

Skyline Nexus stores the tax treatment on the line with the transaction, keeps the rate that applied on the date it applied, and produces the transaction list behind each return figure. It does not decide your VAT liability. Where a treatment is genuinely uncertain, the answer comes from HMRC or your adviser, not from the software.

Peppol and the model planned for around 2029

The direction the UK has signalled is a four-corner model built on Peppol, in which the seller's access point passes a structured invoice to the buyer's access point, rather than every invoice passing through a government platform. It is a different architecture from the clearance systems used elsewhere, and it is worth understanding because it changes what your system needs to be able to do.

In a four-corner model, the burden on the business is to produce a complete and correct structured invoice and to be reachable on the network. There is no waiting for a government system to accept or reject each document before it reaches your customer. That makes the readiness question mostly a data question: do you hold, per invoice, the identifiers, tax detail and totals that a structured format requires.

The sensible thing to do about a target several years away is nothing dramatic. Do not buy for it now; do not choose a system that would make it impossible later. If the system already holds clean customer and item master data, records tax at line level and can export structured documents, the eventual work is an integration project rather than a rebuild.

Timing, scope and whether the target holds are matters for the UK government and HMRC. Treat any specific claim about what will be required and when as something to verify against an official source before you plan a budget around it.

• A four-corner model: seller access point to buyer access point
• No per-invoice government approval step in that design
• Readiness is mostly a data question, not a filing one
• Clean master data and line-level tax are the durable preparation
• Verify any specific claim about timing against an official source

Northern Ireland, in general terms

Since the UK left the European Union, Northern Ireland has occupied a distinct position for the movement of goods, and a transaction that would be straightforward within Great Britain may be treated differently when Northern Ireland is at one end of it. This page will not attempt to state the rule, because the detail is precisely the kind of thing that should be read from the authority rather than from a vendor page.

What it does mean practically is that the location dimension on a transaction matters more here than it does in a single-jurisdiction market. If your system cannot tell you where goods physically moved from and to, independent of where the invoice was addressed, you will not be able to answer the question when it is asked.

The system-level requirement is therefore modest and concrete: hold the ship-from and ship-to locations on the transaction, keep them distinct from the billing address, and make it possible to report on movements by location. The tax conclusion drawn from that data is for HMRC guidance and your adviser to settle.

It is also a reminder that a UK system serving a group with European trade cannot treat the country as a single tax territory with one answer. The dimensions that let you separate movements by origin and destination are the same ones that make intra-EU and third-country reporting possible elsewhere in the group, which is an argument for recording them everywhere rather than only where they are currently needed.

UK GAAP, FRS 102 and what the framework does to your ledger

Reporting framework is the quiet structural difference between the UK and the Gulf markets this site mostly serves. Listed groups here apply international accounting standards as adopted for use in the UK. A large population of private companies prepares accounts under UK GAAP, principally FRS 102, with a reduced regime available to smaller entities.

This matters at the transaction level, not only at the year end. The framework influences how revenue is recognised, how leases and financial instruments are treated, and what has to be disclosed. If those decisions are made only when the accountant arrives, the ledger is a record of cash movements that then has to be reinterpreted; if the chart of accounts reflects the framework, the accounts fall out of the ledger.

For a group with entities in both the UK and the Gulf, the same underlying transactions may have to serve local UK reporting and a different framework on consolidation. That is a real requirement, and it is met by recording enough dimension on each posting to support both views, rather than by keeping two sets of books.

Which framework applies to your entity, and how any specific transaction should be treated under it, is a question for your auditor. A system's job is to hold the detail that lets the answer be applied consistently and evidenced later.

• Listed groups: international standards as adopted for use in the UK
• Many private companies: UK GAAP, principally FRS 102
• A reduced regime is available to smaller entities
• Framework choice affects the chart of accounts, not only disclosure
• Groups spanning frameworks need detail on the posting, not summaries
• Which framework applies to your entity is a question for your auditor

Multi-entity, multi-currency, multi-channel

UK groups tend to become several legal entities well before they become large: a trading company, a property company, a subsidiary set up for a new line, occasionally an overseas entity. Intercompany transactions, elimination on consolidation and a shared chart of accounts stop being advanced requirements and become ordinary ones.

Currency is the other constant. Buying in euros or dollars and selling in sterling means that the rate applied, the date it applied, and the difference realised on settlement all have to be recorded rather than reconstructed. A system that stores only the sterling figure has thrown away the information you need to explain the movement.

Skyline Nexus records each transaction in its original currency with the rate applied, carries entity, branch and location as dimensions on the posting rather than deriving them in a report, and keeps the subledgers reconciled to their control accounts. Consolidation then reads from the same records the statutory accounts do.

• Several legal entities under one group, each with its own statutory accounts
• Intercompany balances that agree in both directions
• Original currency and applied rate stored on every transaction
• Branch, location and department as posting dimensions
• Subledgers that tie to their control accounts without manual adjustment
• One chart of accounts shared across entities, with local additions

What to ask a vendor when there is no deadline to hide behind

In a mandate market, vendor conversations are short: show me the format, show me the acceptance. In the UK there is no such test, which means the questions have to be about the ordinary work of the business. That is harder to demo and more informative.

Ask to see a VAT return produced from live data and then drilled down to source. Ask what happens to a posted invoice when it is corrected, and whether the correction is visible. Ask how a purchase invoice arrives, who approves it and where the evidence of approval is stored. Ask how many people have to touch a sale between the order and the ledger.

Then ask the negative questions, which vendors answer less often. What does this system not do. What do your customers usually keep in a separate tool. What is the part of implementation that goes wrong most often. A vendor who cannot answer those has either not implemented enough sites or is not being straight with you.

Finally, ask about the exit. What does your data look like if you leave, in what format, and how long does it take to get it. A system that makes that awkward has told you something about the relationship it expects to have with you.

• Show a VAT return figure drilled to the underlying invoices
• Show what happens to a posted document when it is corrected
• Show the purchase approval trail, not just the purchase record
• Name what the system does not do
• Describe the export you would get on the way out

A sensible order of work

Without a deadline, the temptation is to do everything at once because nothing forces a sequence. The better order is the one that reduces risk earliest: get the ledger and VAT right first, because that is the part with an authority attached to it, then the operational modules that feed it, then the reporting that depends on both.

Master data comes before all of it. Customers, suppliers, items and the chart of accounts carried over uncleaned will reproduce every existing problem inside a new system, and the effort of cleaning them is roughly the same whenever it happens. Doing it before migration means doing it once.

Run the old and new systems in parallel for at least one full VAT period and one full month-end, and compare the return and the trial balance rather than a sample of documents. Differences found in parallel running are a project task; the same differences found afterwards are an enquiry.

And keep the compliance question where it belongs. A system holds records, produces documents and enforces the rules you configure into it. Whether your treatment of a specific supply is correct, whether you are within scope of a regime, and what you must file and when, are matters to confirm with HMRC or your accountant.

• Clean master data before migrating it, not afterwards
• Ledger and VAT first, because an authority is attached to them
• Operational modules next, reporting last
• Parallel run through one full VAT period and one month-end
• Compare the return and the trial balance, not a sample of documents
• Confirm scope and filing obligations with HMRC or your accountant

Common questions

Is e-invoicing mandatory in the United Kingdom?

No. There is no business-to-business e-invoicing mandate in force in the UK, and no clearance platform your invoices must pass through. A four-corner model based on Peppol has been planned and targeted around 2029, but nothing is in force for ordinary B2B invoicing today. If a vendor tells you otherwise, ask them to name the legislation and its commencement date.

What does Making Tax Digital actually require?

For VAT, businesses in scope keep their VAT records digitally and submit returns to HMRC through compatible software using HMRC's API rather than typing figures into a web form. The point is that the return comes from the records themselves. Whether your business is in scope, and from which period, is a question for HMRC or your accountant.

What is the standard rate of UK VAT?

The standard rate is 20%. Other rates, zero-rating and exemptions apply to particular goods and services, and the correct treatment of a specific supply should be confirmed against HMRC guidance or with your adviser. A system should let you hold that treatment at line level and report on it, not decide it for you.

Does Northern Ireland work the same way as the rest of the UK?

Not entirely. Following the UK's exit from the European Union, Northern Ireland has a distinct position for the movement of goods, so a transaction involving Northern Ireland may not be treated the same as a comparable one within Great Britain. Confirm your own position with HMRC. Practically, your system should record ship-from and ship-to locations separately from the billing address.

Which accounting framework applies to a UK company?

Listed groups apply international accounting standards as adopted for use in the UK, while many other companies prepare accounts under UK GAAP, principally FRS 102, with a reduced regime for smaller entities. Which applies to your entity is a matter for your auditor. It affects the chart of accounts and the disclosures your system needs to be able to produce.

Rates, regimes and deadlines in this summary change, and many countries are actively legislating on e-invoicing. This is general information, not tax or legal advice — confirm the current position with the authority named above or with your tax adviser before you rely on it.