Last Updated: 1 August 2023

6. Audits 

6
Audit data represents machine readable formatted fiscal invoice signed by a taxpayer’s private key followed by journal data — textual representation of a fiscal invoice generated by an E-SDC.

Content of audit data is kept in encrypted form that makes sure no changes have been made and that no one was able to access its content after creation except the CEO (and the Service’s system) after successful audit.

Each package of audit data has associated metadata — ordinal number of package. It is used to track order and make sure audit data is submitted in the consecutive order.

6.1. Encryption of Audit Data

Encryption of audit data prevents access to sales data by unauthorised persons and enables addition of fiscal lottery to the Service’s system in the future. The only one who can decrypt audit data is the Service’s system software running on the Service premises and by the CEO only.

6.2. Proof of Audit

Proof of audit is generated by the Service’s system once audit data has been received and securely stored on the Service’s system.

Minimum information contained in proof of audit must ensure that proof of audit can be used only by the secure element which signed receipts that are contained in the audit data received by the Service’s system.

6.3. Audit Process

An audit is a process of sequential transfer of audit data from an E-SDC to the Service’s system and handling the response generated by the Service’s system for the specific device.

There are three specific scenarios: remote audit, local audit initiated by a taxpayer and local audit initiated by the Service. Basic rules and processes described in this paragraph apply to all scenarios.

An audit is always a synchronous process. Depending on the amount of data and means of communication, it can take from less than a second to a couple of hours or even days to complete.

6.4. SD Card or USB Flash Memory Stick

SD cards or USB memory stick are used as transport mechanism instead of internet connection in cases of local audits initiated by a taxpayer or by the Service. In any case, the carrier has to be empty for an E-SDC to initiate dumping of audit data.

Once the E-SDC receives audit data (signed receipt and journal) from the secure element, it is encrypted and stored in the permanent memory (hard drive, flash or internal SD card).

An E-SDC device is fully functional during audit. The taxpayer must be able to sign new receipts as long as the secure element permits. There is a mechanism in place that is responsible for continuous operation of the secure element and E-SDC while audit data is on its way to the Service’s system.

Depending on the connection availability audit may be triggered by the arrival of a signed receipt from the secure element or insertion of an external memory device into the E-SDC. No matter which event triggered the audit, the following conversation will take place between the E-SDC, the Service’s system and the secure element:

  • 1.the E-SDC signals the beginning of the audit to the secure element;
  • 2.the secure element returns token to the E-SDC;
  • 3.the E-SDC starts sending (by HTTPS) or dumping on external memory (SD card, USB flash) audit data starting with the oldest unaudited package in piecemeal fashion. A token is sent to the Service’s system using the same communication channel;
  • 4.the Service’s system receives audit data, decrypts packages and does a basic verification;
  • 5.if verification is successful, the Service’s system will generate proof of audit and return it using the same transport channel;
  • 6.the E-SDC receives proof of audit and passes it to secure the element;
  • 7.the secure element verifies if proof of audit is signed by the Service’s system private key, which ensures that audit data has been successfully received by the Service’s system;
  • 8.if proof of audit is valid, the secure element will conclude audit process;
  • 9.the E-SDC stores proof of audit in its long-term memory. Consequently—
    • (i)audit data created before beginning of audit is considered safe for deleting because it has been received by the Service’s system;
    • (ii)audit data created after beginning of audit is considered unaudited and E-SDC is responsible to preserve this audit data unit which is submitted to the Service’s system in the next audit;
    • (iii)audit data created after end of audit is considered unaudited and E-SDC is responsible to preserve this audit data unit which is submitted to the Service’s system in the next audit.

6.5 Remote Audit

Remote audit is the process of transferring data to the Service’s system using internet connection. It is the most common way to perform audit for any occasionally connected device.

An E-SDC checks if the Service’s system is online. If it is online, the E-SDC authenticates the Service’s system by using server-side certificate installed on the API endpoint, enabling HTTPS protocol. The Service’s system authenticates the E-SDC using digital certificate issued on the secure element. The E-SDC starts sending audit data in small chunks, performing a series of audits until no more unaudited data is stored on its long-term memory.

Not all E-SDC devices are required to perform remote audit. In cases where the network connection is not available due to the interruption of the service or missing GPRS modem or network card, the E-SDC will still be able to perform Local Audit.

6.6. Local Audit Initiated by Taxpayer

Local audit initiated by a taxpayer is a common scenario for devices that lack ability to connect to internet due to the technical limitations of the devices or limited infrastructure.

An audit is initiated by attaching an empty SD card or USB Flash to E-SDC device. An E-SDC will verify if media is empty. If not, the E-SDC will signal error to the user.

6.7. Submitting Data in Service Office

The CEO can upload data using specific application that will store deleted audit data from media and save proof of audit generated by the Service’s system to media once audit data has been received.

6.8. Submitting Data Using Web Application

Anyone should be able to upload limited amount of audit data (for example, up to 30Mb) using web site. The Service’s system will verify received audit data and generate proof of audit as a response. A user will be required to manually delete audit data from media and save received proof of audit for later use.

6.9. Completing Audit in Progress

A taxpayer inserts media with proof of audit file on it. An E-SDC loads proof of audit and verifies if the format is valid. If the format is valid, proof of audit is sent to the secure element for processing.

If the format is invalid or the E-SDC and the secure element cannot process proof of audit for any reason, the E-SDC signals error message to the operator.

6.10. Local Audit Initiated by Service

Local Audit initiated by the CEO is required when the taxpayer is not reporting transactions for any reason. If an E-SDC and the secure element are operational, the CEO will dump data using the same scenario as the taxpayer.