Why NF525 turns a checkout transaction into a verifiable chain of evidence?
A receipt printed at a French checkout may look like an ordinary commercial record, but in an NF525-certified system it is also the visible endpoint of a cryptographic process that links the transaction to an ordered history. The crucial engineering challenge is not merely producing a valid electronic signature; it is ensuring that every terminal, service, archive and verification tool agrees on the precise transaction being signed, the sequence in which it was registered and the evidence that survives years after the sale.
That distinction matters to international retailers whose checkout architecture increasingly spans cloud services, mobile POS, self-checkout, returns desks and offline stores.
France illustrates how a principle-based fiscal law can coexist with an exacting certification specification, and why the choice of a cryptographic algorithm is only a small part of the compliance investment.
French law sets the outcome while NF525 specifies a method
Article 286 I 3° bis of the French General Tax Code requires covered cash-register software to preserve the inalterability, security, retention and archiving of relevant data, commonly abbreviated ISCA. The French tax administration’s BOFiP guidance treats mechanisms such as record chaining and electronic signatures as examples of reliable security techniques, rather than prescribing a single algorithm or byte-level implementation for every software publisher. The NF525 certification scheme, administered by INFOCERT with AFNOR Certification, goes further by testing a defined method of documenting and securing POS activity. [1][2][3]
The legal status of certification deserves particular attention in 2026.
France’s Finance Act for 2026 restored the possibility of a publisher-issued individual attestation, reversing the planned elimination of self-attestation. An NF525 certificate remains a recognized and commercially important way to demonstrate conformity, but it is inaccurate to describe the detailed NF525 signature format as a universal legal obligation for every covered cash-register product. The technical obligations discussed here concern software following the referenced NF525 certification framework. [4][5]
A signature is only as reliable as the data it represents
Under the NF525 v2.3 and R13 v4.2 specifications described in Fiscal Solutions’ technical analysis of 20 October, a finalised sales ticket is secured by an asymmetric signature based on a precisely constructed record. That record captures amounts broken down by VAT rate, the transaction total, registration timestamp, document number, operation type, an indicator of whether a preceding signature is included and the predecessor signature itself. The order, punctuation, numeric conventions and encoding are substantive requirements because even a harmless-looking change to the input produces a different cryptographic result. [6]
Consider a retailer operating tills in several countries. Its generic transaction service may represent a VAT rate as 20.0, while the French fiscal adapter expects a fixed four-digit representation; a payment service may preserve decimal currency units while the certified signing service expects integer cents. Both systems can describe the same economic transaction correctly, yet they may derive incompatible signature inputs. The control that matters is therefore an agreed canonical representation of the transaction, verified from end to end, not merely a shared signature library.
The article identifies RSA with 2048-bit keys using PSS padding and 256-bit ECDSA as minimum acceptable asymmetric approaches under the referenced NF525 version, while identifying obsolete or weaker methods as unsuitable. Those particular thresholds and the signature-extract rules should be checked against the licensed, current certification documents and the product’s applicable category before implementation; the publicly accessible INFOCERT overview explains the certification structure but does not reproduce the full R13 data dictionary. [3][6]
Receipt chains transform isolated sales into a transaction history
The decisive idea is that each signature incorporates evidence from a preceding record. If a historical transaction is altered, the verification of that record fails, while subsequent records reveal the inconsistency through their dependence on the earlier signature. In this way a sequence of individually valid documents becomes a structure that can expose tampering, deletions and unexplained interruptions. The mechanism does not, by itself, prove that a sale was never omitted before registration or that the underlying VAT treatment was correct; those are separate controls requiring reconciliation, event completeness and sound fiscal logic.
| Record | Cryptographic input | Result |
| Sale 001 | Transaction data + chain start | Signature A |
| Sale 002 | Transaction data + Signature A | Signature B |
| Sale 003 | Transaction data + Signature B | Signature C |
Illustrative sequence only. Actual NF525 chains and canonical formats follow the applicable certification specifications.
There is also no single universal chain across every document created by the software. According to the detailed NF525 account, tickets and provisional restaurant notes, payment receipts, duplicates, periodic cumulative totals, the JET technical-event journal and fiscal archives can follow separate chaining rules. Treating these as one global transaction stream risks joining documents that must be distinguished or losing the independent continuity needed for an audit. In a distributed estate, architects must explicitly define the scope and ownership of each sequence, including how its relationship to document numbering is maintained. [6]
The real failure modes emerge between systems
Centralising signatures in a cloud service can simplify key management, standardise a certified fiscal module and reduce local software divergence. It also introduces a critical dependency at the moment a sale becomes final. If a store loses connectivity, delaying the signature until reconnection may conflict with the intended ordering and registration lifecycle; allowing the store to sign locally requires a controlled key model, unambiguous sequence ownership and a reconciliation process that never silently rewrites history. The correct offline design depends on the certified system boundary and cannot be solved by adding a generic queue after checkout.
The hardest operational episodes often occur outside ordinary sales. A restored database might contain an earlier predecessor value, a migrated POS instance might reuse an existing sequence, and a key rotation could make historical records unverifiable if public keys and their validity periods are not retained. The cited technical account associates key-pair changes with a JET event and describes key identifiers as part of the verification design. Retailers should consequently view backups, disaster recovery, terminal replacement, migration and long-term public-key availability as fiscal controls, not merely infrastructure procedures. [6]
The abbreviated signature printed on a receipt is useful as a pointer from a customer-facing document to the underlying signed record, but it should not be mistaken for the complete signature or an independent guarantee of integrity. A meaningful audit needs the original canonical data, full cryptographic signature, applicable public key, predecessor relationship, relevant event history and a working verification process. SAP’s documentation of NF525 POS object signing likewise emphasises signatures as a mechanism for traceable origin and subsequent integrity checks. [6][7]
Certification should be assessed at the boundary of the entire retail system
For retailers, the purchasing question is broader than whether a POS vendor advertises NF525 support. A multinational checkout platform may depend on a fiscal middleware service, a central transaction engine and multiple country-specific connectors; each participant can transform a value before it reaches the signer. The resulting risk is architectural: one component may be individually secure while the overall transaction chain is not reproducible. Retailers should ask vendors to demonstrate the same test transaction through POS registration, canonical formatting, signing, archival export and independent verification, including an interrupted network connection and a recovered terminal.
An effective acceptance test also needs to cover mixed VAT rates, rounding boundaries, cancellations, partial returns, training events, duplicated documents and records containing delimiter characters. It should deliberately introduce a modified amount or missing predecessor signature and confirm that verification fails, while documenting how authorised corrections are registered as new events. Such testing is valuable even in systems relying on publisher attestation rather than NF525 certification because it targets the underlying ISCA goals rather than a label alone.
A lesson for the next generation of retail infrastructure
France is a useful case study for a larger change taking place in global retail technology. As checkout becomes less tied to a physical cash register and more dependent on distributed services, fiscal compliance must move with the transaction without losing the ability to reconstruct it later. In the coming generation of agent-driven commerce, the sales interface may be controlled by an AI assistant or marketplace, yet the merchant’s systems will still need a defensible record of what was sold, which tax treatment was applied, when the transaction was registered and how its integrity can be demonstrated.
My conclusion is that cryptographic signing is best understood as a contract across the retail technology landscape. The signature proves something only when the participating systems agree on the canonical event, sequence, custody of keys, boundary of certification and long-term verification evidence. That is the genuinely demanding part of France’s NF525 model, and it is also why fiscal compliance increasingly belongs in the core architecture of commerce software rather than being treated as a final step before a receipt is printed.
Sources and further reading
[1] French General Tax Code, Article 286 I 3° bis. https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000006309924
[2] French tax administration, BOI-TVA-DECLA-30-10-30, 25 March 2026. https://bofip.impots.gouv.fr/bofip/10691-PGP.html/identifiant=BOI-TVA-DECLA-30-10-30-20260325
[3] INFOCERT, NF525 certification of POS software. https://infocert.org/nf525/
[4] French Ministry of Economy, Cash-register software certification, 24 February 2026. https://www.economie.gouv.fr/entreprises/gerer-son-entreprise-au-quotidien/gerer-sa-comptabilite-et-ses-demarches/ce-quil-faut-savoir-sur-la-certification-des-logiciels-de-caisse
[5] French public service, Restoration of publisher self-attestation, 24 February 2026. https://entreprendre.service-public.gouv.fr/actualites/A18087
[6] Tamara Tegeltija, Signing Receipts in France, Fiscal Solutions Fiscal Portal, 20 October 2026. https://www.fiscal-requirements.com/news/6088-signing-receipts-in-france-how-nf525-electronic-signatures-and-chaining-work-in-practice
[7] SAP Help Portal, POS Software Certification According to NF 525. https://help.sap.com/docs/SAP_CUSTOMER_CHECKOUT/71570024ae3843f08a10d68054192d3d/d042d2459efb431c80f7ae774c751a9d.html
