The UK and upcoming fiscalisation - Darko Pavic - Global Retail & Fiscalization Expert

Mandatory POS software standards are now government policy. The technical design remains open.

The United Kingdom has taken an important step toward fiscalization. On 28 October 2026, the government confirmed in its Budget that it will introduce mandatory software standards for electronic and mobile point-of-sale systems. For retailers and POS vendors, this is a significant change in direction. For now, however, it is a policy decision rather than a set of technical rules that software developers can implement. ^{[1, 2]}

HM Revenue & Customs (HMRC) will work with the industry and publish a further technical consultation in summer 2027. The legislation is intended for a future Finance Bill, and the government has not yet set an implementation date. That distinction matters. The UK has decided what it wants to achieve, but it has not yet decided exactly how every POS system must achieve it. ^{[2, 3]}

Why the UK is changing direction

For many years, the UK approached electronic sales suppression largely as a matter of enforcement. Electronic sales suppression, often called till fraud, occurs when transactions are hidden, deleted or altered so that a business reports less revenue and pays less tax. Schedule 14 of the Finance Act 2022 introduced penalties relating to the making, supplying, promotion and possession of tools designed for this purpose. ^[5]

The new approach moves part of the responsibility earlier in the process. Rather than relying only on detecting misconduct after it occurs, HMRC wants the software itself to protect sales records against manipulation. The objective is familiar to anyone working with fiscalization systems in Germany, Austria, Poland or other regulated markets. The details, however, may be quite different from those countries. ^{[3, 4]}

HMRC’s June 2026 consultation attracted 17 written responses and contributions from four additional stakeholders at roundtables. Of the 21 responses assessed, 18 supported software standards, although 13 of those expressed reservations. Only one response opposed the proposal. This was support for the principle of protecting transaction records, not a blank cheque for any implementation model. ^[3]

Fiscalization is the direction, but the model is open

The June consultation put several technical possibilities on the table. They included complete and tamper-evident transaction logs, transaction chaining, standardised audit data, certification or registration of POS systems, receipt information that could be verified, and faster checks by HMRC. It also considered obligations on software suppliers to maintain the integrity of their products. ^[4]

It would be a mistake to report every one of these ideas as an adopted requirement. The 28 October response confirms the government’s intention to introduce mandatory standards. It does not select a final cryptographic mechanism, mandate SAF-T as a native storage format, establish a certification scheme, impose QR codes on all receipts or require real-time transmission of every sale to HMRC. Those choices remain subject to technical work. ^{[2, 3]}

There is another distinction worth making. Mandatory standards for EPOS and MPOS systems do not automatically mean that every business must purchase a cash register. The consultation separately asked whether compliant electronic systems should become compulsory in certain higher-risk sectors. HMRC has not yet settled that question. ^{[3, 4]}

The most important technical question may be when a sale begins

A fiscal record has little value if the system protects it too late. Imagine a checkout application in which an item is scanned, a sale is prepared, then the transaction is cancelled before payment. Should the protected audit trail include that event? What about a refund, a void, a transfer between terminals or a partially completed transaction? These are normal retail processes, but they can also be used to conceal sales if the audit trail is incomplete.

The consultation responses showed a real difference of opinion. Most respondents favoured protecting records when a transaction is created, because that can preserve evidence of later amendments and cancellations. A minority preferred protection from completion, with separate audit controls for earlier events. HMRC has not chosen the final rule. For POS developers, the definition of a transaction event will be one of the most consequential parts of the future specification. ^[3]

The same responses made a useful technical correction. Encryption primarily protects confidentiality. It does not, by itself, demonstrate that a recorded transaction has not been changed. Respondents discussed hashes, digital signatures and transaction chains as possible ways to provide tamper evidence. Some specifically cautioned against calling every chained record a blockchain, because that term could imply a much more complicated technology than the problem requires. ^[3]

SAF-T, certification and receipts are still being designed

Standardised data is another likely element, but the format is not final. Several respondents supported the Standard Audit File for Tax (SAF-T) as an export format. They argued that systems should be able to produce consistent data for audit without necessarily storing every transaction internally in SAF-T. For a modern cloud POS architecture, the difference is substantial. An export requirement can be implemented at a defined interface; a mandated internal data model can force changes across an entire product. ^[3]

Certification is similarly unresolved. Some respondents favoured manufacturer self-certification or supplier declarations, provided HMRC could verify the supporting evidence. Others preferred independent assessment, potentially focused on a security component rather than the complete POS application. The question is closely connected to software updates. Requiring full recertification after every release could be expensive for vendors that continuously improve their products. ^[3]

HMRC also needs to distinguish a register of compliant software products from a register of every installed POS system. Those are different operational models with very different consequences for resellers, retailers and multi-site operators. The consultation outcome leaves both the assurance method and registration responsibilities open. ^[3]

Receipts are another area where the industry asked for practical rules. Many respondents opposed automatic issuance of paper receipts for every transaction, citing cost, waste and checkout speed. They distinguished between securely creating a receipt record, making a receipt available, and requiring that a customer receive one. QR codes and verifiable receipt references remain possibilities, but there is no confirmed general mandate yet. ^[3]

Cloud and Android make this more complicated

A POS transaction no longer necessarily lives on a single cash register. It may begin on a mobile device, continue at a different checkout and be stored in a cloud service. A store may also need to operate without connectivity. The HMRC response explicitly recognises cloud, mobile, hybrid and offline architectures, as well as transactions that move between terminals. [3]

That is an encouraging signal for technology providers. A regulation that assumes every sale is processed and secured on one physical machine risks becoming outdated before it is introduced. The UK has an opportunity to specify verifiable results while leaving room for different implementations. It should be possible to demonstrate the integrity of a transaction without forcing every retailer to adopt the same POS architecture.

One problem no digital signature can solve

The consultation outcome contains a particularly important observation: protecting transactions that have entered a system cannot prove that every sale was entered in the first place. A perfectly valid cryptographic chain may still omit an entirely unrecorded cash sale. The distinction between the integrity of recorded data and the completeness of the business activity being recorded is fundamental. ^[3]

I find this point especially important in the wider discussion about compliance intelligence. A technical check can confirm that a record has not been altered. It cannot automatically confirm that all legally relevant events were captured. Trustworthy compliance therefore requires both reliable technical evidence and a clear understanding of which events the law expects the system to preserve.

The industry’s voice is part of the process

One detail in the published outcome is particularly relevant to us at Fiscal Solutions. HMRC explicitly lists Fiscal Solutions d.o.o. Novi Sad among the consultation respondents, alongside companies and organisations including Block, Stripe, Fiskaly, Swissbit, UKHospitality and POS software providers. Our company has spent more than two decades working with different fiscalization models, and I welcome the fact that the UK is examining international experience before fixing its technical design. ^[3]

The responses did not favour copying one foreign regime in full. They pointed to useful elements in Germany and Austria, especially separation of security functions and machine-readable verification, while also highlighting lessons from France, Spain and Norway. That seems sensible. The UK retail market has its own business models, and any effective system has to work in the real world of refunds, high-volume checkout, software updates and distributed retail systems. ^[3]

What retailers and POS vendors should do now

There is no confirmed UK compliance deadline and no final technical specification to build against today. Retailers should therefore avoid treating the Budget announcement as a requirement for an immediate hardware replacement programme. POS vendors should not assume that any proposed format, receipt layout or certification model is already fixed. ^{[2, 3]}

But doing nothing would also be a mistake. Software providers can already review how their applications record cancellations, refunds and other events, whether their audit trails reveal later changes, how they export transaction data and how security works during network interruptions. These are sound architectural questions regardless of the final UK model. Multinational retailers can also assess which elements of their existing fiscalization infrastructure might be reusable.

The decisive milestone will be HMRC’s technical consultation in summer 2027. It should tell the industry much more about the scope of the standards, the required evidence, the assurance model and the treatment of existing systems. Only after those choices are made will meaningful implementation budgets and dates be possible. ^{[2, 3]}

For me, the biggest news is the policy direction. The UK has decided that reliable POS records should become a responsibility of the software design itself. After years of watching fiscalization evolve across Europe, I see that as a significant step. The important engineering work is still ahead.