Efsta Documentation

website·Indexed 34 days ago

https://docs.efsta.eu

Technical documentation for Efsta's multi-country e-invoicing and fiscalisation services. It includes the EFR API reference for register operations, Cloud EFR managed services, and country-specific integration guides for Germany, Italy, Poland, and others. The docs cover Web-API installation, firewall settings for fiscal authorities, and reporting obligations such as the German KassensichV and Section 146a (4) AO.

Tokens
259.8K
Snippets
675
Records
1.9K
Agent score
62%

What's inside Efsta

  1. Overview of the EFR Generic Interface for Imports

    The EFR Generic Interface is a standardized API available from version 2.5.0 that can be used for all countries. While the generic interface provides a baseline for imports, developers should consult country-specific guides for any additional regional requirements. Changes to this interface are designed to be backwards compatible.
  2. Overview of Austrian Cash Register Signature Requirements

    According to the Austrian Cash Register Ordinance (RKSV), every cash register must use a signature creation unit (Signaturerstellungseinheit SEE) for digital signing. This can be implemented as a hardware component (signature module or smart card), a software-based solution, or a cloud-based service.
  3. Overview of the EFR Unified API

    The EFR (Electronic Fiscal Register) is a middleware used for fiscalization, e-invoicing, and receipt archiving. It processes transactions according to the fiscal requirements of the configured country. It can be deployed on-site with a POS, in a datacenter, or in the efsta cloud. On-site deployments can control local signing devices or fiscal printers.
  4. Overview of efsta EFR ISCA Compliance

    The EFR (efsta Fiscal Record) subsystem acts as a supplement to POS applications to meet the Inalterability, Security, Storage, and Archiving (ISCA) conditions required by the French "VAT Anti-Fraud" Law. It achieves this through ECDSA (NIST P-256 curve) certificates, electronic signatures for all fiscal transactions, and a secure data stream to the efsta Cloud.
  5. Overview of the efsta reporting process for Section 146a (4) AO

    Taxable companies must report the status of their electronic recording systems (eAs) to MeinElster. The efsta solution follows a four-step workflow:

    1. Enter MeinElster contact data in the efsta portal.
    2. Verify and complete mandatory reporting data in the efsta portal/EFR.
    3. Receive weekly informational emails from efsta if changes occur.
    4. Download the generated XML file from the efsta portal and upload it to MeinElster for review.

    Efsta monitors the following trigger points every Monday to notify the Elster contact via email:

    • Addition or removal of an Electronic Fiscal Register (EFR).
    • Changes at the terminal level (e.g., serial number, hardware), excluding the internal efsta identifier (TT).
    • Activation or deactivation of a TSE.
    • Addition or removal of a location/business premise.
    • Changes to the tax number (Note: This requires closing the existing EFR instance and deregistering the TSE before creating a new company/EFR).
  6. Overview of EFR System Interface

    The EFR serves as a system interface for certified fiscal printers. It does NOT replace a fiscal printer, as a physical printer is still required to comply with fiscal laws. The EFR maintains secure journals. To print sales transactions, the system requires a transaction sent via a REST web request containing sales data and a formatting file that defines the formal representation of that data.
  7. Overview of EFR functions for EET 2.0

    The EFR (Electronic Fiscal Register) acts as an intermediary between the cash register application and the Czech tax authority. Its primary responsibilities include:

    • Generating registered sale data messages from ESR data.
    • Signing messages locally using a point-of-sale certificate (WS-Security, RSA-SHA256).
    • Sending requests to the EET system via HTTPS (TLS 1.2 or higher).
    • Verifying electronic signatures on acknowledgements from the tax authority.
    • Maintaining a transaction protocol and journal.
    • Handling retries during network failures and providing tamper-proof archiving via encrypted cloud storage.
  8. Overview of efsta reporting for Section 146a (4) AO

    Taxable companies must report the status of their electronic recording systems (eAs) to comply with Section 146a (4) AO. The efsta solution facilitates this by managing reporting data and providing XML files for upload to MeinElster. The process generally involves: entering MeinElster contact data, verifying mandatory reporting data, receiving weekly notifications of changes, and uploading XML files to MeinElster.
  9. Overview of Cloud EFR

    Cloud EFR is a fully efsta-managed fiscalisation service hosted in efsta's cloud infrastructure. It requires no local software installation or maintenance. It is accessible via an HTTPS API using OAuth Bearer token authentication and uses the same transaction request format as a locally installed EFR.

    Key Constraints:

    • Exclusively for cloud-based POS systems with no offline capability. If offline support is needed, use Local EFR.
    • No local web UI (no localhost:5618).
    • No fiscal hardware (printers, signature devices) is supported or required.
    • Available only on request via a partner manager or ticket@efsta.eu.
  10. Overview of efsta E-Invoicing module

    The efsta E-Invoicing module is a compliance solution integrated into the Electronic Fiscal Register (EFR). It manages the structure, formatting, and transport of invoices for B2B, B2C, and B2G scenarios. The solution is format-agnostic (not tied to a specific format like ZUGFeRD) and provides invoice management via the efsta Portal.
  11. Overview of efsta electronic fiscal register (EFR)

    The efsta middleware electronic fiscal register (EFR) is software designed to meet country-specific fiscalization requirements. It receives transaction data via a REST interface from upstream systems (such as POS, ERP, or PMS), forwards it to a fiscal device if required, or processes it internally. Fiscalized data is stored encrypted in the efsta Cloud archive.
  12. Overview of EFR for Hungarian Fiscal Law

    The EFR (Electronic Fiscal Record) acts as a system interface to certified fiscal printers to comply with Hungarian fiscal law. It does not replace the fiscal printer, which is still required for printing sales transactions and maintaining secure journals. To process a transaction, the EFR requires a transaction sent via a REST web request containing sales data and a formatting file that defines the formal representation of that data.