Response Examples & Error Handling

Elise Basic Validation

This process makes sure that the required fields are provided. If any of the required fields are missing or are invalid, this process throws Elise Basic Validation Exception.

Send Method Validation

This process is responsible for checking that email recipients exist when the provided send method requires them. Supported Send Methods are:

E E-mail

A Archive

M SMS/Viber

C Email and SMS/Viber

If requirements are not fulfilled, the process throws Elise Basic Validation Exception.

Issuer Authentication

This process is responsible for validating that document issuer is an active subscriber with a valid API key. The process retrieves the issuer from the database and updates the software cache, adding the current issuer vat. If issuer.vat is not found, provided API key is invalid, or anything else unexpected happens, it throws an Elise Authentication Exception.

Conversion to Elise Core

This process converts an object to Elise Core Document. The conversion takes into consideration any Parsing Rules that are registered to the corresponding conversion type. Those parsing rules can apply to all companies, or just the issuer company. The Elise Core Document that is produced is treated as the “one and true” document. Any process that follows depends on this document. Any exception during the conversion procedure, results in an Elise Conversion Exception.

Uniqueness Validation

This process ensures that the incoming document has not already been successfully sent to the service. In order to do so, it produces the incoming document’s UID (as described by IAPR documentation) and checks the issuer’s database for any document with the same UID.

The uniqueness check performed by the Provider continues to be applied to the invoice UID, which is derived from the following fields:
{issuer.vat}-{dateIssued:yyyy-MM-dd}-{issuer.branchCode}-{invoiceTypeCode}-{series}-{number}

Basic Rule
If an invoice is transmitted with specific details (e.g., Series A, Number 1, Date 2026-02-20, Type 1.1, Branch 0) and a new transmission is attempted with the same details (i.e., the same UID), then:

If the first invoice has already been successfully transmitted and has received a MARK, the Provider will return a 409 Conflict error.

Concurrent Transmission Scenario

Since all invoices are now recorded, if two transmissions occur simultaneously (for example, sending two invoices within 2 minutes with the same uniqueId) and the first transmission has not yet been completed:

The second request will receive a 408 Request Timeout error, because the processing of the first transmission has not yet finished.

Conversion to IAPR

This process converts an Elise Core Document to AadeBookInvoiceType, as described by IAPR documentation. The conversion takes into account all issuer’s Parsing Rules, alongside the generic parsing rules that correspond to this conversion type. Any exception during the conversion procedure, results in an Elise Conversion Exception.

Signature Data Validation

This process is included when Documents sent to the API contain the XML for IAPR. It is responsible for validating that the data sent to IAPR in field aadeXml are consistent with the corresponding data in the Elise Core Document. Fields checked for consistency are the following:

Issuer Vat,

Issuer Branch Code,

Invoice Type

Series

Number

Total Vat Amount

Counter Party Vat

Total Gross Amount (this check is optional and by default skipped, due to IAPR’s inability to perform correct checks)

Postage to IAPR

This process is handled by the “AadeMyData” Module. Any errors during this process, which includes pre-validation and actual IAPR validation steps, result in an IAPR Exception.

IAPR response handling

This process is responsible for updating the incoming document with data provided by

IAPR: Authentication Code, Mark, UID

Elise: Public Salt, Public Signature, Private Signature

Data Persistence

This multi part process is responsible for persisting all data that need to be stored. It handles the following data:

In case of outgoing invoices:

Saves Elise Core Document in Azure Blob Storage

Saves Invoice Counter Party in SQL database

Updates POS activity in Azure Table Storage

Updates Awaited Invoices (Offline Module)

In case of incoming invoices:

Saves Invoice issuer in SQL database

In both cases:

Saves raw document in Azure Blob Storage (the raw data of the request)

Saves document’s metadata in SQL databases of both issuer and counter party (if same database only one copy is created).

If any unhandled error occurs during these processes, an Elise SQL Storage Exception is thrown.

Notification Service

This service is responsible for adding the incoming document to the notification queue. Entries are read and emails are produced and sent to inform the document’s counterpart that a new invoice has been sent. Any errors during this process, result in Elise Notification Service Exception.

Success Response

If no preceding process throws an exception, the API responds with a HTTP-Created Status code (201). Alongside the public document url, an object is sent back to the caller, including:

Success status, set to true

Message informing that all processes have successfully completed

Integrity Signature

Signature

UID

Mark

AuthenticationCode

MyDataResponse

Responses

- 201 - Success
The document has been transmitted successfully

- 400 – Bad Request
There is an error in the data in the payload

- 401 - Unauthorized
The authentication failed

- 408 - Request Timeout
IAPR service is down

- 409 - Conflict
The document has already been transmitted to IAPR

- 5xx - Server Error
There is an exception to our server

Mandatory Metadata Display on Document Visualization

Detailed description of all the essential fields required on printed invoices.
It covers both scenarios: receiving a successful MARK and instances of connectivity loss.
Below, you will find the mandatory printing fields for invoices in each situation, ensuring compliance and accuracy in data representation.
Additionally, this guide includes instructions for composing the offline QR code in cases of connectivity loss.
This guide aims to assist users in understanding and implementing the necessary specifications for proper invoice printing, in compliance with the legislative requirements of the IARP (ΑΑΔΕ).

HTTP Response case

🎯 Case 1: Success MARK (HTTP 201)

Document successfully transmitted to IAPR and MARK assigned.
Response Example:

💡

🖨️ Mandatory Printing Fields

Label	Value
MARK	Received as a response from REST API call "mark"
UID	Received as a response from REST API call "uid"
Authentication code	Received as a response from REST API call "authenticationCode"
Service Provider Name:	Information systems IMPACT Μον. AE
Service Provider URL	www.einvoicing.gr
License Number (YPAHES)	2023_10_103Impact_002_Impact eInvoicing_V1_24102023
QR code	Received as a response from REST API call "url"

⚠️ Case 2: Transmission Failure Issuer ↔ Service Provider

❌ Case 3: Transmission Failure Service Provider ↔ IAPR (ΑΑΔΕ)

When visualizing an document, the following metadata must be clearly and visibly displayed:
- MARK: The unique identifier number assigned to the invoice by the tax authority.
- Signature: The digital signature verifying the authenticity of the invoice.(Defined in the API response as: authenticationCode)
- UID: The unique identifier of the document.
- Service Supplier: The name and identifier of the certified e-invoicing service provider.
- Certification Number: The official certification number of the service provider, as issued by the competent authority.

📌

These fields are mandatory and must appear in a readable and standardized manner on all rendered invoice views.

Response Examples & Error Handling

Elise Basic Validation#

Send Method Validation#

Issuer Authentication#

Uniqueness Validation#

Conversion to IAPR#

Signature Data Validation#

Postage to IAPR#

Data Persistence#

Notification Service#

Success Response#

Responses#

Mandatory Metadata Display on Document Visualization#

HTTP Response case#