UK EPOS Software Standards 2026: What HMRC Is Proposing for POS Systems

HMRC is considering a significant change to how Electronic Point of Sale (EPOS) and Mobile Point of Sale (MPOS) systems operate in the UK, but the proposed software standards are not yet mandatory.

A consultation published on 23 June 2026 proposes measures including standardised sales records using the OECD Standard Audit File for Tax (SAF-T), complete encrypted transaction histories, tamper-evident transaction chaining, registration or certification of POS systems, mandatory receipt information, and stronger responsibilities for POS suppliers. The consultation closes on 18 August 2026.

For retailers, restaurants, takeaways and POS developers, the sensible response is neither to ignore the proposal nor to rebuild software around rules that have not been finalised.

The better approach is to identify which architectural changes are valuable regardless of the final policy, and which decisions should wait for technical standards and legislation.

Are new UK EPOS software standards already mandatory?

No.

HMRC's current consultation says there are no mandatory EPOS or MPOS software standards in the UK at present. The government is consulting on whether and how mandatory standards should be introduced.

The consultation runs from 23 June to 18 August 2026. HMRC states that responses will inform future policy proposals and that any further steps will be announced through the normal tax policy-making process.

HMRC also says the process and timeline for implementation have not yet been decided.

That distinction matters.

A business should not interpret a consultation as:

"Our till system becomes illegal on 18 August."

It does not.

Nor should a POS developer market a product as "HMRC compliant with the new 2026 EPOS standard" when a final standard does not yet exist.

The accurate position is:

Current UK position
        ↓
No mandatory EPOS/MPOS software standard
        ↓
HMRC consultation
23 June – 18 August 2026
        ↓
Responses assessed
        ↓
Possible future policy / technical consultation
        ↓
Potential legislation and implementation

The direction is meaningful. The final specification is not settled.

Why is HMRC looking at POS software?

The consultation targets Electronic Sales Suppression (ESS), sometimes described as till fraud.

ESS occurs when digital sales records are manipulated to hide or reduce reported transactions, lowering reported turnover or tax liabilities.

HMRC says operational experience has identified risks involving deliberately modified POS systems and the misuse of legitimate functionality. The consultation highlights small retail, takeaway and hospitality businesses as areas where the risk has been observed.

The UK already has legislation specifically addressing ESS tools. HMRC's consultation notes that Finance Act 2022 Schedule 14 introduced offences relating to possessing, making, supplying or promoting ESS tools.

The new proposal moves further upstream.

Instead of relying only on investigations after suspicious records exist, the government is considering whether POS software itself should be required to preserve a trustworthy audit trail by design.

That changes the engineering question from:

"Can the database store a sale?"

to:

"Can the system prove what happened to that sale afterwards?"

For modern POS architecture, that is a much more useful question anyway.

What is HMRC proposing?

The consultation describes a package of potential measures rather than one isolated rule.

These are proposals. Several details remain open questions in the consultation.

That is why engineering teams should prepare for capabilities, not pretend they already know the final compliance specification.

What is SAF-T, and why does it matter for POS software?

SAF-T stands for Standard Audit File for Tax.

It is an OECD-originated data standard designed to make tax-relevant accounting records easier to exchange and analyse electronically.

HMRC proposes that UK EPOS and MPOS systems could be required to store sales records using SAF-T.

The important architectural implication is not "replace your database with an XML file."

A sensible POS application can keep its operational data model while providing a controlled standards layer:

Operational POS database
        ↓
Canonical transaction model
        ↓
Validation / transformation
        ↓
SAF-T-compatible export

That separation matters because a restaurant POS, retail POS and mobile checkout application may each have different internal concepts.

For example:

Restaurant
- table
- cover
- course
- modifier
- service charge
- void reason

Retail
- SKU
- barcode
- quantity
- promotion
- return
- exchange

A tax/audit format should not dictate the entire operational model.

Instead, the application should be able to map operational events into a reliable reporting representation.

The OECD's 2024 Consumption Tax Trends report notes that SAF-T, or national variations of it, is already used by several OECD countries for standardised tax-data exchange.

The biggest architectural change is not SAF-T. It is the audit trail.

A traditional CRUD application often stores the current state:

Sale #4817
total = £42.50
status = completed

If someone later changes the sale:

Sale #4817
total = £32.50
status = completed

the database may simply overwrite the original values unless history was designed separately.

That is convenient for application development.

It is weak for auditability.

HMRC's proposal focuses on a complete record of transactions and adjustments, including an audit trail protected against later tampering.

A stronger POS model treats important changes as events:

10:42:11  SALE_CREATED       £42.50
10:42:13  PAYMENT_CAPTURED   £42.50
10:44:08  ITEM_VOIDED       -£10.00
10:44:08  VOID_REASON        "Customer changed order"
10:44:09  MANAGER_APPROVED
10:44:12  RECEIPT_REISSUED   £32.50

The business can still display:

Current total: £32.50

But it can also explain exactly how £42.50 became £32.50.

That is useful for tax audit, fraud investigation, refund disputes, staff accountability, stock reconciliation, cash variance, manager approvals, customer complaints and operational analytics.

So even if the exact HMRC proposal changes, better auditability is not wasted engineering.

Should transactions become immutable?

Important financial records should generally become append-oriented rather than silently editable.

That does not mean a cashier can never correct a mistake.

It means the correction should become another recorded action.

Bad pattern:

UPDATE sale
SET total = 32.50
WHERE id = 4817;

Better conceptual pattern:

Original sale
      ↓
Adjustment event
      ↓
Reason
      ↓
Authorised user
      ↓
Timestamp
      ↓
Resulting state

A practical database may still maintain current-state tables for speed, alongside an append-oriented __INLINE_CODE_0__ or __INLINE_CODE_1__ layer.

The current state serves the live application.

The event/audit layer preserves the history.

What does "transaction chaining" mean?

The consultation discusses cryptographically linking transaction records so that changes to earlier entries become detectable.

Conceptually:

Transaction A
hash = H(A)

Transaction B
previous_hash = H(A)
hash = H(B + previous_hash)

Transaction C
previous_hash = H(B + previous_hash)
hash = H(C + previous_hash)

If someone secretly modifies Transaction A later, the chain no longer validates.

This is often described as a tamper-evident chain.

HMRC's consultation refers to digitally signed/encrypted receipt data linked to previous transactions and discusses a closed-system form of transaction blockchain.

There is an important engineering distinction:

Tamper-evident does not automatically mean blockchain infrastructure, cryptocurrency or a distributed ledger.

A conventional database can implement cryptographic chaining.

POS providers should therefore avoid architecture theatre. If a future standard defines a particular signature, hashing, key-management or chaining method, implement that requirement. Until then, preserve the ability to add such a mechanism cleanly.

What should POS developers prepare now?

Several improvements are defensible even before a final HMRC standard exists.

1. Give every financial event a stable identifier

Use unique identifiers for transactions, payments, refunds, voids, adjustments, receipts, shifts, terminals, branches and users.

2. Stop destructive edits to completed sales

A completed transaction should not casually become an editable document.

Use:

sale
+
adjustment
+
reason
+
authorisation

rather than silently replacing the original record.

3. Record who performed important actions

For high-impact events, preserve user, role, device/terminal, branch, timestamp, reason and approval where needed.

Example:

{
  "event": "ITEM_VOIDED",
  "transactionId": "txn_4817",
  "itemId": "item_03",
  "performedBy": "user_118",
  "approvedBy": "manager_22",
  "terminalId": "till_04",
  "reasonCode": "CUSTOMER_CHANGED_ORDER",
  "occurredAt": "2026-08-13T18:42:11Z"
}

4. Keep raw financial events separate from editable notes

A manager may need to edit an internal note, customer name or booking reference.

That should not grant permission to rewrite the original payment amount, VAT calculation, item sale or void history.

5. Create an export layer

Do not hard-code tax reporting deeply into checkout logic.

Prefer:

POS domain model
      ↓
Reporting adapter
      ↓
Versioned export format

If the eventual UK requirement uses a defined SAF-T profile, the adapter can change without rebuilding the checkout domain.

6. Version your receipt schema

If mandatory receipt fields arrive later, a receipt should be reproducible according to the rules that applied when it was generated.

Store structured receipt data, not only a rendered PDF or thermal print string.

7. Build migration capability

HMRC says its preferred outcome would ideally allow existing systems to be updated rather than replaced.

That makes backwards-compatible migrations important.

A POS vendor may eventually need to introduce new audit tables, backfill identifiers, add receipt fields, upgrade terminal software, rotate cryptographic keys, migrate historical data or activate a new export schema.

A system with controlled versioning will handle that much better than one whose tills behave as isolated databases.

What should retailers and hospitality businesses do now?

For most businesses, the immediate action is an inventory and vendor conversation, not a replacement project.

Ask:

1. Which POS product and version do we use?
2. Is it actively maintained?
3. Who supplies the software?
4. Can it receive remote/software updates?
5. Can transactions be deleted or overwritten after completion?
6. Does it retain void, refund and adjustment history?
7. Can transaction records be exported in structured form?
8. Do we know which user made each sensitive change?
9. Can receipts be reproduced from structured historical data?
10. Do we have unsupported tills or old local installations?

The riskier scenario is not necessarily "our POS lacks SAF-T today."

The riskier scenario is:

"Our supplier disappeared three years ago and nobody can update the till."

If future certification or data standards arrive, unsupported software will be much harder to adapt.

Should a restaurant replace its POS now?

Not because of this consultation alone.

HMRC explicitly says it would ideally prefer changes to be implemented through updates to existing systems rather than forcing replacement, and it expects measures would likely be introduced over time.

Replacing a working POS purely because of a proposal whose technical requirements are not finalised would be premature.

A replacement may still make sense if the current system already has business problems such as no reliable audit history, no API, no structured export, unsupported operating system, no vendor updates, poor multi-branch controls, weak permissions, unreliable backups or inability to separate refunds, voids and corrections.

Those are independent reasons to modernise.

The consultation can strengthen the business case, but it should not manufacture one.

What should a custom POS architecture look like?

A compliance-ready architecture could separate operational checkout from audit and reporting layers.

Till / mobile checkout
        ↓
Transaction service
        ↓
Validation + pricing rules
        ↓
Authoritative transaction event
        ↓
┌────────────────────┬────────────────────┐
│                    │                    │
Current-state DB     Audit/event log      Receipt service
│                    │                    │
Stock / orders       Tamper evidence      Structured receipt
│                    │                    │
└───────────────┬────┴──────────────┬─────┘
                │                   │
        Reporting adapter      Compliance checks
                │
         SAF-T / future
         HMRC-defined format

The useful property is separation of responsibilities.

The checkout interface should not decide the audit standard.

The audit log should not depend on a printable receipt.

The receipt renderer should not be the only source of tax data.

And a reporting integration should not have permission to rewrite historical transactions.

This is the kind of architecture that can evolve as the final standard becomes clearer.

What not to build yet

Some elements are too unsettled to treat as final requirements.

Do not hard-code a UK-specific SAF-T interpretation yet

HMRC is proposing SAF-T, but a final UK EPOS implementation profile and technical specification have not been published through this consultation.

Prepare a mapping layer. Wait for the final schema before freezing it.

Do not invent an "HMRC certification API"

The consultation considers manufacturer certification, supplier registration and user registration.

The operating model has not been decided.

Do not force a blockchain product into the stack

Prepare for tamper evidence and cryptographic chaining.

Do not assume that means deploying a distributed blockchain network.

Do not make every sale irreversible

A business still needs legitimate corrections, refunds, voids, returns and cancellations.

The goal is that these actions are traceable, not impossible.

Do not claim compliance with a non-final standard

A vendor can truthfully say:

"The platform provides immutable audit events and structured exports designed to support future compliance requirements."

It should not say:

"HMRC 2026 certified"

unless such certification actually exists and has been obtained.

How does this relate to Making Tax Digital?

It is related to the broader direction of digital tax records, but it is a separate proposal.

Making Tax Digital for Income Tax already requires some sole traders and landlords to use compatible software and maintain digital records from 6 April 2026, depending on their circumstances.

HMRC's EPOS consultation specifically targets Electronic Sales Suppression and the integrity of POS transaction records.

A business should therefore avoid collapsing different requirements into one vague concept of "HMRC compliant software."

Think in layers:

POS transaction integrity
        ↓
Accounting records
        ↓
Tax reporting software
        ↓
HMRC submission obligations

One product may cover several layers, but the rules governing them are not identical.

HMRC is also strengthening expectations for third-party tax software

The EPOS consultation is not happening in isolation.

In March 2026, HMRC published a separate plan to strengthen standards for third-party software that integrates with HMRC.

That plan covers product integrity, supporting correct outcomes, data accountability, error management, and misuse and fraud prevention.

The EPOS proposals are more specific to point-of-sale records and ESS, but together the documents show a direction of travel:

Software involved in financially significant workflows is increasingly expected to provide evidence of integrity, not merely functionality.

That is a useful product-design principle even before any particular standard becomes law.

A practical readiness score

A retailer, restaurant or POS provider can evaluate its current system without pretending to conduct a legal certification.

Give one point for each statement that is true:

This is not an HMRC compliance score.

It is an engineering-readiness check.

A low result tells you that future standards may be harder to adopt because the current system has weak auditability or maintainability.

What happens after the consultation closes?

The consultation closes on 18 August 2026.

HMRC says responses will inform future policy proposals, with future steps announced through the tax policy-making process. It also anticipates continued stakeholder engagement and potentially further technical consultation.

So the sensible monitoring sequence is:

18 August 2026
Consultation closes
        ↓
Government analyses responses
        ↓
Future policy announcement
        ↓
Potential technical specification
        ↓
Potential legislation
        ↓
Implementation / transition period

Do not treat dates after the first box as known until HMRC publishes them.

For POS developers, the next technically important publication may define actual fields, schemas, signing requirements, cryptographic methods, certification processes, retention periods, transition rules and interfaces.

That is the point where architecture preparation becomes specification implementation.

FAQs

Are HMRC EPOS software standards law in the UK in August 2026?

No. HMRC is consulting on introducing mandatory EPOS and MPOS software standards. The consultation states that the UK currently has no mandatory EPOS/MPOS software standards and that future policy will depend on the consultation process.

When does the HMRC EPOS consultation close?

The consultation closes on 18 August 2026. It opened on 23 June 2026.

Will UK POS systems have to use SAF-T?

HMRC is proposing that EPOS and MPOS systems store sales records using the OECD SAF-T format, but this is not yet a final mandatory technical requirement.

Will restaurants have to replace their current tills?

Not necessarily. HMRC says the preferred approach would ideally allow existing systems to be updated rather than replaced and that measures would likely be phased in. The final implementation process has not yet been decided.

Is HMRC proposing blockchain for tills?

The consultation discusses cryptographically chaining receipt/transaction data and describes this as a form of closed-system transaction blockchain. That does not necessarily imply a public or distributed blockchain platform. The eventual technical requirements have not been finalised.

What is the best thing a POS developer can do now?

Improve capabilities that remain useful regardless of the final specification: append-oriented audit history, traceable adjustments, structured exports, stable identifiers, access controls, maintained migrations and separation between operational and reporting layers. Avoid hard-coding unfinalised compliance details.

Conclusion

HMRC's 2026 EPOS consultation matters because it signals a possible change in what the UK expects from point-of-sale software.

But the useful response is precision, not panic.

Today: there is no new mandatory UK EPOS/MPOS software standard from this consultation.

Proposed: SAF-T records, complete encrypted audit histories, transaction chaining, registration or certification, receipt requirements and stronger system-integrity controls.

Undecided: the exact technical specification, operating model, legislation, transition process and implementation timeline.

Businesses should therefore audit whether their existing POS can be maintained and upgraded.

Developers should make financial history traceable, keep reporting adaptable and avoid destructive transaction edits.

Then wait for the final technical rules before engraving a consultation document into the architecture.

If your restaurant, retail business or multi-branch operation needs a POS or management platform designed around reliable transaction history, integrations and future change, Softotic's custom software development service can help design the underlying system, while web application development can support the management and reporting layer.

Sources and references

• HMRC: Electronic Sales Suppression — Introduction of software standards in EPOS/MPOS systems
• HMRC: Electronic Sales Suppression software standards consultation
• HMRC: Tax update 2026 — simplification, modernisation and fairness
• OECD: Consumption Tax Trends 2024 — transactional reporting and SAF-T
• HMRC: Plan to strengthen standards for third-party software
• HMRC: Create digital records for Making Tax Digital for Income Tax