NF525 certification: is your property compliant?

In 2026, NF525 certification (the French cash register certification) is back at the top of tourism professionals’ concerns. The requirement has nonetheless been in force since January 1, 2018, yet it remains one of the most underestimated in the industry. Hotels, campgrounds, residences, spas, restaurants: as soon as a property takes payments from consumers, it must be able to prove that its payment software meets the 4 criteria set by law. This is not something to plan for some vague day in the future; it is an active obligation, with real penalties in the event of an audit. This article lays the groundwork: what the regulation covers, how to assess your own situation, and how to take action methodically before you are forced to.

What NF525 certification is and who it applies to

NF525 certification is one of those regulatory obligations that stay in the blind spot until the day of a tax audit, when it is too late to improvise. Understanding what it covers, why it exists and whether your property falls within its scope is the prerequisite for any compliance process.

Definition and objectives: the 4 ISCA criteria

The 2016 Finance Act (article 88), which came into force on January 1, 2018, requires any professional who takes payments from consumers to use cash register software or a system that meets four specific criteria: data inalterability, security, retention and archiving; summarized by the French acronym ISCA. The objective is simple: to make it impossible to delete or modify a transaction after the fact, a practice that allowed some businesses to artificially understate their revenue and therefore the VAT they owed.

What the obligation means in practice is that the software used to take payments must not only work properly day to day: it must be designed from the outset to guarantee the integrity and traceability of financial data over time. It is not a constraint that applies to the way the software is used, but to the software itself; which explains why proof of compliance comes from the software vendor, not the user.

Does your property fall within the scope?

The answer is yes for almost every property in the tourism and accommodation sector, as long as they take payments from consumers, which is by definition the case. The scope is broader than it first appears: it covers not only payment for a complete stay, but also the payment of a deposit at booking, the sale of any additional service (restaurant, spa, breakfast, activities), and any payment taken on site, whatever its nature.

What often surprises operators is that NF525 certification applies per point of sale, not per property. A hotel that also runs a restaurant and a spa area potentially uses three separate payment software programs, and each of them must be covered by a separate attestation or certificate.

The most common mistake is to check the compliance of the main booking software while forgetting the tools used for secondary activities, which nonetheless account for a real share of revenue.

Attestation or certificate: what is the difference in practice?

There are two forms of proof of compliance accepted by the tax authorities, and they do not carry the same weight. The individual attestation is a statement provided by the software vendor, who takes on its own liability by certifying that its product meets the 4 ISCA criteria. The certificate, on the other hand, is issued by an accredited external body, such as the LNE or a body recognized by COFRAC, following an independent audit of the software against the NF 525 standard. The certificate offers a stronger legal guarantee, but the attestation remains valid and accepted by the authorities.

What the hotelier must have in hand is the document provided by their vendor (attestation or copy of the certificate) in an up-to-date version, matching the exact version of the software they use. This document must be available immediately in the event of an audit. Leaving it in a drawer or a forgotten email is not enough: it must be accessible, dated, and match the version of the software actually in production at the property.

The question of the version is particularly important. An attestation issued for version 3.0 of a piece of software does not cover version 4.0 if it has been updated since. It is a point few operators check on their own, even though a single update is enough to make the existing document invalid.

Knowing these definitions lays the groundwork, but you still need to gauge what non-compliance actually means, and know how to assess your own situation before an audit does it for you.

What a non-compliant property risks and how to assess your own situation

Many properties approach the NF525 question with a vague idea that “it should be fine” without having checked whether their software is actually covered, or whether the corresponding document exists and is up to date. It is precisely this approximation that exposes them to real risk during an audit. Before taking action, you first need to gauge in concrete terms what is at stake.

The concrete risks of a tax audit

In the event of an audit by the tax authorities, the property must be able to immediately present the attestation or certificate covering each payment software program used. The absence of this document is enough to constitute a compliance failure, regardless of how the software is used day to day. The penalty set out by law is a fine of €7,500 per non-compliant software program; not per property, but per tool. A hotel-restaurant-spa using three separate payment software programs, none of them documented, therefore theoretically faces three fines.

Beyond the fine, the risk goes further if the property cannot prove the integrity of its payment data. In that case, the tax authorities are entitled to reconstruct revenue from external evidence and claim the corresponding VAT, with late-payment surcharges. This is a scenario that goes well beyond the amount of a simple fine.

There is also the operational risk to consider: compliance triggered in a rush during an audit takes up time, contacts at the vendor, sometimes software updates; all steps that are infinitely more costly in energy and disruption to daily operations than if they had been calmly anticipated.

The 4 questions to ask yourself now about NF525 compliance

The first question to ask your software vendor is direct: does this software comply with the requirements of the 2016 Finance Act on payments? If the answer is not immediate and documented, that is already a warning sign. A serious vendor should be able to answer precisely, with the supporting document.

The second question concerns the validity of the document: is the attestation or certificate currently valid, and does it match the version of the software currently used at the property? A document valid as of the last major update is not necessarily valid for the current version; this is a point many properties overlook.

The third question concerns the actual scope: are all points of sale covered? This is where most blind spots hide (the restaurant, the spa, the gift shop, the seasonal pool bar). It is not only about the central booking software, but about every tool used to take a payment from a consumer, whatever the amount.

The fourth question relates to data retention: is payment data retained and archived under regulatory conditions, for the legal period? NF525 compliance does not only cover the moment of the transaction; it requires this data to remain accessible, intact and unalterable over time.

The most common mistakes to avoid

The first mistake, and the most widespread, is to assume compliance without checking it. A property that uses well-known or recent software is not automatically compliant: compliance must be proven by a document, not presumed from the tool’s reputation.

The second mistake is to confuse booking software with payment software. The two are not always the same tool, and their regulatory scope is different. Checking the compliance of the booking engine without looking at the restaurant’s cash register leaves part of the property exposed.

The third mistake concerns secondary points of sale: they are often forgotten during checks, because they represent a lower payment volume. But the legal criterion is not the amount, it is taking payments from consumers, and every tool concerned must be covered.

Finally, the fourth mistake is failing to update the document after a significant software update. An attestation is not valid for life: it covers a specific version of the software. Failing to renew it after a major change creates a gap between reality and the documentation, which can be penalized as non-compliance.

This map of risks and blind spots raises the next question: how do you take concrete action, and in what order?

Becoming compliant: method and tools

Identifying the risks is one thing. Taking action in an orderly way is another. NF525 compliance is not a complex process when it is anticipated; it is a series of logical steps, which can also become an opportunity to take a broader look at how the property’s payment tools are organized.

The quick checklist for your property

The first step is a complete inventory. Before contacting any vendor, you need to list all the software used to take payments from consumers at the property, including those at secondary points of sale, which are often left out of compliance processes. This inventory is the starting point without which the rest of the process remains incomplete.

Once the list is drawn up, each vendor must be contacted to explicitly obtain the individual attestation of compliance or a copy of the NF525 certificate, specifying the version of the software concerned. This request must be made clearly, in writing, so as to obtain a signed and dated document, not a simple verbal confirmation or a vague email.

The supporting documents obtained must be kept in an organized and accessible way. A document archived in an email from 2022 that cannot be found during an audit has little practical value. Ideally, these documents should be centralized in a dedicated folder, with the reference of the software version covered and the date of issue.

Compliance does not concern only the owner or the accountant: the teams handling payments day to day must understand what this obligation involves, particularly when a tool is changed or updated. Raising awareness among the managers of each point of sale (front desk, restaurant, spa) is part of the process, to prevent a software update from going unnoticed without triggering a new attestation.

Finally, anticipating changes is a habit to establish for the long term. With every major update of a payment software program, the question of the validity of the compliance document should be raised with the vendor systematically, without waiting for a reminder or an audit.

What you should be able to demand from your software vendor

A serious vendor whose software is actually compliant should be able to provide the attestation or certificate on simple request, without delay. This document must explicitly state the version of the software covered, the date of issue, and the vendor’s commitment to the 4 ISCA criteria. This is not an unusual request: it is a legal obligation that weighs on the vendor as much as on the operator.

If a vendor is unable to provide this document quickly, or answers in a vague and undocumented way, this is a warning sign to take seriously. It may indicate that the software was not developed with this obligation in mind, or that the vendor itself is not aware of its regulatory responsibilities. In both cases, the property using this software takes on a risk it will bear alone in the event of an audit.

It is also legitimate to demand a clear commitment from the vendor on the procedure to follow during updates: is every major version covered by a new compliance document? Is this document sent automatically or does it have to be requested? These questions allow you to anticipate rather than discover after the fact that a document is no longer valid.

Compliance as an opportunity to audit your management tools

The NF525 process requires an inventory of all the payment software in place at the property. It is often the first time an operator takes such a comprehensive look at their tools, and the exercise can be revealing: solutions that do not communicate with each other, redundant tools between the booking software and the restaurant’s cash register, secondary points of sale managed with a mix of tools accumulated over the years.

This mapping can be an opportunity to ask whether a more integrated approach would simplify both day-to-day management and regulatory follow-up. A PMS connected directly to a cash register mechanically reduces the number of tools to monitor for compliance, while centralizing billing and payment data in a single system. This is precisely the logic behind the connection between Reservit PMS and Reservit POS: managing on-site sales in synergy with the booking system, without multiplying independent tools to maintain separately.

NF525 compliance is not an end in itself; it is a regulatory constraint. But if it pushes a property to streamline its payment tools and gain clarity on its own organization, it will have served something more lasting than avoiding a fine.

To sum up, NF525 certification is not just another box to tick on a regulatory compliance list. It is an active tax obligation, in force since 2018, which engages the property’s liability with every payment taken from a consumer, and the penalty in the event of an audit goes well beyond a simple warning. Anticipating compliance is first and foremost about avoiding a preventable financial risk. But it is also an opportunity to take an honest look at all the payment tools in place at the property and to gain organization and clarity for the future.

Would you like to review your payment tools and check their compliance with the requirements of NF525 certification? Our teams are available to support you through this process.

Julie
Communication Manager
In partnership with Jennifer Therond