Greece
Learn about enabling Greece e-invoicing, including prerequisites, resources, and available products.
To enable support for Greece e-invoicing, contact the Sovos Professional Services team. This team provides access credentials for the Tax IDs that need to be enabled. For each VAT number, they will create a unique account with a username, an email address chosen by the respective company, and a password also selected by that company.
Prerequisites
-
A valid VAT number
-
Customer credentials from the Sovos Professional Services team
-
Authentication method configured in your account
Resources
- Independent Authority for Public Revenue (AADE) – myDATA technical specifications
-
This is your go-to for schema specification, XSD files, API documentation and version/maintenance notes
-
Page: Technical specifications – Versions of myDATA where you can download XSD files (such as "expensesClassification-v1.0.6.xsd") and see version updates.
-
PDF: myDATA API Documentation v1.0.6 includes REST API interface details and XML schema requirements.
-
- General Secretariat for Information Systems and Digital Governance (GSIS) – B2G / Public Procurement e-invoicing specification
-
Reference for the national B2G e-invoice format, PEPPOL BIS, EN 16931 compliance and routing via PEPPOL network
-
PDF: Documentation and Usage Guide of the Greek Data Format … for PEPPOL BIS-EN-v1.0. This document describes the schema for B2G e-invoicing in Greece (based on EN 16931 / PEPPOL BIS).
-
PDF: INSTRUCTIONS FOR FOREIGN B2G ECONOMIC OPERATORS (Sellers). Specifies how foreign sellers must comply with Greek B2G e-invoice schemas.
-
- EU Digital-Building-Blocks site – Greece eInvoicing guide
-
A good reference for mandate scope, status, and thresholds
-
Page: eInvoicing in Greece – European Commission on the digital building blocks site. Provides summary, link to technical documents, and status of rollout
-
Available products
-
gr_mydata__1.0
-
Outbound invoicing
MARK (Unique Invoice Registration Number)
MARK stands for Unique Invoice Registration Number (or Unique Registration Number).
It's a unique identifier that the Greek tax authority (AADE) assigns to your invoice after it validates and clears your document data through the myDATA platform.
-
Required for compliance: You must include the MARK and a QR code on electronic invoices you share with customers
-
Document tracking: Use the MARK for all future actions related to that invoice, like cancellations or retrievals
-
Immediate issuance: AADE returns the MARK immediately when your invoice submission succeeds
Error handling
When handling errors, the client application must follow the Indirect Tax API's error handling principles, as specified in the error handling documentation.
In general, all error codes in the 400 range are client errors, which you need to analyze. After fixing the error, you can resend the request. Error codes 408 and 429 are exceptions: In these cases, you should wait at least 60 seconds before retrying. Error codes in the 500 range are server errors. In that case, resend the request according to the instructions given on the error handling documentation, which also includes a full list of error codes Indirect Tax API can return.
Configure credentials for Greece
Samples for the Create settings endpoint
Request sample
[
{
"context": "transmission",
"configurations": [
{
"name": "partner_credentials_epsilon",
"value": {
"subscriptionKey": "85E5590684EC4718B632F8488DB630CF",
"email": "(Enter username here)"
"password": "{enter password here}"
},
"scope": {
"category": "GR_INV",
"productId": "gr_mydata__1.0",
"orgId": "{{orgId}}",
"taxId": "9999999999",
"operation": "<Issue or IssueLegal>"
}
}
]
}
]Response sample
{
"status": 201,
"message": "Created",
"success": true,
"timestamp": 1663415078266,
"data": [
{
"message": "Configurations are created",
"statusCode": 201,
"configurationContextResponse": {
"context": "Transmission",
"configurations": [
{
"id": SETTING-ID,
"name": "partner_credentials_epsilon",
"value": {
"subscriptionKey": "****",
"email": "(configured email)"
"password": "****"
},
"scope": {
"category": "GR_INV",
"productId": "gr_mydata__1.0",
"orgId": YOUR-ORG-ID,
"taxId": YOUR-COMPANY-TAXID
},
"auditData": {
"createdAt": 1663415078,
"createdBy": "user@company.com",
"isDeleted": false,
"version": 1
}
}
]
}
}
]Issue invoice
Issuing an invoice in Greece is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview.
Step 1: Supplier creates the Standard Business Document
Every invoice sent to Sovos must be part of a Standard Business Document (SBD). This document includes a Standard Business Document Header (SBDH) and a Sovos Document node, which in turn includes a Sovos Canonical Invoice (SCI). To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages. Here are some key elements that should be included in the SBD and in the invoice.
| Node | Required | Attributes | Value |
|---|---|---|---|
| StandardBusinessDocumentHeader.Sender.Identifier | Yes | Authority="GR" | Supplier's AFM |
| StandardBusinessDocumentHeader.Receiver.Identifier | Yes | Authority="GR" | |
| StandardBusinessDocumentHeader.DocumentIdentification.Standard | Yes | urn:oasis:names:specification:ubl:schema:xsd:Invoice-2 | |
| StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion | Yes | ||
| StandardBusinessDocumentHeader.DocumentIdentification.Type | Yes | Invoice | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: Country Child node Identifier: GR | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: ProcessType Child node Identifier: Outbound | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: CompanyCode Child node Identifier: Supplier's AFM | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: SenderDocumentId Child node Identifier: A unique document ID. We recommend the ERP document ID. | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: SenderSystemId Child node Identifier: The system ID configured in the backend. This parameter is used to determine which notifications are returned to the client and what attachments they include. If SenderSystemId is not configured on the client side, it will use the default value of "DefaultSystemERP". | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: Mapping.OutputSchema Child node Identifier: mydata | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: Mapping.TransformDocument Child node Identifier: SCI-TO-LEGAL_INVOICE | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: BusinessCategory Child node Identifier: "B2B" or "B2G" | |
| StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) | Yes |
Child node Type: Version Child node Identifier: 1.0 | |
| StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessProcess.BusinessServiceName | Yes | Default | |
| SovosDocument.SovosCanonicalInvoice.Invoice | Yes | SCI |
Here is a sample of the SBD. In addition, there's a full sample of the SBD on the Postman Samples page.
<sbd:StandardBusinessDocument xmlns="http://uri.etsi.org/01903/v1.4.1#" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
<sbd:StandardBusinessDocumentHeader>
<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
<sbd:Sender>
<sbd:Identifier Authority="PL">08AAACI9260R002</sbd:Identifier>
<sbd:ContactInformation>
<sbd:Contact>08AAACI9260R002</sbd:Contact>
<sbd:EmailAddress/>
<sbd:FaxNumber/>
<sbd:TelephoneNumber/>
<sbd:ContactTypeIdentifier/>
</sbd:ContactInformation>
</sbd:Sender>
<sbd:Receiver>
<sbd:Identifier Authority="PL"/>
<sbd:ContactInformation>
<sbd:Contact/>
<sbd:EmailAddress/>
<sbd:FaxNumber/>
<sbd:TelephoneNumber/>
<sbd:ContactTypeIdentifier/>
</sbd:ContactInformation>
</sbd:Receiver>
<sbd:DocumentIdentification>
<sbd:Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</sbd:Standard>
<sbd:TypeVersion>2.1</sbd:TypeVersion>
<sbd:InstanceIdentifier/>
<sbd:Type>Invoice</sbd:Type>
<sbd:MultipleType>false</sbd:MultipleType>
<sbd:CreationDateAndTime>2022-06-16T00:31:52Z</sbd:CreationDateAndTime>
</sbd:DocumentIdentification>
<sbd:BusinessScope>
<sbd:Scope>
<sbd:Type>Version</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>1.0</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>SenderDocumentId</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>321412</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>SenderSystemId</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>UAT101</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>CompanyCode</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>08AAACI9260R002</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Country</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>GR</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>ProcessType</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>Outbound</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Mapping.TransformDocument</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>SCI-TO-LEGAL_INVOICE</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>Mapping.OutputSchema</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>mydata</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>BusinessCategory</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:Identifier>B2B</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
<sbd:Type>BusinessProcess</sbd:Type>
<sbd:InstanceIdentifier/>
<sbd:BusinessService>
<sbd:BusinessServiceName>Default</sbd:BusinessServiceName>
</sbd:BusinessService>
</sbd:Scope>
</sbd:BusinessScope>
</sbd:StandardBusinessDocumentHeader>
<svs:SovosDocument>
<sci:SovosCanonicalInvoice>
<inv:Invoice>
*UBL Elements*
</inv:Invoice>
</sci:SovosCanonicalInvoice>
</svs:SovosDocument>
</sbd:StandardBusinessDocument>Step 2: Supplier sends the SBD to Sovos
The supplier sends a POST request to the /documents endpoint.
The request must include the following request body parameters:
| Name | Type | Required | Description |
|---|---|---|---|
| data | string | Yes | The Base64-encoded SBD from step 1 |
| dataEncoding | string | Yes | Use "base64" |
- Request sample
-
curl --location --request POST 'https://api-test.sovos.com/v1/documents' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer TOKEN' \ --header 'x-correlationId: SET-TO-UNIQUE-VALUE' \ --data-raw '{ "data": "PD9...d4=", "dataEncoding" : "base64" }' - Response sample
-
{ "timestamp": 1605282724079, "status": 202, "success": true, "message": "Document Received", "data": { "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf" } }
Step 3: Sovos maps the SCI into XML
Upon receiving the SCI, Sovos maps the file into the required XML format.
Step 4: Sovos validates the schema
Sovos validates the schema based on the information provided by the tax authority. If there are errors in the document, Sovos detects them instead of waiting for the tax authority's response.
Step 5: Sovos transmits the XML
Sovos transmits the XML file to the myDATA system.
Step 6: myDATA processes the XML
myDATA validates the invoices and verifies the supplier permissions. Then it generates a MARK, an approval or rejection response message, and an error message, if needed.
Once the myDATA system approves the invoice, the buyer can retrieve it.
Step 7: myDATA sends the response to Sovos
myDATA sends the response to Sovos.
Step 8: Supplier retrieves the application responses
- Attachments configuration
There are three ways you can access your attachments:
-
As binary data, so the file is embedded in the Base64-encoded application response.
-
As open download links, in which the response contains a public URL to download the file.
-
As secure download links, in which you need to use the Indirect Tax API's bearer token to download the attachment.
By default, Sovos configures your attachments as open download links to avoid potential size limitations when retrieving responses. To improve security, you should configure them as secure links. Then, make a GET call to the secure link returned by the Indirect Tax API, and include the API token. Sample request:
curl --location 'https://einvoicing-api.sovos.com/download/api/v1/download/JqYyqliXiJFKhXshnBQZfW3qpfwATVGE5Q73T41JUynNLJD8zHy5VH__9qzL9No-Kia9olSw3_lNX3KmaA9Je89Xx--vk5pQjyKx0iT_4CwPSABD0Yg7uxXZ8SNiliEhFY-4TOX7m1TV5FwwfqntehbGaiGMI2JVYu18VBDiC_0/plain%27 \ --header 'Authorization: Bearer TOKEN'Y-
In response to the initial sending of the document, the client receives a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the supplier must retrieve the application responses that become available during the transaction, which provide status information and the cleared XML encoded in Base64.
Additionally, you must consider the following details included in the response:
- Transmission message
- It maps to the
SCIGovtStatusCodeandStatusReasonelements in the response message, as described in the application responses documentation, which details any warnings or additional notes to consider. The Greek tax authority doesn't define any specific set of rules about what action to take on each error. Depending on the type of message, the user may have to modify the invoice, take some additional action, or make a note for the future.
Options for retrieving application responses (notifications):
- Fetch everything in one single response (notification)
- When polling for responses, Sovos returns one notification with
SCICloudStatusCodeof 209 that contains all the relevant attachments and data. Detailed description follows. - Fetch multiple responses (notifications) containing different information
- When polling for responses, Sovos returns multiple notifications with different
SCICloudStatusCodevalues that contain different attachments and data until the final one (with status 209) is returned. Detailed description follows.
To complete a transaction, the supplier retrieves only one notification, the complete workflow one. This notification includes SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, you'll need to parse the notification for the SCIResponseCode value. Possible values for SCIResponseCode:
- AP
- The document's compliance status has been accepted with all the necessary attachments and data included.
- RE
- The document's compliance status has been rejected, and more parsing is needed:
-
If
SCIGovtStatusCodeis present, the error can be found by readingStatusReason. -
If
SCIInternalValidationCodeis present, the error can be found by readingStatusReason.
-
If you receive a notification that contains SCICloudStatusCode with a value in the 5xx range, there is a server error. This means that the workflow has not completed, and you must retry the transaction.
| # | SCICloudStatusCode | SCIResponseCode | Sample |
|---|---|---|---|
| 1 | 209 | AP |
|
| 2 | 209 | RE |
|
To complete a transaction, the supplier must retrieve the application responses until the transaction has finished. If the supplier has subscribed to all notifications, the transaction can generate different application responses. See the table below:
| # | SCICloudStatusCode | SCIResponseCode | Sample |
|---|---|---|---|
| 1 | 100 | IP |
|
| 2 | 101 | IP |
|
| 3 | 200 | AP |
|
| 4 | 207 | AP |
|
| 5 | 209 | AP |
|
| 6 | 401 | RE |
|
| 7 | 500 | RE |
|
To configure notifications for your company or update your current configuration, contact the Professional Services team.
-
GET /notifications/GR -
GET /documents/GR/{documentId}/notifications
- GET/Notifications/GR
- The supplier can send a GET request to the /notifications/GR endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
Name Type Required Default Description taxId string No Include only notifications related to the specified
taxId. This value relates to theCompanyCodeset in the SBDH.Note:If a request doesn't include this parameter, it will return all the notifications related to the country and the
sourceSystemIdparameter.page integer No 1 To specify the page to be returned, enter a value between 1 and 10. perPage integer No 10 To specify the number of results for the returned page, enter a value between 1 and 100.
Important:If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.
sourceSystemId string Yes Include only notifications related to documents that originate from the given source system. This value is related to the SenderSystemIdin the SBDH.includeAckwnowledged boolean No false Enter "true" to specify whether previously acknowledged notifications, within 24 hours of their acknowledgment, must be included in the result. processType string No Enter "0" to include only notifications related to outbound documents. - Request sample
-
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/IT?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \ --header 'Content-Type: application/json' \ --header 'x-correlationId: 057b5a5e-...-9d583b4d121c' - Response sample
-
{ "timestamp": 1633685509314, "status": 200, "success": true, "message": "Notifications Listed", "data": { "pageState": { "page": 1, "perPage": 50, "totalEntries": 1 }, "notifications": [ { "createdDate": 1633681296, "metadata": { "productId": "gr_InvoiceData__1.0", "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf", "erpDocumentId": "321412", "erpSystemId": "UAT101", "processType": "0", "taxId": "08AAACI9260R002", "sciCloudStatusCode": "200", "sciResponseCode": "AP", "sciStatusAction": "NOA", "sciGovtStatusCode": "100" }, "appPrefix": "DLT", "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c", "content": "PEF...NlPg==" } ] } }
- GET /documents/GR/{documentId}/notifications
- The supplier can send a GET request to the /documents/GR/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameter:
Name Type Required Parameter Type Description documentId string Yes Path The ID of the document returned in step 2 - Request sample
-
curl --location --request GET 'https://api-test.sovos.com/v1/documents/IT/{documentId}/notifications?' \ --header 'Content-Type: application/json' \ --header 'x-correlationId: 6d49dcfe-...-44f4e720d70b' - Response sample
-
{ "timestamp": 1633685509314, "status": 200, "success": true, "message": "Notifications Listed", "data": { "pageState": { "page": 1, "perPage": 50, "totalEntries": 1 }, "notifications": [ { "createdDate": 1633681296, "metadata": { "productId": "gr_InvoiceData__1.0", "documentId": "DOCUMENT-ID", "erpDocumentId": "ERP-DOCUMENT-ID", "erpSystemId": "SystemERP", "processType": "0", "taxId": "YOUR-TAXID", "sciCloudStatusCode": "200", "sciResponseCode": "AP", "sciStatusAction": "NOA", "sciGovtStatusCode": "100" }, "appPrefix": "DLT", "notificationId": "a8dc1aa2-...-97a3d5fdb91c", "content": "PEF...NlPg==" } ] } }
Step 9: Supplier marks the application responses as acknowledged
The supplier must process the retrieved application responses and mark them as acknowledged. Send a PUT request to the /notifications/GR endpoint.
To make this request, set the following request body parameters:
| Name | Type | Required | Description |
|---|---|---|---|
| status | string | Yes | Enter "read" |
| notificationId | string | Yes | The ID of the notification that must be marked as acknowledged |
To acknowledge multiple notifications, add multiple notificationId values to a single Indirect Tax API request.
- Request sample
-
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/GR' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer TOKEN' \ --header 'x-correlationId: SET-TO-UNIQUE-VALUE' \ --data-raw '[ { "status": "read", "notificationId": "51341d39-fd3e-4dcf-aea3-a73d73e0de76" } ]' - Response sample
-
{ "timestamp": 1601673284, "status": 200, "success": true, "message": "Notifications acknowledged successfully." }
Step 10: Archiving
You can compliantly archive the XML, the application response, and any graphical representation, such as a PDF, using Sovos' Compliant Archive.
For suppliers integrating with the Sovos solution for Greece for the first time, we recommend the bundled approach, in which archiving is part of the invoice clearance flow. Archiving can also be done separately through an explicit API call that uses another archive. For more information on standalone archiving, see the eArchiving documentation page.
Bundled e-invoice archiving is optional. This means you can use your current solution and include Sovos eArchiving.
Step 11: Supplier sends the invoice to the buyer
For B2B transactions, Greece does not mandate a specific way to distribute invoices to buyers, so it is up to both business parties to decide how they will distribute invoices.
For B2G transactions, Peppol distribution is mandated, and Sovos does this on your behalf.