HMRC Wants an Unalterable POS Trail. ERP Corrections Need One Too

An encrypted till trail can make later tampering visible. It cannot make a refund settle, put stock in the right place, or post the right credit automatically. The defensible unit is the whole correction trail.

Category: Retail, POS & ERP Operations

What changed

HM Revenue & Customs published a consultation on proposed software standards for Electronic Point of Sale and Mobile Point of Sale systems on June 23, 2026. Responses are due by August 18. The closing window gives affected operators and suppliers a reason to test the proposal against how their systems actually work.

The proposal is not an adopted standard or a current software-compliance duty. HMRC is asking for views on a package that could include:

• storing UK EPOS and MPOS sales records in the Standard Audit File for Tax, or SAF-T, format;
• retaining a complete encrypted audit trail for every individual sale, regardless of payment method;
• digitally signing and linking receipts into an indelible transaction chain;
• registration or certification approaches for systems, suppliers, or users; and
• specified receipt and report data that could support faster integrity checks.

HMRC has not decided the implementation process or timetable. Its consultation says measures would likely arrive over time and should ideally be delivered through updates to existing systems. One of the most important questions is still open: should a transaction be protected when it is created, so aborted, cancelled, and voided activity is captured, or only when it is completed?

A separate Odoo change merged on August 12 provides an operational counterpoint. For scheduled POS orders, its updated refund-picking flow distinguishes stock already delivered from stock not yet delivered. A delivered order produces a return picking; an undelivered full refund cancels the original picking; an undelivered partial refund reduces the relevant moves. That change is not evidence of HMRC compliance. It shows why a till correction can require a different warehouse event.

Why operational leaders should care

An unalterable transaction log can show that a record was not rewritten after the fact. It cannot, by itself, show that the product tax treatment was correct, the refund reached the customer, the reserved stock was released, the returned unit was inspected, the credit note posted, or the management report used the same definition of net sales.

That distinction matters in an omnichannel operation. A store sale may share product and customer records with e-commerce, reserve inventory in an ERP, settle through a payment provider, post to finance, and appear in analytics and support. A correction changes different parts of that chain depending on timing and physical reality.

The implementation question is therefore larger than “does the POS keep encrypted receipts?” It is: can the business preserve the original sale, add a linked correction, and explain every downstream state without rebuilding the story from email, spreadsheets, and connector logs?

The correction-to-close evidence map

The following is AorBorC's suggested operating model, not a final HMRC field list or a statement of legal sufficiency.

• Original sale: Preserve stable transaction, store, device or session, line, product, price, discount, tax, tender, and time references. Reconcile: Does the original event remain visible after a correction?
• Correction: Add a new event ID, correction type, reason, actor, approval where required, original-sale link, and initiated or completed state. Reconcile: Was the change appended and linked rather than used to rewrite history?
• Receipt: Retain original and correction receipt references, issue status, and the relationship between them. Reconcile: Can a reviewer trace what the customer was shown?
• Payment: Retain the tender, authorisation or refund reference, amount, settlement state, failure, and retry. Reconcile: Did the money movement complete, not merely start?
• Inventory and warehouse: Record delivery state, reservation, picking, return receipt, inspection, quarantine, restock, or write-off. Reconcile: Did the stock event match what physically happened?
• Finance and tax: Link the invoice or sales entry, credit note, tax treatment, journal posting, period, and reconciliation state. Reconcile: Did the correction reach the ledger in the right period and form?
• Integration: Link the source event ID, destination ID, idempotency key, sync state, retry, and exception owner. Reconcile: Could a retry create a duplicate or leave one system behind?
• Reporting and support: Define net-sales and return measures, freshness time, exception queue, case reference, and evidence export. Reconcile: Can teams explain the same correction from one retained trail?

The identifiers need durable relationships, not one crowded screen. A useful evidence pack can start from the sale or correction and retrieve the connected receipt, payment, stock, finance, integration, reporting, and support states.

A ten-step implementation checklist

1. Map the real system boundary. List every store, legal entity, POS, e-commerce channel, payment provider, ERP company, warehouse, finance ledger, reporting tool, and support queue that can touch a sale or correction.
2. Name every correction event. Define void, cancellation, refund, partial refund, exchange, return, price override, discount override, no-sale, aborted sale, and post-order edit. Do not let teams use the same status for different physical or financial outcomes.
3. Preserve the original. Make corrections append-only business events with their own IDs and direct links to the source transaction and lines. Restrict destructive edits and retain actor, time, reason, and approval evidence.
4. Decide when protection begins. Model both transaction-creation and transaction-completion approaches while HMRC's question remains open. Confirm how offline sales, abandoned baskets, training mode, reversals, and failed payments would be represented.
5. Reconcile payment completion. Distinguish a refund request from gateway acceptance and settlement. Add retry-safe identifiers, expose failures, and assign an owner for money that has not reached the customer.
6. Branch stock by delivery reality. Before delivery, cancel or reduce the planned movement as appropriate. After delivery, create a controlled return path with receipt, inspection, disposition, and restock or write-off decisions.
7. Connect tax and finance. Define when the credit note or reversing entry is created, which tax treatment applies, how closed periods are handled, and what report proves the POS total agrees with the ledger.
8. Harden integrations. Pass stable source IDs and idempotency keys through every connector. Test delayed, duplicated, reordered, rejected, and manually replayed events instead of testing only the clean path.
9. Test permissions and evidence retrieval. Verify who can correct, approve, configure, export, and administer. Run automated regression tests plus human review for one sale, one void, one partial refund, one delivered return, and one failed connector retry.
10. Run a correction-to-close drill. Select a recent correction and retrieve the original sale, linked event, receipts, settlement, stock action, finance posting, integration history, report outcome, and exception ownership. Record gaps and retest after remediation.

Risks, limits, and where the hype is not useful

• This is an open consultation closing August 18, 2026. The final policy, technical scope, dates, transition treatment, and responsible parties may change.
• HMRC has proposed SAF-T storage for EPOS and MPOS records, but it has not published a final UK POS profile in this consultation. Do not build around assumed final fields.
• The consultation asks when a chain should start; it does not settle the treatment of every aborted, cancelled, or voided transaction.
• Encryption and transaction chaining protect continuity. They do not prove that product, price, tax, tender, customer, or reason data was correct when recorded.
• A POS refund record does not prove that payment settled, stock moved correctly, a credit note posted, or analytics stopped counting the original sale.
• Odoo's August 12 change concerns its scheduled POS order picking flow. Check the exact version, deployment, custom modules, connectors, and regression behaviour before relying on it.
• No POS, Odoo, Zoho, Shopify, AI tool, or custom application should be described as automatically meeting a future HMRC standard. Qualified tax, legal, accounting, security, and operational review still matters.
• A “blockchain” label does not repair a broken order-to-cash process. The useful outcome is evidence people can retrieve and reconcile, not a fashionable architecture word.
• This article is operational guidance, not legal, tax, accounting, or security advice.

The AorBorC view

The right control is simple to state: never replace a business event when the truth is that something else happened next. Keep the original sale, add a linked correction, and make every connected system declare whether it completed, failed, or needs review.

AorBorC's Odoo implementation work connects POS, sales, inventory, warehouse, returns, finance, integrations, and reporting around that event trail. For existing builds, rescue work starts by reproducing the correction and locating the first state that no longer agrees with the others.

Our Zoho QEngine implementation work turns the evidence map into regression coverage for permissions, calculations, retries, stock branches, and downstream postings. AI can help classify exception notes or assemble an evidence pack, but AorBorC keeps consequential approvals and ambiguous exceptions human-reviewed.

The AorBorC company profile explains the founder-led delivery model behind that approach: practical systems, direct technical accountability, and long-lived operational handover rather than an unsupported compliance badge.

Business takeaway

A tamper-resistant till log is necessary evidence, not an end-to-end control. A correction is defensible only when the receipt, payment, stock, tax, ledger, integration, and report still reconcile.

Your next move

Pick one void, one undelivered refund, and one delivered return. Trace each from the original sale to cash, stock, finance, and reporting, then list every manual reconstruction step. If the trail breaks or depends on one person's memory, plan a correction-to-close systems review before adding more automation.