E-Invoicing Architecture
EFR Platform
The E-Invoicing functionality is part of a system with various architectural configurations within the EFR middleware. It can be deployed locally (e.g., in POS systems), on-premise for multiple clients, centralized (e.g., in ERP systems), or as a cloud-based service. Integrated into the efsta ecosystem, the EFR platform ensures secure data processing and transport, long-term archiving, and system management through the efsta Cloud Portal.
The fiscalization and E-Invoicing modules are non-exclusive, allowing for invoices that are fiscalized according to the relevant laws to be sent from the POS system to the customer in a structured format. Both functions can also operate independently, with the efsta Portal providing monitoring capabilities in either case.
To facilitate seamless integration of E-Invoicing into existing workflows, the ESR (efsta Simple Receipt) format has been expanded with additional data fields. Details on this extension are provided in the following chapters.
E-Invoicing Module
Workflow
The workflow for the /register REST request follows the usual POS rules, with the exception that
additional formal checks are performed on the supplied data. In case of an invalid XML
result, the request is rejected with <Result RC="BAD" ErrorCode="xxx"/\> (http status code 406),
returning the code of the failed validation rule. Please fix potential errors during development to
avoid problems in the production environment.
Please mind that the validation of the data (recipient) takes place online, so the request can take up to 5 seconds longer than a normal transaction.
If the EFR is offline when you create an E-Invoice, validation will be skipped and the E-Invoice will be temporarily stored on the EFR.
As soon as the EFR service is back online, the E-Invoice will be sent.
In this case, a validation error may occur after the E-Invoice has been created and the E-Invoice cannot be delivered.
You will be notified of this process via email to the address specified in ContactElectronicMail.
Structure
Once an invoice is validated, it moves through several processing stages.
First, the ESR gets normalized, which means that if there are incorrect values, our system tries to correct them automatically wherever possible. For example, if a value is only valid in uppercase but sent in lowercase instead, our system will correct the spelling and log a warning for traceability. Here is a list of the values which are checked and normalized if needed:
| Country | Value | Normalization |
|---|---|---|
| General | TaxId | Add country specific prefix |
[DE]  | Email Leitweg ID | Lowercase Uppercase |
[IT]  | IT_CodiceDestinatario IT_CodiceFiscale | Uppercase Uppercase |
When the value of a provided field like IT_CodiceDestinatario, IT_PECDestinatario, TaxId, aso. is completely invalid, our system notifies the customer with a mail.
After normalization, our system creates the XML invoice and then validates it against the country-specific XML schema of the financial authorities. The validated XML is then sent to the financial authority.
After submission, the invoice status is monitored, although this step depends on the country:
- In Poland, the request is added to a queue. A scheduled check runs after a defined time to fetch the current status once the invoice has been processed.
- In Italy, the financial authority actively notifies our system by sending an API callback with the invoice status.
If an error occurs at any point, an email will be sent out containing a link that allows correcting invoice details and resending the invoice (see chapter "Delivery Error" in Use Cases - Correcting.
Invoice processing works differently in each country. In the future, Peppol may offer a unified and simplified approach.
Error Handling
The formal rules of an E-Invoice exceed the data required for a normal receipt and have to stand
automatic check routines, that are performed before fiscalization and delivery (e.g. .xsd
validation). In case of severe error HTTP StatusCode 406, RC="BAD" is delivered by EFR.
To find out more details about a failed transaction see directory
/EFR/rn/def/log/{yyyymmddhhmmss}.log, where request and XML data is stored. Explanation
for errors can be found in the internet, use "UBL" and the error code for searching.
In case of a transport system outage the sending will be retried.
If the document cannot be delivered because of an error of the receiver, the forwarding is done immediately.