Sovos.com Contact Support

e-invoicing

Compliance Network Implementation Guide

Germany

E-invoicing in Germany requires specific prerequisites, invoice formats, exchange methods, and validation rules.

Germany's B2B e-invoicing mandate operates on a post-audit model with no government pre-clearance. Trading parties must directly exchange EN 16931-compliant structured formats, with receiving obligations in force since January 2025 and issuing obligations phasing in from 2027. On the Compliance Network platform, Sovos currently supports Germany through Pan-European Public Procurement On-Line (PEPPOL).

Prerequisites

  • Get a valid tax ID.

  • Configure your company under the PEPPOL network.

  • If you use Sovos as your service provider, you must have an outsourcing authorization agreement.

Network architecture

Model

Germany uses the PEPPOL four-corner model.

Sovos as an access point

Corner two for suppliers, corner three for buyers.

Network used

Germany doesn't require a dedicated Compliance Network country network because it reuses the existing cross-country PEPPOL network.

Invoice formats

E-invoices must comply with European Norm (EN) 16931 syntaxes or a mutually agreed-upon format that meets the requirements. Germany supports the invoice, credit note, and self-billing invoice document types.

The supplier and the buyer must decide which accepted format they want to use. If an invoice recipient refuses or is technically unable to accept an invoice, they can't request an alternative invoice from the issuer. So, if the issuer has issued an invoice and made clear efforts to ensure its correct transmission, they have met their Value-Added Tax (VAT) obligations.

The following formats are compliant with EN 16931:

PEPPOL

Formats compatible with PEPPOL:

PEPPOL BIS 3.0

XML file in the PEPPOL Business Interoperability Specification (BIS) Billing 3.0 syntax.

CIUS XRechnung UBL 2.1

XML file in the Universal Business Language (UBL) syntax.

CIUS XRechnung CII

XML file in the Cross-Industry Invoice (CII) syntax.

Note:

The invoice receipt platforms Zentrale Rechnungseingangsplattform (ZRE) and OZG-Rechnungsempfang (OZG-RE) use the PEPPOL network to let suppliers send electronic invoices automatically to the direct federal administration, parts of the indirect federal administration, and participating federal states.

For more information on PEPPOL, see the PEPPOL documentation.

Non-PEPPOL formats

The hybrid ZUGFeRD format, which is a human-readable PDF/A-3 with an embedded XML file in the CII syntax.

Invoice exchange

The supplier and the buyer must agree on their preferred method of invoice exchange. Email, electronic interface, or shared access to a central storage location are all accepted transmission methods.

Validation rules

To get the latest validation rules:

XRechnung

Go to the XStandards Einkauf website and download the latest version of the English summary PDF.

ZUGFeRD

Go to the FERD website and request the latest version of the ZUGFeRD English PDF.

PEPPOL participant identifiers

Sovos supports the following PEPPOL participant identifier schemes:

Scheme ID Name Format
0204 German Electronic Business Address (GEBA) According to the GEBA specification
0088 Global Location Number (GLN) 13 digits
9930 German VAT number "DE" plus nine digits

Available products

  • de_invoice_outbound_1.0

  • de_invoice_inbound_1.0

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.

Send invoice through e-delivery

The following diagram provides a detailed overview of the e-delivery outbound flow for sending an e-invoice:

Germany e-delivery outbound flow

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 includes a Sovos Canonical Invoice (SCI). To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages.

The SBD must include the following key elements:

SCI - invoiceLocal Format - invoice
Node Required Attributes Value
StandardBusinessDocumentHeader.Sender.Identifier Yes Authority="DE" Supplier's tax ID
StandardBusinessDocumentHeader.Receiver.Identifier Yes Authority="DE" Buyer's tax ID
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yes urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion Yes 2.1
StandardBusinessDocumentHeader.DocumentIdentification.Type Yes Invoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Country

Child node Identifier: DE
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 tax ID
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. Use this parameter to determine which notifications the client receives and the attachments they include. If you don't configure SenderSystemId on the client side, the default value is "DefaultSystemERP". For more information, see see this topic.
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: BusinessCategory

Child node Identifier : B2B
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier : ALL-PEPPOLSCI-1.0-INVOICE-1.0 (PEPPOL) or DE-SCI-1.0-INVOICE-1.0 (ZUGFeRD)
StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceName Yes Default

Alternatively, the supplier can use the local format instead of SCI. Use the following values in the SBDH for documents that use the local format:

Name Document type Node Required Plugin
PEPPOL BIS Invoice StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: ALL-PEPPOLBISUBL-3.0-INVOICE-1.0
Credit note
XRechnung CII Invoice StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-CIUS-CII-INVOICE-1.0
Credit note StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-CIUS-CII-INVOICE-1.0
XRechnung UBL Invoice StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-CIUS-UBL-INVOICE-1.0
ZUGFeRD PDF StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-ZUGFERD-2.3-INVOICE-1.0
PDF StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-ZUGFERDEXTENDED-2.3-INVOICE-1.0
PDF StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-ZUGFERDBASIC-2.3-INVOICE-1.0
PDF StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-ZUGFERDMINIMUM-2.3-INVOICE-1.0
PDF StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.InputSchema

Child node Identifier: DE-ZUGFERDBASICWL-2.3-INVOICE-1.0
Note:

Include all the required nodes, as specified in the SBDH schema. If you can't provide the information for a required node not mentioned here, such as the receiver.identifier, leave the node empty but include it in the SBDH.

SBD sample

The following is a sample of the SBD:

CODE 
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
    xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
    xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
    xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice"
    xmlns:svs="http://www.sovos.com/namespaces/sovosDocument">
    <sbd:StandardBusinessDocumentHeader>
        <sbd:HeaderVersion>1.0</sbd:HeaderVersion>
        <sbd:Sender>
            <sbd:Identifier Authority="DE">311819603</sbd:Identifier>
        </sbd:Sender>
        <sbd:Receiver>
            <sbd:Identifier Authority="DE">4015827392012</sbd:Identifier>
        </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>2026-10-01T00:00:00Z</sbd:CreationDateAndTime>
        </sbd:DocumentIdentification>
        <sbd:BusinessScope>
            <sbd:Scope>
                <sbd:Type>Country</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>DE</sbd:Identifier>
            </sbd:Scope>
            <sbd:Scope>
                <sbd:Type>CompanyCode</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>311819603</sbd:Identifier>
            </sbd:Scope>
            <sbd:Scope>
                <sbd:Type>SenderDocumentId</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>DE-SCI2XRCII-SBD-1790854184</sbd:Identifier>
            </sbd:Scope>
            <sbd:Scope>
                <sbd:Type>SenderSystemId</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>ERPSystem</sbd:Identifier>
            </sbd:Scope>
            <sbd:Scope>
                <sbd:Type>ProcessType</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>Outbound</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:Scope>
                <sbd:Type>BusinessCategory</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>B2B</sbd:Identifier>
            </sbd:Scope>
            <sbd:Scope>
                <sbd:Type>Mapping.InputSchema</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>DE-SCI-1.0-INVOICE-1.0</sbd:Identifier>
            </sbd:Scope>
        </sbd:BusinessScope>
    </sbd:StandardBusinessDocumentHeader>
    <svs:SovosDocument>
        <sci:SovosCanonicalInvoice>
            <inv:Invoice>
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
  <cbc:ID>DE-SCI2XRCII-SBD-1790854184</cbc:ID>
  <cbc:IssueDate>2026-10-01</cbc:IssueDate>
  <cbc:DueDate>2026-10-31</cbc:DueDate>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:Note>Test</cbc:Note>
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
  <cbc:BuyerReference>991-33333TEST-33</cbc:BuyerReference>
  <cac:AccountingSupplierParty>
    <cac:Party>
      <cbc:EndpointID schemeID="9930">311819603</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Germany Test Supplier</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Friedrichstrasse 1</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10117</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE311819603</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Germany Test Supplier</cbc:RegistrationName>
        <cbc:CompanyID>311819603</cbc:CompanyID>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>Supplier Contact</cbc:Name>
        <cbc:Telephone>+49 30 1234567</cbc:Telephone>
        <cbc:ElectronicMail>supplier@example.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>
  <cac:AccountingCustomerParty>
    <cac:Party>
      <cbc:EndpointID schemeID="0088">4015827392012</cbc:EndpointID>
      <cac:PartyName>
        <cbc:Name>Germany Test Buyer</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Empfaengerstrasse 2</cbc:StreetName>
        <cbc:CityName>Frankfurt am Main</cbc:CityName>
        <cbc:PostalZone>60311</cbc:PostalZone>
        <cac:Country>
          <cbc:IdentificationCode>DE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE719283272</cbc:CompanyID>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Germany Test Buyer</cbc:RegistrationName>
        <cbc:CompanyID>719283272</cbc:CompanyID>
      </cac:PartyLegalEntity>
      <cac:Contact>
        <cbc:Name>Buyer Contact</cbc:Name>
        <cbc:Telephone>+49 69 7654321</cbc:Telephone>
        <cbc:ElectronicMail>buyer@example.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingCustomerParty>
  <cac:Delivery>
    <cbc:ActualDeliveryDate>2026-10-01</cbc:ActualDeliveryDate>
  </cac:Delivery>
  <cac:PaymentMeans>
    <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
    <cbc:PaymentID>DE-SCI2XRCII-SBD-1790854184</cbc:PaymentID>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE89370400440532013000</cbc:ID>
      <cbc:Name>Germany Test Supplier</cbc:Name>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>
  <cac:PaymentTerms>
    <cbc:Note>#SKONTO#TAGE=14#PROZENT=2.00#
</cbc:Note>
  </cac:PaymentTerms>
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">19.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">100.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">19.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">100.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">119.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">119.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">1</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Name>Test Service</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme>
          <cbc:ID>VAT</cbc:ID>
        </cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>
</inv:Invoice>
        </sci:SovosCanonicalInvoice>
    </svs:SovosDocument>
</StandardBusinessDocument>

Sample documents:

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
JSON 
curl --location --request POST 'https://api-test.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {accessToken}' \
--header 'x-correlationId: {uniqueValue}' \
--data-raw '{
	"data": "PD9...d4=",
	"dataEncoding" : "base64"
}'
Response sample
JSON 
{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "DOCUMENT-ID"
    }
}

Step 3: Sovos maps the document

After receiving the file, Sovos maps the document to the format expected by the buyer.

Note:

Sovos skips this step if the SBD contains the invoice in the local format.

If mapping fails, Sovos returns an error that the supplier sees when retrieving application responses.

Step 4: Sovos validates the document

Sovos performs semantic, syntactic, and legal validations. We also perform a schema validation to ensure the XML file conforms to the expected structure, comparing it with the official schema.

Note:

If the validation fails, Sovos returns an error that the supplier sees when retrieving application responses.

Step 5: Sovos generates and sends the document

Sovos generates the document and sends it to the buyer's PEPPOL Access Point (AP).

Note:

If the buyer doesn't have a registered PEPPOLD AP, Sovos returns an error that the supplier can see when retrieving application responses.

Step 6: Buyer's AP processes the document and sends a response

After receiving the document, the buyer's PEPPOL AP processes and validates the document and makes it available for the buyer to retrieve. The AP also returns a response to Sovos, which creates notifications for the supplier to retrieve.

Step 7: Supplier retrieves the application responses

You can access your attachments:

  • 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:

CODE 
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'

To complete a transaction, the supplier must retrieve application responses until the SCIResponseCode in the response has the value of either IP or RE. These values indicate that the transaction is finished.

SCICloudStatusCode SCIResponseCode StatusReason Description
102 AB Validated by Sender Platform The document was correctly validated in Compliance Network
204 IP Distributed The document was sent to the buyer
401 RE Rejected The document was rejected

The supplier can use the following Indirect Tax API endpoints to retrieve application responses:

GET /notifications/DE

The supplier can send a GET request to the /notifications/DE endpoint to retrieve application responses that match the set search criteria. To make this request, use the following query parameters:

Name Type Required Default Description
taxId string No

Include only notifications related to the specified taxId. This value is related to the CompanyCode set in the SBDH.

Note:

If you don't include this parameter, the request returns all the notifications related to the country and the sourceSystemId parameter.
page integer No 1 To specify the page to return, use a value between 1 and 10.
perPage integer No 10

To specify the number of results for the returned page, use a value between 1 and 100.

Important:

If you configured the attachment file to return 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 SenderSystemId in the SBDH.
includeAcknowledged boolean No false Use "true" to include previously acknowledged notifications, within 24 hours of their acknowledgment, in the result.
processType string No Use "0" to only include notifications related to outbound documents.
Request sample
JSON 
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/DE?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: {uniqueValue}' \
--header 'Authorization: Bearer {accessToken}'
Response sample
JSON 
{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 1790605115727,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 20,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "a8f612ae-...-966c69780571",
                "correlationId": "efe7c5bc-...-836c981fc87a",
                "appPrefix": "CN",
                "metadata": {
                    "productId": "de_invoice_outbound_1.0",
                    "transactionId": "TRANSACTION-ID",
                    "documentId": "DOCUMENT-ID",
                    "erpSystemId": "ERPSystem",
                    "processType": "0",
                    "taxId": "{taxId}",
                    "sciCloudStatusCode": "204",
                    "sciResponseCode": "IP"
                },
                "content": "PD94bW...9uc2U+",
                "createdDate": 1790605097828,
                "orgId": "5be5...bc230"
            },
        ]
    }
}
GET /documents/DE/{documentId}/notifications

The supplier can send a GET request to the /documents/DE/{documentId}/notifications endpoint to retrieve application responses related to a single document.

To make this request, use the following path parameter:

Name Type Required Description
documentId string Yes The document ID returned in step 2
Request sample
JSON 
curl --location --request GET 'https://api-test.sovos.com/v1/documents/DE/{documentId}/notifications?' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {accessToken}' \
--header 'x-correlationId: {uniqueValue}'
Response sample
JSON 
{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 1790605115727,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 20,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "a8f612ae-...-966c69780571",
                "correlationId": "efe7c5bc-...-836c981fc87a",
                "appPrefix": "CN",
                "metadata": {
                    "productId": "de_invoice_outbound_1.0",
                    "transactionId": "TRANSACTION-ID",
                    "documentId": "DOCUMENT-ID",
                    "erpSystemId": "ERPSystem",
                    "processType": "0",
                    "taxId": "{taxId}",
                    "sciCloudStatusCode": "204",
                    "sciResponseCode": "IP"
                },
                "content": "PD94bW...9uc2U+",
                "createdDate": 1790605097828,
                "orgId": "5be5...bc230"
            },
        ]
    }
}

Sample notification responses:

Step 8: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. To do that, send a PUT request to the /notifications/DE endpoint.

To make this request, use the following request body parameters:

Name Type Required Description
status string Yes Use "read"
notificationId string Yes The notification ID
Note:

You can acknowledge multiple notificationId values in a single Indirect Tax API request.

Request sample
JSON 
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/DE' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {accessToken}' \
--header 'x-correlationId: {uniqueValue}' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-...-a73d73e0de76"
    }
]'
Response sample
JSON 
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Receive invoice through e-delivery

The following diagram provides a detailed overview of the e-delivery inbound flow for receiving an e-invoice:

Germany e-delivery inbound flow

Step 1: Sovos receives the document

Sovos receives the document from the supplier's ERROR - unresolved reference (PEPPOL) Access Point (AP).

Step 2: Sovos validates the document

Sovos performs semantic, syntactic, and legal validations.

Step 3: Sovos sends a status response

Sovos sends a status response to the supplier's AP.

Step 4: Sovos maps the document

Sovos maps the document from the received format to the buyer's format.

Note:

Sovos skips this step if the buyer and the supplier use the same format.

Step 5: Sovos generates a response

Sovos generates an application response that includes the document.

Step 6: Buyer retrieves the application responses

You can access your attachments:

  • 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:

CODE 
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'

To complete a transaction, the buyer must retrieve all application responses until the transaction has finished. If the buyer has subscribed to all notifications, one transaction can generate different application responses.

SCICloudStatusCode SCIResponseCode StatusReason Description
215 AP Made available The buyer receives the document

The buyer can use the GET /notifications/DE endpoint to retrieve application responses. This endpoint lets you use the following query parameters:

Name Type Required Default Description
taxId string No Include only notifications related to the specified taxId.
page integer No 1 To specify the page to return, use a value between 1 and 10.
perPage integer No 10 To specify the number of results for the returned page, use a value between 1 and 100.
Important:

If you configured the attachment file to return 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.
includeAcknowledged boolean No false Use true to include previously acknowledged notifications in the result.
processType string No Use 1 to only include notifications related to inbound documents.
orgId string No Restricts the notifications listed to documents associated with the given organization ID (only applicable for workspace tenants).
senderDocumentId string No Restricts the notifications listed to the given sender document ID if you used the SenderDocumentId scope in the POST /v1/documents endpoint.
Request sample
JSON 
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/DE?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=1' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: {uniqueValue}' \
--header 'Authorization: Bearer {accessToken}'
Response sample
JSON 
{
  "status": 200,
  "message": "Notifications Listed",
  "success": true,
  "timestamp": 1693343820329,
  "data": {
    "pageState": {
      "page": 1,
      "perPage": 10,
      "totalEntries": 4,
      "totalPages": 1
    },
    "notifications": [
      {
        "notificationId": "202603100...ad43-d0edf3e48807",
        "correlationId": "rrt-...-1335030-1",
        "metadata": {
          "productId": "aa_edelivery__1.0",
          "documentId": "569d7232-...-568dd061b613",
          "erpDocumentId": "212093...2025",
          "erpSystemId": "BRADYBEUAT",
          "processType": "0",
          "taxId": "0405007662",
          "sciCloudStatusCode": "100",
          "sciResponseCode": "AP",
          "sciStatusAction": "NOA"
        },
        "content": "PD94...Pz4",
        "createdDate": 1693339001904
      }
    ]
  }
}

Sample notification response:

Step 7: Buyer acknowledges the application responses

After retrieving the application responses, the buyer must process them and mark them as acknowledged. To do this, send a PUT request to the /notifications/DE endpoint.

To make this request, use the following parameters:

Name Type Required Parameter type Description
countryCode string Yes Path The two-character country code specified by the ISO 3166-1 alpha-2 standard
status string Yes Request body Use "read"
notificationId string Yes Request body The notification ID
Tip:

You can acknowledge multiple notificationId values in a single Indirect Tax API request.

Request sample
JSON 
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/DE' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: {uniqueValue}' \
--header 'Authorization: Bearer {accessToken}' \
--data '[
    {
        "status": "read",
        "notificationId": "55f26671-...-d42925946ebf"
    }
]'
Response sample
JSON 
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1653424820578,
    "data": {}
}
Germany Compliance Network

Last updated: October 7, 2026