PaperlayerView exact revision on arXiv

Source-linked AI summary

Blockchain-Enabled Secure Logging for Fiscal Electronic Mechanisms: Evaluation of the Greek eSEND and myDATA Tax Systems

Panagiotis Mavridis, Anargyros Baklezos, Christos Nikolopoulos

arXiv:2609.04356v1cs.CRcs.AIecon.EM

TL;DR

The paper examines transaction-integrity protections in Greek fiscal mechanisms and the e-invoicing path to myDATA. It analyzes device hash chains and eSEND validation, finding that the FEM/eSEND path has safeguards absent from EIPS/myDATA.

Abstract

from arXiv · show

This paper analyzes the implementation of blockchain-based integrity mechanisms in Greek Fiscal Electronic Mechanisms (FEMs) and the central tax information system eSEND. The study examines the cryptographic architecture of fiscal devices, including Electronic Cash Registers, Fiscal Printers, Fiscal Signing Machines, and FEMAS devices, which implement double or triple hash-chain structures to ensure transaction immutability. The transmission protocol between fiscal devices and the central database is also evaluated with respect to encryption, sequential validation, and blockchain verification. In contrast, the architecture of Electronic Invoicing Provider Services and the myDATA central platform is analyzed, highlighting the absence of blockchain-based integrity guarantees. The comparison demonstrates that hardware-based fiscal mechanisms provide stronger guarantees for transaction completeness and tamper resistance than purely software-based invoicing infrastructures. The findings highlight architectural weaknesses in the current e-invoicing framework and propose improvements for ensuring transaction integrity in digital tax ecosystems.

I. INTRODUCTION

The introduction defines hash chaining as a basis for transaction immutability and presents the paper’s examination of Greek fiscal-device logging and data transmission. For Fiscal ECRs, protected memory and three linked hash chains structure receipt and Z-report records.

I. INTRODUCTION

  • Hash chaining links blocks through hashes, so altering recorded data requires altering subsequent blocks.Each block also contains a timestamp and transaction data.Source: §I · p. 1
  • Issuance-time digital stamps or hashes authenticate invoice and receipt content and origin under cited European and Greek requirements.The introduction also reviews blockchain applications to tax reporting and information exchange.Source: §I · p. 1
  • The paper examines Greek FEM hash-chain integrity and eSEND validation, contrasting them with EIPS data transmission to myDATA, where blockchain is absent.FEM examples include ECRs, AFDs, EAFDSS, FEMAS, and EFTPOS.Source: §I · p. 2

A. Fiscal Electronic Cash Registers: Triple Blockchain Implementation

  • Fiscal ECRs use a sealed package and protected fiscal memory; working-memory accumulators total receipt net values and VAT by category.The fiscal memory permits writing but prohibits deleting or modifying data, and is enclosed in a separate compartment surrounded by resin.Source: A. Fiscal Electronic Cash Registers:… · p. 2
  • ECRs hash receipts, link each Z report to the previous one, and construct additional c.txt and d.txt hash chains.The d.txt value combines hashes of the current Z report’s receipt lines with the preceding Z report’s total hash.Source: A. Fiscal Electronic Cash Registers:… · pp. 2–3

B. Fiscal Printers: Triple Blockchain Implementation

Greek Fiscal Printers are Fiscal ECRs without keyboards: they accept sales orders from computers through a protocol. Their remaining functions, including triple block-chain implementation, match those of Fiscal ECRs.

B. Fiscal Printers: Triple Blockchain Implementation

C. Fiscal Signing Machines - EAFDSS: Double Blockchain Implementation

EAFDSS processes fiscal documents from a connected computer and maintains two hash chains, but its printer connection can be bypassed by ERP software.

C. Fiscal Signing Machines - EAFDSS: Double Blockchain Implementation

D. Fiscal Signing Machines - FEMAS: Triple Blockchain Implementation

FEMAS combines cash-register and signing-machine functions, storing receipt files on an integrated SD card and implementing three hash chains.

D. Fiscal Signing Machines - FEMAS: Triple Blockchain Implementation

III. CONNECTION OF EFTPOS AND GREEK FISCAL ELECTRONICS MECHANISMS: BLOCKCHAIN IMPLEMENTATION OF EFTPOS TRANSACTIONS

Greek FEMs must issue a fiscal receipt before sending a transaction amount to EFTPOS. The protocol records payment totals and sends detailed card-payment data to eSEND for receipt matching by auditors.

III. CONNECTION OF EFTPOS AND GREEK FISCAL ELECTRONICS MECHANISMS: BLOCKCHAIN IMPLEMENTATION OF EFTPOS TRANSACTIONS

  • The FEM sends the amount to EFTPOS only after issuing a fiscal receipt, pairing card payments with receipts.Source: §III · p. 5
  • After each payment, transaction details return to the FEM and are printed after the fiscal receipt; the final amount may be lower because of discounts such as loyalty offers.Source: §III · p. 5
  • The FEM chains progressive card-payment totals in fiscal memory and prints those totals when it issues a Z report.Source: §III · p. 5
  • At Z-report issuance, the FEM sends detailed EFTPOS card payments to eSEND so IAPR auditors can check their match with retail receipts.Source: §III · p. 5

IV. THE CENTRAL INFORMATION SYSTEM ESEND”

FEM sales data are sent to eSEND, with offline Z-report data retained for later transmission and FEM-specific AES-256 encryption keys used for package exchange.

IV. THE CENTRAL INFORMATION SYSTEM ESEND”

  • If internet access is unavailable when a Z report is issued, the FEM stores all Z sales data on its SD card and sends them with the next Z report.Source: §IV · p. 5
  • Each FEM's transmission data are encrypted with AES-256 using a unique key obtained through an eSEND web-service call.Source: §IV · p. 5
  • The FEM uses its unique AES key to encrypt packages sent to eSEND, which uses that key to decrypt the packages from that FEM.Source: §IV · p. 5

A. The back-end: Receiving sales data from the FEMs

eSEND decrypts FEM submissions, accepts only the next expected Z report, and rejects data that fail the blockchain rule. These checks support completeness of received sales data, which are stored in the IAPR database with fields defined in Table C.

A. The back-end: Receiving sales data from the FEMs

B. The Front-end: User Interface of the central information system “eSEND”

The eSEND front end displays sales data received from FEMs through a website accessible to businesses and citizens. The section also summarizes the conditions and checks governing FEM-to-eSEND transmission.

B. The Front-end: User Interface of the central information system “eSEND”

V. FUNCTIONALITY OF ELECTRONIC INVOICING PROVIDER SERVICE

An Electronic Invoicing Provider Service routes issuer documents through a provider to myDATA and, where supported, to the recipient. Retail issuers also print the receipt locally.

V. FUNCTIONALITY OF ELECTRONIC INVOICING PROVIDER SERVICE

  • The issuer sends each receipt or invoice through the EIPS application to the Electronic Invoicing Provider, which authenticates it using a hash algorithm.Source: §V · p. 6
  • After authentication, the provider sends the document to IAPR’s myDATA database and to the recipient or the recipient’s provider, if the recipient has electronic-document receiving infrastructure.Source: §V · p. 6
  • For retail transactions, the issuer prints the receipt on a local printer; EIPS obligations and functionality are described in specified decisions and amendments.Source: §V · p. 6

VI. RULES FOR DATA TRANSFER FROM EIPS TO MYDATA

When connected, the issuer’s sales document is sent in real time through the provider to myDATA over HTTPS. Offline issuance and the absence of required blockchain and consecutive numbering leave gaps in the available integrity checks.

VI. RULES FOR DATA TRANSFER FROM EIPS TO MYDATA

  • With an internet connection to the provider, the issuer transfers the sales document in real time to the provider and then myDATA using HTTPS.Source: §VI · pp. 6–7
  • Fig. 8 is identified as depicting the functionality of an Electronic Invoicing Provider Service.Source: Figure 8 · p. 7
  • During a connection outage, the issuer may issue invoices or receipts offline for 24 hours before transmitting them to the provider.Source: §VI · p. 7
  • Because the issuer uses a computer without FEM hardware safeguards, documents may be deleted or modified before provider transmission.Source: §VI · p. 7
  • Blockchain maintenance is not required, and sales-document numbering may restart each fiscal period, so a document numbered 1000 need not follow 999.Source: §VI · p. 7
  • Unique myDATA MARK numbers are not consecutive per business, so auditors cannot use them to determine whether documents are missing.Source: §VI · p. 7

VII. CONCLUSION

FEMs transmit sales documents to eSEND, where sequential Z-number and blockchain-hash checks ensure sales-data integrity. By contrast, the paper reports that myDATA lacks these and other controls, leaving completeness uncertain to tax auditors.

VII. CONCLUSION

  • FEMs use tamper-proof hardware, fiscal memories, progressive sales-document numbers, AES encryption, and blockchain when transmitting sales documents to eSEND.The paper contrasts this set of controls with the absences it identifies for EIPS transmissions to myDATA.Source: §VII · p. 7
  • eSEND checks each Z package’s sequential number and blockchain hash, which the paper says ensures sales-data integrity.FEMs transmit all sales documents they issue to eSEND.Source: §VII · p. 7
  • For EIPS-to-myDATA transmissions, missing hardware, fiscal memories, progressive document numbers, consecutive MARK numbers, blockchain, and sequential-transmission requirements leave sales-data integrity lacking.The paper says this also leaves tax auditors uncertain whether a company transmitted all its sales documents or only some.Source: §VII · p. 7
Loading 2609.04356v1…