The fiskaltrust team knows there are many stumbling blocks on the way to a legally compliant POS system in France. The legislature outlined the principles in the law, which are expected from POS manufacturers and operators. Then came a few regulations that specified the parameters even more precisely. And in the end, the two certification bodies adapted to this with their rules and interpreted the requirements in their own way. But what are these principles really all about? Read on for a neutral and independent account.
Why only four cornerstones?
In France, they don’t think much of exact rules that define everything down to the last detail. No! It is more so assumed that once the cornerstones are defined, everyone can implement them as they see fit. This freedom gives the cash register manufacturers a lot of possibilities and also liberty in their solutions.
In the BOI-TVA-DECLA-30-10-30 of 30 December 2020, the 2nd section defines the four principles or specifications in more detail. We also take a look at this to reduce the mystery around it and to be able to offer a secure and legally compliant POS system with a clear view.
The four principles need a foundation!
The legislator clearly states that only POS systems or, in the case of multifunctional software (PMS for hotels, ERP systems, or similar), only the POS module is to be secured.
The goal is clearly defined as the verification of the recorded data by the tax authorities. However, no exact specification or technical solution is prescribed in the law or the ordinance. Thus, the development of the technical solution becomes the sole responsibility of the private sector.
The software used must, therefore, record all original payment data, make it immutable, store it securely and enable the data to be archived.
The 1st pillar – Inalterability
This is the I for Inaltérabilité in ISCA and specifies as a first step the prevention of subsequent modification. Let’s take a look at what data is involved here. First of all, it is primarily about data concerning goods and/or services for which a payment is expected and for which a receipt is issued. Whether this actually applies is not important here, it is sufficient that the payment is expected and the receipt is to be issued.
What data is now affected?
There may be additional data required (determined by other legal bases), but the following list sets the lower bar for this present purpose:
- Receipt number
- Date and time
- Cash register number (or terminal number)
- Total amount of the receipt (including all taxes)
- Details of the item and/or service (description, quantity, unit price, , total amount without tax, VAT rate applied)
- All data concerning the payment methods.
In addition, all data that ensures the traceability and integrity of the above data, must be saved.
Can the administrator change the data?
It is also clearly stated here that once data has been stored, it may no longer be directly changed by anyone. This also results in the consequence that all changes can only be made with plus/minus transactions. It even goes so far as to require that if no linked receipt/transactions are created, the original receipt must be cancelled and a new one created with the desired changes.
The first step is to ensure that the data is secure at the application level. This will deny the user any possibility of modification in the POS system. This means that there must be no functions or modules or tools that make it possible to directly change the data.
The next step is security at the level of the data. Since access to the data or a database can never be prevented, proof must be provided here that the data has not been changed. This can be ensured by one or more techniques. For example, a digital fingerprint (hash value over all data), a single or multiple chaining is possible or an immediate mirroring onto a data carrier outside the system is possible.
And how is this achieved technically?
The legislator makes several suggestions here:
- Prevent user access to all modification possibilities
- Detect every access/change data and track every possible change
- Provide proof that the original data has not been changed
- Provide an appropriate system of verification of the original data.
All four points are valid, but not all are technically feasible. Therefore, a mixture of all four will occur. Access to data will be restricted as far as technically possible, and hashing and chaining can at least be used to detect changes, as the original data cannot be restored.
Would you like to know how fiskaltrust.Middleware implements this for your POS system? Contact our key account manager for France without obligation.
The 2nd pillar – Security
This is the S for Sécurisation in ISCA and specifies preventing deletion or alteration as the second step. Here the main focus is on securing the recorded data and being able to identify if data has been deleted or changed.
The term security is not used in the sense of restricting access. Rather, all payments that are recorded in a POS system by any person should be saved. Also any and all changes to the original data are subject to the security requirement and must be stored.
In order to exclude any other possibility to circumvent this requirement, even data entered in the training mode of a POS system must be clearly marked and saved. On the outside with a clearly recognisable notice must appear on each receipt and internally the same notice must appear and the identification of user who activated the training mode must be recorded.
Do you want to know how the fiskaltrust.Middleware makes security possible for your POS system? Contact our Key Account Manager for France without obligation.
The 3rd Pillar – Storage
This is the C for Conservation in ISCA and specifies as the third step the storage of data by the POS system. Of particular importance here, is the consideration of deleting data if there is not enough storage space available.
In general, all data must be stored for the legally prescribed period (6 years, plus the current financial year). This is a well established requirement and has nothing to do with this regulation. However, it may be that POS systems do not have sufficient storage capacity and therefore data must be deleted.
The legislator has recognised this problem and also the advancements in technology. Therefore, the data does not have to be printed out, but can be processed electronically. However, the data concerned must be exported before deletion and an archive must be created before deletion. Only then may the deletion process be carried out.
The data stored on an external storage medium is of course also subject to the ISCA principles, must be protected against any change and the archiving must be traceable.
It is not sufficient to store only the document totals, cumulative data of a document or similar. Although this is not stated in the regulation (BOI-30-10-30), paragraphs L102B – L02E in the Tax Code (article L102b Livre des procédures fiscales) set out the retention obligations and periods for a company.
There is a little more to it than just storing!
However, this pillar also defines additional processes that a POS system must enable and store the data generated from the system. This additionally generated data must never be deleted from the system and of course it must be managed according to ISCA rules.
Here, we are talking about the total counters and the necessary closings. All POS systems must offer a daily, monthly and year-end closing. These ends of a period must be carried out by the POS user. With a closing, the respective totals for the period must be saved. In addition, the permanent perpetual counter must be added to each closing. This requirement is necessary because it records the sales since the beginning of the use of the POS system.
Period counters may only be reset to zero at the end of each of the periods concerned. All other counters may only be reset to zero if the software or hardware is changed. These counters are not affected by a simple change of the software (e.g. a version jump).
It is also repeatedly pointed out here that the data must be stored in the POS system or the software. However, the exception is made for centrally managed systems. This type of system may store the detailed data in a central computer/data centre.
Do you want to know how the fiskaltrust.Middleware facilitates data storage and the management of sales counters for your POS system? Contact our Key Account Manager for France without obligation.
The 4th pillar – Archiving
This is the A for Archivage in ISCA and specifies as the fourth step the archiving of data by the POS system. Every POS system must offer an archiving function and an archive must not contain more data than that of one calendar year or one business year.
The purpose of the archive is to freeze the data at a certain point in time. The legislator clearly distinguishes between data backup and archiving. This is because the archive is also subject to the ISCA rules and must therefore be backed up and stored in an unchangeable form. However, it may be stored from the beginning outside of the POS system.
In any case, the archive must not have a proprietary format. It must be readable by the tax authorities at any time without necessitating a special software. Since the content has not been standardised, an explanation of the content in French also must be provided to the tax authorities.
The legislator also specifies the storage location only to the extent that it must be secure. However, here again the ISCA rules apply and everything points to revision-safe storage.
Would you like to know how fiskaltrust ensures revision-safe archiving for your customers? Contact our Key Account Manager for France without obligation.
The building ISCA principles
As we can see, the building stands on a broad foundation with four mighty pillars. Of course, this has some consequences for the self attestation of your POS system or even for obtaining a certificate.
On the one hand, you have to record certain data (for example, the version of the POS system or the gross price and the tax and unit price, …) in your POS system in any case. Furthermore, you have to chain the entire data stock and sign it electronically. And in the end you even have to provide a verification tool for the archives and these also have to be linked and saved. Otherwise, someone could end up changing the contents of the archives without anyone noticing.
As you can see, the building is stable, but not quite so easy to construct! With fiskaltrust, however, you have a reliable and transparent partner at your side, with whom you can go down the road to a legally compliant POS system at any time.