France

To enable support for France, you'll need to confirm prerequisites and product IDs, configure endpoints and networks, and review the supported use cases and French regulatory requirements.

Prerequisites

A valid SIREN number.
A valid SIRET number per establishment, for companies with multiple establishments

Available products

ERROR - unresolved reference (fr_invoice_outbound_1.0)
ERROR - unresolved reference (fr_invoice_inbound_1.0)
ERROR - unresolved reference (fr_Report__1.0)

Supported use cases

Sovos supports the following use cases in France.


Number #	Category	Use Case
1	Multi-order / Multi-delivery	Multi-order / Multi-delivery
2	Invoice already paid by a third party or the buyer	Invoice already paid by the purchaser or a third party designated for invoicing at the time of invoicing when the invoice is issued
3	Bill to be paid by a third party	Invoice to be paid by a third party designated at the time of invoicing
4	Bill to be paid by a third party	Invoice to be paid by the purchaser and partially paid by a third party known when invoiced (subsidy, insurance, ... )
8	Invoice payable to a third party	Invoice payable to a third party determined at the time of invoicing (factoring, cash pooling)
9	Invoice payable to a third party	Invoice to be paid to a third party known at the time of invoicing, who also manages the ordering/receiving and invoicing (Distributor/Depositary)
11	Invoice with "addressee" other than buyer	Invoice with "Addressed to" (INVOICEE) different from the buyer (BUYER)
17a	Invoice issued by a third party, payment intermediary	Invoice payable to a third-party payment intermediary (for example on Marketplace)
17b	Invoice issued by a third party, payment intermediary and billing mandate	Invoice payable to a third party, payment intermediary and invoicing mandate
19a	Invoices issued by mandated third parties	Invoice issued with a billing mandate
20	Advance Invoice (pre-paid)	Down-payment invoice and final invoice after down-payment
21	Advance Invoice (pre-paid)	Down-payment invoice and final invoice after down-payment

Supported document types

Sovos supports the following document types in France.

SCI format

Sovos Canonical Invoice is our format created specifically to assist global clients with their e-invoicing and reporting needs. The main objective of SCI is to ease the complexity and burden when mapping data into the required local format.

Regulated formats

User and platform interactions are standardized across technical formats to ensure the tax authority can accurately process the data. The French tax authority uses a core set of formats based on global standards, adapted for France.


Format	Description
UBL (Universal Business Language) EN16931 France CIUS	The exchange standard for this format is promoted by OASIS (the Organization for the Advancement of Structured Information Standards) in the form of standard Universal Business Language version 2.1.
Factur-X (PDF A/3) (non-XML)	A Franco-German standard for hybrid e-invoice (PDF for users and XML data for process automation), the first implementation of the European Semantic Standard EN 16931 was published by the European Commission on October 16th, 2017.
CII UN/CEFACT EN16931 France CIUS	The exchange standard adopted for this format is promoted by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) in the form of the Core Component Technical Specification (CCTS) version 3.0.
CDAR	UN/CEFACT SCRDM CI Cross Domain Application Response message.

Supported documents


Code	Description
380	Commercial invoice
381	Credit note
384	Correcting invoice
386	Prepayment invoice

Custom formats

You can use custom formats when you cannot generate the platform's native formats, such as the regulated formats for each mandate and the SCI. To use tailor-made data mappings, contact your Sovos representative.

Available configuration formats

Based on the supported document types. We have defined the following formats

FR-SCI-1.0-INVOICE-1.0
FR-CIUSUBL-1.0-INVOICE-1.0
FR-FACTURX-1.06-INVOICE-1.0
FR-CIUSCII-1.0-INVOICE-1.0
FR-CDAR-3.0-LIFECYCLE-1.0

Manage lifecycle

Learn which status messages are mandatory throughout an invoice's lifecycle, understand AFNOR's technical format specifications, and discover how to implement compliant lifecycle management.

Core principles of the invoice lifecycle

Tracking and updating an invoice's status throughout its lifecycle ensures transparency and supports reform goals. Proper status documentation lets buyers and suppliers monitor the progress of invoice processing - such as submission, availability, validation, and payment.

Note:

Because only "internal" scenarios are available, lifecycle updates are shared exclusively between the supplier and buyer. We will provide more details on how the Tax Authority (TA) processes lifecycle statuses once their procedures are finalized.

The invoice lifecycle must meet four key requirements:

Provide a shared view of invoice processing for issuers, recipients, and the tax authority
Define a standardized list of statuses and exchange formats to ensure interoperability between companies, registered private platforms, and the public invoicing portal
Establish clear processes for handling invoice rejections and cancellations
Support the pre-filling of VAT declaration forms

The invoice lifecycle consists of two main categories:

Mandatory statuses required by the Tax Authority
Common statuses shared across all invoicing stakeholders, which might be mandatory or optional

Status management

Note:

The submission of multiple lifecycles is not supported.

Status processing diagram

Lifecycle status definitions and procedures


Legal Status Code	Legal Status Name	Platform Code	Platform Name	Change of status	Trigger	Producer	Forwarding To
200	Submitted	102	Validated by sender platform	Automatic	The supplier submits its invoice or credit note to the registered private platform. The status is generated after the controls are performed.	Supplier's platform PDPE (Issuer)	Supplier
201	Issued by the platform	204	Sent by the platform	Automatic	The invoice has been processed on the supplier's platform and issued to the buyer.	Supplier's platform PDPE (Issuer)	Supplier
202	Received by the platform	214	Validated by recipient platform	Automatic	The invoice has been received by the buyer's registered private platform but has not yet been made available to the buyer.	Buyer's platform PDPR (Receiver)	Supplier
203	Made available	215	Made available	Automatic	The invoice has been made available to the buyer on the registered private platform.	Buyer's platform PDPR (Receiver)	Supplier
204	In hand	216	Received	Manual	The invoice is assumed by the buyer for processing.>	Buyer	Supplier
205	Approved	203	Approved	Manual	The invoice is accepted in its entirety by the buyer.	Buyer	Supplier
206	Partially approved	217	Partially approved	Manual	The invoice is partially accepted by the buyer. This partial processing may give rise to a credit note.	Buyer	Supplier
207	Disputed	218	Disputed	Manual	There is a dispute regarding the invoice. This may ultimately lead to refusal or approval by the buyer.	Buyer	Supplier
208	Suspended	219	Suspended	Manual	Invoice processing may be suspended when one or more supporting documents are missing. The invoice data remains unchanged.	Buyer	Supplier
209	Completed	206	Completed	Manual	The invoice is completed when the supplier adds an attachment or comment to an invoice with a status of "suspended".	Supplier	Buyer
210	Refused	405	Refused	Manual	The invoice has been refused by the recipient for business reasons A complete list of reasons for refusal is available in the document "Annex 1 - Semantic Format FE e-invoicing - Flows 1 & 2" on the "Reason for refusal" tab.	Buyer	Supplier
211	Payment sent	213	Payment sent	Manual	The bank transfer flow has been sent to the supplier. The reimbursement flow has been sent to the buyer.	Buyer	Supplier
212	Payment received	220	Payment received	Manual	The supplier has received payment of the invoice. This status is mandatory for supply of services (except VAT on debits and excluding reverse charge transactions).	Supplier	Buyer
213	Rejected	401	Rejected	Automatic	The invoice can be automatically rejected by the platform on technical grounds (e.g. format, non-compliance with the standard, ...) When the transmit platform rejects the invoice, the invoice must be corrected by its issuer and resubmitted to the platform. When the receive platform rejects the invoice, the Rejected status is transmitted to the transmit platform (see 2.12.1.3 Invoice management in the event of inadmissibility, rejection or refusal).	Supplier or Buyer platform	Supplier or Buyer

Validate documents

Sovos validates French e-invoicing documents against technical and mandate-specific standards. Learn how inadmissibility, rejection, and refusal work, and understand the validation rules that ensure compliance with External Specifications requirements.

The French mandate establishes rules for rejection, refusal, and inadmissibility to enhance user comprehension and make it easier to fix any issues. If a document is not accepted, Sovos' role as a PDP is to identify the concerned item, along with the reasons for that action.

These reasons allow issuers to:

Understand the reasons for the rejection of a document.
Take corrective action for issuing a revised document.

These are the concepts behind each validation

Inadmissibility: The platform cannot receive or process the flow or its content due to a virus, an empty or unusable file, or a non-verifiable signature. A file might be unusable because it has an unexpected format, is not compressed correctly, or some other reason. The supplier's or recipient's platform establishes inadmissibility, which relates solely to the flow.
Rejection: Both the supplier's and recipient's platform detect anomalies during functional checks. These anomalies might include issues with semantic format, data consistency, uniqueness, or other properties. Either side can reject an invoice, but when the recipient rejects it, their platform sends a Lifecycle flow to inform the sender.
Refusal: When the recipient refuses an invoice, their platform sends a Lifecycle flow to the issuer's platform to inform them of the refusal and the reason. For example, a recipient might refuse an invoice if they are not the correct recipient. The list of valid refusal reasons follows the mandate v2.4 specifications.

High-level validations

Sovos performs the following high-level validations on transmitted data messages:

Technical: Validate that the document's format fulfills all the requirements, for example, schema validation.
Mandate: Validate that the document fulfills all the region and country-specific requirements where the document is issued.

Mandate-specific validations

Sovos as a PDP validates all documents against the French mandate's standards and specifications, defined in Annex 7 of External Specifications 2.4.

Note:

Expect changes to the validation rules as the AFNOR commission is still working on a stable version.

The following table lists the reasons for rejection according to each validation type:


Validation type	Validation	Failure consequence	Explanation
Application Controls	Syntactic format analysis	The document is rejected.	The document issued does not comply with the expected format. The wrong data item name is specified, if applicable.
Functional Controls	Semantic format analysis (standards and specifications)	The document is rejected.	The document issued does not comply with the standards or specifications. The data item or data group that infringes the rule is shown, along with the infringed rule.
	Uniqueness validation: Supplier's Invoice number Supplier's ID (the company's SIREN or SIRET registration number), if indicated (see BT-29 and BT-30 from the EN16931 standard) Invoice year	The document is rejected.	The issued document has already been received, but it does not comply with the uniqueness validation rules.
	Invoice addressing validation: Note: Not applicable currently The recipient exists in the directory when the invoice is submitted The receiving platform ensures the recipient is a customer	The document is refused by the recipient (incorrect routing).	The recipient validates that they are the intended recipient of the document. The document issuer ensures that the recipient's data is properly qualified (routing data present in the directory).
		Sovos rejects the invoice during transmission (unknown recipient).

Trading partners

Learn how to manage endpoints for trading partners in your workspace.

Use Compliance Network to manage communication network endpoints for trading partners of the companies in your organization.

Add trading partner endpoint

Note: This feature is only available to workspace administrators.

A network should already exist.

Go to Network.
Click on a "non-workspace" Network to manage.
Click on New endpoint.
Enter required information:
1. Enter a user friendly Name for your endpoint.
2. Enter the SIREN number.
3. Enter the SIRET number when registering a company branch.
4. Enter the Code Routage to identify a specific department in your organization.
5. Enter the Suffix identifier to create a virtual location for grouping your documents.
6. Enter the Matricule Plateforme value to identify the PDP that handles the delivery.
Configure Invoices:
1. Select Invoices.
2. Click on Add Subtype.
3. Select all that apply.
4. Click Save.
5. Select a distribution method, either push or pull.
6. Select a plugin.
Configure Lifecycles:
1. Select Lifecycles.
2. Click on Add Subtype
3. Select all that apply.
4. Click Save.
5. Select a distribution method, either push or pull.
6. Select a plugin.
Click Save.

Edit trading partner endpoint

Note: This feature is only available to workspace administrators.

Go to Network.
Click on a "non-workspace" Network to manage.
Click on an endpoint to manage.
Click Edit.
Update Invoices:
1. Select Invoices.
2. Add new or remove existing subtypes.
3. Update the distribution method..
4. Select a new plugin.
Update Lifecycles:
1. Select Lifecycles.
2. Add new or remove existing subtypes.
3. Update the distribution method.
4. Select a new plugin.
Click Save.

Add trading partner endpoint with Indirect Tax API

Learn how to add endpoints assigned to the workspace in Compliance Network using Indirect Tax API.

Note: This feature is only available to workspace administrators.

A network should already be available for configuration.

Send a POST request to the endpoint URL

POST https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Include the following parameters inside the JSON payload in the request body


Name			Type	Required	Description
codeComponents			array	Yes (at least one)	Business identification codes
	field		string	Yes	SIREN or SIRET
	value		string	Yes	SIREN or SIRET value
supportedDocuments			array	Yes (at least one)	Document types and configurations
	type		string	Yes	Invoice or Lifecycle
	subTypes		array	Yes	Varies by type. For Invoice Invoice CreditNote For Lifecycle Lifecycle
	communication		object	Only in certain cases	Communication settings
		distributionMethod	string	Yes	"Pull" (API) or "Push" (IaaS) integration
		formatId	string	Yes	Format specification; See available formats for specific values
tradingPartner			object	Yes	Trading partner info
	name		string	Yes	Trading partner name
	businessIdentifiers		array	Yes	Array of business identifiable info items
		type	string	Yes	TaxId
		value	string	Yes	SIREN or SIRET
		name	string	Yes	Company Name
		countryCode	string	Yes	FR

Upon successful creation, the API will return a JSON object containing status info.

Samples for adding a trading partner

Request sample

Request sample for adding a trading partner

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw ' {
   "codeComponents":[
      {
         "field": SIREN / SIRET,
         "value": SIREN-OR-SIRET-VALUE
      }
   ],
   "supportedDocuments":[
      {
         "type": SIREN / SIRET,
         "subTypes": [
            "Invoice",
            "CreditNote"
         ],
         "communication": {
            "distributionMethod": Push / Pull,
            "formatId": AVAILABLE-FORMAT-NAME
         }
      }
   ],
   "tradingPartner": {
      "name": "Trading Partner Name",
      "businessIdentifiers": [
         {
            "type": "TaxId",
            "value": SIREN / SIRET,
            "name": "Company Name",
            "countryCode": "FR"
         }
      ]
   }
}'

Response sample

Response sample for adding a trading partner

{
   "status": 201,
   "message": "Created",
   "success": true,
   "timestamp": 1741968114340,
   "data":{
      "id": "f728171e-…-37bc12d9fa8c",
      "code": {
         "value": "123456789_12345678954321",
         "scheme": "0225"
      }
   }
}

Edit trading partner endpoint with Indirect Tax API

Learn how to update endpoints assigned to the workspace in Compliance Network using Indirect Tax API.

Note: This feature is only available to workspace administrators.

The endpoint should already exist.

Send a PUT request to the endpoint URL

PUT https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Include the following parameters inside the JSON payload in the request body


Name			Type	Required	Description
supportedDocuments			array	Yes (at least one)	Document types and configurations
	type		string	Yes	Invoice or Lifecycle
	subTypes		array	Yes	Varies by type. For Invoice Invoice CreditNote For Lifecycle Lifecycle
	communication		object	Only in certain cases	Communication settings
		distributionMethod	string	Yes	"Pull" (API) or "Push" (IaaS) integration
		formatId	string	Yes	Format specification; See available formats for specific values
tradingPartner			object	Yes	Trading partner info
	name		string	Yes	Trading partner name
	businessIdentifiers		array	Yes	Array of business identifiable info items
		type	string	Yes	TaxId
		value	string	Yes	SIREN or SIRET
		name	string	Yes	Company Name
		countryCode	string	Yes	FR

Upon successful update, the API will return a JSON object containing status info.

Samples for updating a trading partner

Request sample

Request sample for updating a trading partner

curl --location --request PUT 'https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw ' {
   "supportedDocuments":[
      {
         "type": SIREN / SIRET,
         "subTypes": [
            "Invoice",
            "CreditNote"
         ],
         "communication": {
            "distributionMethod": Push / Pull,
            "formatId": AVAILABLE-FORMAT-NAME
         }
      }
   ],
   "tradingPartner": {
      "name": "Trading Partner Name",
      "businessIdentifiers": [
         {
            "type": "TaxId",
            "value": SIREN / SIRET,
            "name": "Company Name",
            "countryCode": "FR"
         }
      ]
   }
}'

Response sample

Response sample for updating a trading partner

{
   "status":200,
   "message":"OK",
   "success":true,
   "timestamp":1741968114344
}

Get a trading partner endpoint with Indirect Tax API

Learn how to fetch partner endpoints assigned to a workspace in Compliance Network using Indirect Tax API.

Note: This feature is only available to workspace administrators.

The endpoint should already exist.

Send a GET request to the endpoint URL

GET https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Upon successful update, the API will return a JSON object containing the endpoint configuration.

Samples for fetching a trading partner

Request sample

Request sample for fetching a trading partner

curl --location --request GET 'https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json'

Response sample

Response sample for fetching a trading partner

{
   "status":200,
   "message":"OK",
   "success":true,
   "timestamp":1741968114349,
   "data":{
      "id":"7f176e1f-…-d447dc499306",
      "code":{
         "value":"999999999",
         "scheme":"0225",
         "components":[
            {
               "field":"SIREN",
               "value":"999999999"
            }
         ]
      },
      "validityPeriod":{
         "start":"2026-09-01T00:00:00.0000000Z",
         "end":"2029-09-01T00:00:00.0000000Z"
      },
      "supportedDocuments":[
         {
            "type":"Invoice",
            "subTypes":[
               "Invoice",
               "CreditNote"
            ],
            "communication":{
               "distributionMethod":"Push",
               "formatId":" FR-CIUSCII-1.0-INVOICE-1.0"
            }
         },
         {
            "type":"LifeCycles",
            "subTypes":[
               "LifeCycles"
            ],
            "communication":{
               "distributionMethod":"Push",
               "formatId":"FR-CDAR-3.0-LIFECYCLE-1.0"
            }
         }
      ],
      "tradingPartner":{
         "name":"Trading Partner Name",
         "businessIdentifiers":[
            {
               "type":"TaxId",
               "value":"999999999",
               "name":"Company Name",
               "countryCode":"FR"
            },
            {
               "type":"Gln",
               "value":"1234578912345789",
               "name":"Company Name",
               "countryCode":"FR"
            }
         ]
      }
   }
}

Delete a trading partner endpoint with Indirect Tax API

Learn how to delete partner endpoints assigned to a workspace in Compliance Network using Indirect Tax API.

Note: This feature is only available to workspace administrators.

The endpoint should already exist.

Send a DELETE request to the endpoint URL

DELETE https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Upon successful removal, the API will return a JSON object containing status info.

Samples for removing a trading partner

Request sample

Request sample for fetching a trading partner

curl --location --request DELETE 'https://api-test.sovos.com/v2/configurations/workspaces/networks/{networkId}/trading-partners/endpoints/{endpointId}' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json'

Response sample

Response sample for fetching a trading partner

{
   "status":200,
   "message":"OK",
   "success":true,
   "timestamp":1741968114352,
   "data":{}
}

Inbound company

Learn how to configure an inbound company in Compliance Network to receive notifications with supported formats for Invoices attached.

A company should already be available for configuration.

In this scenario, we will configure the company to receive notifications (UBL Application Response) with one of the supported formats for Invoices attached and to receive these notifications.

Click the Settings icon.
Select Companies from the menu.
All available companies will be listed.
Pick the inbound company to configure and open the details screen.
Click on the Settings icon.
Select Network Settings from the menu.
Click on New Endpoint.
Select the appropriate inbound product.
Enter the required information:
1. Enter the SIREN number.
2. Enter the SIRET number when registering a company branch
3. Enter the Code Routage to identify a specific department in your organization.
4. Enter the Suffix identifier to create a virtual location for grouping your documents.
5. Select validity period start date.
6. Select validity period end date.
7. Select an ERP system id.
Configure Invoices:
1. Select Invoices.
2. Click on Add Subtype
3. Select all that apply.
  Must select at least one.
4. Click Save.
Click Create.

The configured company will now receive notifications via API when documents become available.

Edit inbound company configuration

Learn how to update an endpoint configuration for an inbound company in Compliance Network.

Note: This feature is only available to workspace administrators.

A configuration should already be available for update.

Click the Settings icon.
Select Companies from the menu.
All available companies will be listed.
Pick the company to edit and click on the Settings icon.
Select Network Settings from the menu.
Click the More options icon from the endpoint.
Select Edit from the menu.
Update the endpoint information.
Click Save.

The company has an updated configuration.

Configure inbound company with Indirect Tax API

Learn how to configure a company to receive notifications in Compliance Network using Indirect Tax API.

A company should already be available for configuration.

Send a POST request to the endpoint URL

POST https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Include the following parameters inside the JSON payload in the request body


Name		Type	Required	Description
productId		string	Yes	fr_invoice_inbound_1.0
validityPeriod		object	Yes	Period during which the configuration is valid
	start	string (ISO 8601)	Yes	Configuration start date
	end	string (ISO 8601)	Yes	Configuration end date
codeComponents		array	Yes (at least one)	Business identification codes
	field	string	Yes	SIREN or SIRET
	value	string	Yes	SIREN or SIRET value
supportedDocuments		array	Yes (at least one)	Document types and configurations
	type	string	Yes	Invoice or Lifecycle
	subTypes	string	Yes	Varies by type. For Invoice Invoice CreditNote For Lifecycle Lifecycle
erpSystemId		string	Yes	The system ID configured in the backend.

Upon successful creation, the API will return a JSON object containing status info.

Sample for configuring an inbound company

Request sample

Request sample for configuring an inbound company endpoint

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
   "productId": "fr_invoice_inbound_1.0",
   "validityPeriod":{
      "start": "2026-09-01T00:00:00.0000000Z",
      "end":" 2029-09-01T00:00:00.0000000Z"
   },
   "codeComponents":[
      {
         "field": SIREN / SIRET,
         "value": SIREN-OR-SIRET-VALUE
      },
      {
         "field": SIREN / SIRET,
         "value": SIREN-OR-SIRET-VALUE
      }
   ],
   "supportedDocuments": [
      {
         "type": "Invoice",
         "subTypes": [
            "Invoice",
            "CreditNote"
         ]
      },
      {
         "type": "Lifecycle",
         "subTypes": [
            "Lifecycle"
         ]
      }
   ],
   "erpSystemId": "ERPTest_Inbound"
}'

Response sample

Response sample for configuring an inbound company endpoint

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1752140016103,
    "data": {
        "id": "345cef18-ae70-….-bd4c-d2c2795bfbbe",
        "code": {
            "value": "123456789_12345678954321",
            "scheme": "0225"
        },
        "registeredDirectories": ["Jurisdiction", "Peppol"]
    }
}

Sample for updating an inbound company configuration

Request sample

Request sample for updating the configuration of an inbound company endpoint

curl --location --request PUT 'https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints/{endpointId}' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
   "validityPeriod":{
      "start": "2026-09-01T00:00:00.0000000Z",
      "end":" 2029-09-01T00:00:00.0000000Z"
   },
   "supportedDocuments": [
      {
         "type": "Invoice",
         "subTypes": [
            "Invoice",
            "CreditNote"
         ]
      },
      {
         "type": "Lifecycle",
         "subTypes": [
            "Lifecycle"
         ]
      }
   ],
   "erpSystemId": "ERPTest_Inbound"
}'

Response sample

Response sample for updating the configuration of an inbound company endpoint

{
   "status":200,
   "message":"OK",
   "success":true,
   "timestamp":1741968114435
}

Outbound company

Learn how to configure an outbound company in Compliance Network.

A company should already be available for configuration.

In this scenario, we will configure the company to receive notifications (UBL Application Response) with the legal CDAR format for Lifecycles attached.

Click the Settings icon.
Select Companies from the menu.
All available companies will be listed.
Pick the inbound company to configure and open the details screen.
Click on the Settings icon.
Select Network Settings from the menu.
Click on New Endpoint.
Select the appropriate outbound product.
Enter the required information:
1. Enter the SIREN number.
2. Enter the SIRET number when registering a company branch.
3. Enter the Code Routage to identify a specific department in your organization.
4. Enter Suffix identifier to create a virtual location for grouping your documents.
5. Select validity period start date.
6. Select validity period end date.
7. Select an ERP system id.
Configure Lifecycles:
1. Click on Add Subtype
2. Select Lifecycle.
3. Click Save.
Click Create.

The configured company will now receive notifications via API when submitting documents.

Edit outbound company configuration

Learn how to update an endpoint configuration for an outbound company in Compliance Network.

Note: This feature is only available to workspace administrators.

A configuration should already be available for update.

Click the Settings icon.
Select Companies from the menu.
All available companies will be listed.
Pick the company to edit and click on the Settings icon.
Select Network Settings from the menu.
Click the More options icon from the endpoint.
Select Edit from the menu.
Update the endpoint information.
Click Save.

The company has an updated configuration.

Configure outbound company with Indirect Tax API

Learn how to configure a company to receive notifications in Compliance Network using Indirect Tax API.

A company should already be available for configuration.

Send a POST request to the endpoint URL

POST https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints

Include the following headers in your request
- Authorization: Bearer {accessToken}
- Content-Type: application/json
- x-correlationId: {uniqueValue}

Include the following parameters inside the JSON payload in the request body


Name		Type	Required	Description
productId		string	Yes	fr_invoice_outbound_1.0
validityPeriod		object	Yes	Period during which the configuration is valid
	start	string (ISO 8601)	Yes	Configuration start date
	end	string (ISO 8601)	Yes	Configuration end date
codeComponents		array	Yes (at least one)	Business identification codes
	field	string	Yes	SIREN or SIRET
	value	string	Yes	SIREN or SIRET value
supportedDocuments		array	Yes (at least one)	Document types and configurations
	type	string	Yes	Invoice or Lifecycle
	subTypes	string	Yes	Varies by type. For Invoice Invoice CreditNote For Lifecycle Lifecycle
erpSystemId		string	Yes	The system ID configured in the backend.

Upon successful creation, the API will return a JSON object containing status info.

Sample for configuring an outbound company

Request sample

Request sample for uploading configuring an inbound company endpoint

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
   "productId": "fr_invoice_outbound_1.0",
   "validityPeriod":{
      "start": "2026-09-01T00:00:00.0000000Z",
      "end":" 2029-09-01T00:00:00.0000000Z"
   },
   "codeComponents":[
      {
         "field": SIREN / SIRET,
         "value": SIREN-OR-SIRET-VALUE
      }
   ],
   "supportedDocuments": [
      {
         "type": "Lifecycle",
         "subTypes": [
            "Lifecycle"
         ]
      }
   ],
   "erpSystemId": "ERPTest_Outbound"
}'

Response sample

Response sample for uploading configuring an inbound company endpoint

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1752140016103,
    "data": {
        "id": "345cef18-ae70-….-bd4c-d2c2795bfbbe",
        "code": {
            "value": "123456789_12345678954321",
            "scheme": "0225"
        },
        "registeredDirectories": ["Peppol"]
    }
}

Sample for updating an outbound company configuration

Request sample

Request sample for updating the configuration of an outbound company endpoint

curl --location --request PUT 'https://api-test.sovos.com/v2/configurations/workspaces/organizations/{orgId}/companies/{companyId}/endpoints/{endpointId}' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
   "validityPeriod":{
      "start": "2026-09-01T00:00:00.0000000Z",
      "end":" 2029-09-01T00:00:00.0000000Z"
   },
   "supportedDocuments": [
      {
         "type": "Lifecycle",
         "subTypes": [
            "Lifecycle"
         ]
      }
   ],
   "erpSystemId": "ERPTest_Outbound"
}'

Response sample

Response sample for updating the configuration of an outbound company endpoint

{
   "status":200,
   "message":"OK",
   "success":true,
   "timestamp":1741968114435
}

French mandate inbound e-invoicing

An overview of the inbound e-invoicing workflow for the French mandate to help developers integrate their applications with the Indirect Tax API.

The diagram below provides a detailed flow on how to retrieve an invoice in France: France invoice retrieve invoice flow

Step 1: Sovos receives the documents from PDP

Sovos receives documents from the Supplier's PDP.

Note:

Currently this reception can only be carried out internally within CN, not involving the tax authority.

Step 2: Sovos processes document

Upon receiving the document, Sovos will validate the document based on mandate specifications.

Note:

If the document comes from an internal sender, this step is not applied.

A notification with an application response is issued with some of the following values:

Received by the platform (202) CDAR lifecycle
Maide available (203) CDAR lifecycle
Rejected 'on receipt' (213) CDAR lifecycle (Only if a manual submission is made on the UI)

Step 3: Sovos makes the documents available

Sovos makes the documents available to the buyers after transforming them into the format configured by the recipient. This generates a notification with an application response containing the inbound document.

Note:

Currently this transmission can only be carried out internally within CN, not involving the tax authority.

Step 4: Buyer sends SBD with Lifecycle CDAR to Sovos

Lifecycle documents in CDAR format can be submitted to change the status of the Invoice.

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	Set it to the SBD encoded in Base64, with the scope Mapping.InputSchema having the value "FR-CDAR-3.0-LIFECYCLE-1.0".
dataEncoding	string	Yes	Always set it to "base64".

Step 5: Buyer retrieves application response

The application responses provide the inbound document in the configured format, and encoded in base64.

Note:

If applicable the buyer can also receive status information with the legal lifecycle format CDAR.

Transmission Message: It maps to the SCIGovtStatusCode and StatusReason elements in the response message, as described in the application responses section, which details any warnings or additional notes to consider. For each transaction, application responses must be retrieved based on the Invoice lifecycle specified under the French mandate.

To retrieve the application responses, the supplier can use GET /v1/notifications/FR

GET /notifications/FR

The supplier can send a GET request to the /notifications/FR endpoint to retrieve application responses that match the set search criteria. This endpoint allows setting the following query parameters:


Name	Type	Required	Default	Description
taxId	string	No		Set it to include only notifications related to the specified taxId. Note: This parameter is required for Sovos' direct customers, and optional for hub partners.
page	integer	No	1	To specify the page to be returned, set the value between 1 and 10.
perPage	integer	No	10	To specify the number of results for the returned page, set its value between 1 and 100. Important: If the attachment file is configured to return the binary content, instead of a link, it's recommended to use only values between 1 and 10.
sourcesystemId	string	Yes		Set it to include only notifications related to documents that originate from the given source system.
includeAcknowledged	boolean	No	false	Set it to "true" to specify whether previously acknowledged notifications must be included in the result.
processType	string	No		Set it to "1" to only include notifications related to inbound documents.

Request Sample

curl --location --request GET 'https://api-test.sovos.com/v1/notifications/FR?processType=1&sourceSystemId=YOUR-SYSTEM&taxId=YOUR-TAXID' \
--header 'x-correlationId: developer-guide'

Response Sample

{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 0,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 10,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "ba056226-...-a111e24acd51",
                "correlationId": "49a75544-...-5f672c2a814d",
                "appPrefix": "DLT",
                "metadata": {
                    "productId": "fr_invoice_inbound_1.0",
                    "transactionId": "47514154-...-77a72ab75731",
                    "documentId": "04c...151",
                    "erpDocumentId": "YOUR-DOCUMENT-ID",
                    "erpSystemId": "YOUR-SYSTEMERP",
                    "processType": "1",
                    "taxId": "YOUR-TAXID",
                    "sciCloudStatusCode": "215"
                },
                "content": "PD...T4=",
                "createdDate": 1674572920
            }
        ]
    }
}

Step 6: Supplier marks application response as acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/FR endpoint.

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


Name	Type	Required	Description
status	string	Yes	Set it to read.
notificationId	string	Yes	Set it to the ID of the notification that must be marked as acknowledged.

Note:

Multiple notificationId values can be acknowledged using one Indirect Tax API call by including them in a single request.

Request Sample

curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/IT' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: developer-guide' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-...-a73d73e0de76"
    }
]'

Response Sample

{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

In general, all error codes in the 400 range are client errors, so the customer needs to analyze them. After fixing the error, it's possible to resend the request. Error codes 408 and 429 are exceptions: in these cases, customers should wait at least 60 seconds before retrying. The error codes in the 500 range are server errors. In that case, customers need to resend the request, according to the instructions given on the responses page, which also includes a full list of error codes the Indirect Tax API can return.

French mandate outbound e-invoicing

An overview of the outbound e-invoicing workflow for the French mandate to help developers integrating their applications with the Indirect Tax API.

The flow to issue an invoice in France is based on the Default business process. The following diagrams provide a detailed overview of the workflow.

France issue invoice 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 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.

The Standard Business Document Header (SBDH) must be created using the following values when issuing a document in the SCI format:


Node	Required	Attributes	Value
StandardBusinessDocumentHeader.Sender.Identifier	Yes	Authority="FR"	Supplier's SIREN/SIRET
StandardBusinessDocumentHeader.Receiver.Identifier	Yes	Authority="FR"	Buyer's SIREN/SIRET
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: FR
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 SIREN/SIRET
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: SenderDocumentId Child node Identifier: A unique document ID, whereby the ERP document ID is recommended.
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'll assume the default value of "DefaultSystemERP". For more information, see this topic.
StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceName	Yes		Default
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: BusinessCategory Child node Identifier: One of: FR-SCI-1.0-INVOICE-1.0 FR-CIUSUBL-1.0-INVOICE-1.0 FR-FACTURX-1.06-INVOICE-1.0 FR-CIUSCII-1.0-INVOICE-1.0 FR-CDAR-3.0-LIFECYCLE-1.0
SovosDocument.SovosCanonicalInvoice.Invoice	Yes* (only if document type is `FR-SCI-1.0-INVOICE-1.0`)		SCI
SovosDocument.SovosLegalDocument.Base64Document	Yes* (for document types: `FR-CIUSUBL-1.0-INVOICE-1.0`, `FR-FACTURX-1.06-INVOICE-1.0`, `FR-CIUSCII-1.0-INVOICE-1.0`, `FR-CDAR-3.0-LIFECYCLE-1.0`)		Other supported formats

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	Set it to the SBD encoded in Base64, as created in step 1.
dataEncoding	string	Yes	Always set it to "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 - Success

{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "DOCUMENT-ID"
    }
}

Response Sample - Failure

{
  "success": false,
  "status": 400,
  "message": "Bad Request",
  "timestamp": 1601666692,
  "errors": [
    {
      "subCode": "XSD_SYNTAX_ERROR",
      "message": "An XML comment cannot contain '--', and '-' cannot be the last character. Line 276, position 11. "
    }
  ]
}

Step 3: Sovos processes the document

Upon receiving the SCI/Legal, Sovos will validate the document based on mandate specifications.

A notification with an application response is issued with some of the following values:

Submitted (200) CDAR lifecycle
Rejected 'on issue' (213) CDAR lifecycle

Step 4: Sovos transmits the document

Sovos will transmit the document file to the PDP based on the buyer's information left in the Directory and if integration is configured with the PDP receiver (Not available).

A notification with an application response is issued with a "Issued by the Platform (201)" CDAR lifecycle.

Note:

Currently this transmission can only be carried out internally within CN, not involving the tax authority.

Step 5: PDP sends the response to Sovos

After performing its services, PDP sends the response to Sovos.

A notification with an application response is issued with some of the following values:

Received by the platform (202) CDAR lifecycle
Made available (203) CDAR lifecycle
Rejected 'on receipt' (213) CDAR lifecycle (If the document is simulated internally, it won't be rejected as it has already been in reception)
or any other CDAR lifecycle notifications the buyer submits

The supplier needs to retrieve and process this notifications. For more details see Retrieve application responses.

Step 6: Buyer sends the response to Sovos

After retrieving the document the buyer sends the response to its PDP, and the PDP send the response to Sovos.

A notification with an application response is issued with some of the following values:

Received by the platform (202) CDAR lifecycle
Made available (203) CDAR lifecycle
Rejected 'on receipt' (213) CDAR lifecycle (If the document is simulated internally, it won't be rejected as it has already been in reception)
or any other CDAR lifecycle notifications the buyer submits

The supplier needs to retrieve and process this notifications. For more details see Retrieve application responses.

Step 7: Supplier sends SBD with Lifecycle CDAR to Sovos

Lifecycle documents in CDAR format can be submitted to change the Invoice status.

Note:

Follow steps 1 and 2.

Step 8: Supplier Marks the Application Responses as Acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/FR endpoint.

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


Name	Type	Required	Description
status	string	Yes	Set it to read.
notificationId	string	Yes	Set it to the ID of the notification that must be marked as acknowledged.

Note:

Multiple notificationId values can be acknowledged using one Indirect Tax API call by including them in a single request.

Request Sample

curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/FR' \
--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."
}

Retrieve application responses

Transmission Message: It maps to the SCIGovtStatusCode and StatusReason elements in the response message, as described in the Application Responses section, which details any warnings or additional notes to consider. For each transaction, application responses must be retrieved based on the Invoice lifecycle specified under the French mandate.

The supplier must retrieve the application responses that become available during the transaction. The application responses provide status information and include the legal lifecycle format CDAR XML encoded in base64 with the respective legal status.

GET /notifications/FR


Name	Type	Required	Default	Description
taxId	string	No		Set it to include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH. Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.
page	integer	No	1	To specify the page to be returned, set the value between 1 and 10.
perPage	integer	No	10	To specify the number of results for the returned page, set its value between 1 and 100. Important: If the attachment file is configured to return the binary content, instead of a link, it's recommended to use only values between 1 and 10.
sourceSystemId	string	Yes		Set it to include only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAckwnowledged	boolean	No	false	Set it to "true" to specify whether previously acknowledged notifications, within 24 hours of their acknowledgment, must be included in the result.
processType	string	No		Set it to "0" to only include notifications related to outbound documents.

Request Sample

curl --location --request GET 'https://api-test.sovos.com/v1/notifications/FR?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN'

Response Sample

{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "fr_invoice_outbound_1.0",
                    "documentId": "DOCUMENT-ID",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "YOUR-TAXID",
                    "sciCloudStatusCode": "214"
                },
                "appPrefix": "CN",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

GET /documents/FR/{documentId}/notifications

The supplier can send a GET request to the /documents/FR/{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	Set it to the ID of the document returned in step 2

Request Sample

curl --location --request GET 'https://api-test.sovos.com/v1/documents/FR/{documentId}/notifications?' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'

Response Sample

{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "fr_invoice_outbound_1.0",
                    "documentId": "DOCUMENT-ID",
                    "erpDocumentId": "321412",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "YOUR-TAXID",
                    "sciCloudStatusCode": "214"
                },
                "appPrefix": "DLT",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

French mandate e-invoice reporting

An overview of the e-invoice reporting workflow for the French mandate to help developers integrating their applications with the Indirect Tax API.

The flow to report an invoice in France is based on the Reporting business process, which encompasses Transmission. The following diagrams provide a detailed overview of the workflow.

France report invoice flow

Step 1: Supplier / Buyer Creates the Standard Business Document

The Standard Business Document Header (SBDH) must be created using the following values when issuing a document in the SCI format:


Node	Required	Attributes	Value
StandardBusinessDocumentHeader.Sender.Identifier	Yes	Authority="FR"	Supplier's SIREN/SIRET
StandardBusinessDocumentHeader.DocumentIdentification.Standard	Yes		urn.cpro.gouv.fr:1p0:ereporting
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion	Yes		1.0
StandardBusinessDocumentHeader.DocumentIdentification.Type	Yes		Flow10
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Country Child node Identifier: FR
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 SIREN/SIRET
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: SenderDocumentId Child node Identifier: A unique document ID, whereby the ERP document ID is recommended.
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'll assume the default value of "DefaultSystemERP". For more information, see this topic.
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)	Yes		Child node Type: Report.Type Child node Identifier: FR_Reporting_Transaction_Report or FR_Reporting_Payment_Report
StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceName	Yes		Reporting
SovosDocument.SovosLegalDocument.Base64Document	Yes		Other supported formats

Step 2: Supplier / Buyer 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	Set it to the SBD encoded in Base64, as created in step 1.
dataEncoding	string	Yes	Always set it to "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 - Success

{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "DOCUMENT-ID"
    }
}

Response Sample - Failure

{
  "success": false,
  "status": 400,
  "message": "Bad Request",
  "timestamp": 1601666692,
  "errors": [
    {
      "subCode": "XSD_SYNTAX_ERROR",
      "message": "An XML comment cannot contain '--', and '-' cannot be the last character. Line 276, position 11. "
    }
  ]
}

Step 3: Sovos processes the document

Upon receiving the document Sovos will validate the document based on mandate specifications.

Important:

We're using an unofficial schema. Further validations will be carried out when the official schema is published.

The format used will depend on whether the buyer is using a PDP or PPF.

Step 4: Sovos transmits the document

Sovos will send the document in the right format to the PPF system based on the buyers information left in the Directory.

Step 5: PPF Processes the document

PPF performs schema and business rules validation of the invoice. An approval or rejection response message is then generated along with an error message where applicable.

Step 6: PPF sends the response to Sovos

After performing its services, PDP sends the response to Sovos.

Step 7: Supplier / Buyer Retrieves the Application Responses

Attachments configuration: Sovos highly recommends configuring your application response attachments as download links instead of base64-encoded data to avoid potential size limitations when retrieving responses. The default option is "download links".
Note:
When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a 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 — once it's available during the process.

Additionally, you must consider the following details included in the response:

Transmission message: It maps to the SCIGovtStatusCode and StatusReason elements in the response message, as described in the application responses documentation, which details any warnings or additional notes to consider.

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification): When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 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 SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.

Single responseMultiple responses

To complete a transaction, the supplier retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

IP

The document's compliance status is still being processed.

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 SCIGovtStatusCode is present, the error can be found by reading StatusReason.
if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.


#	SCICloudStatusCode	SCIResponseCode	Sample
1	209	AP	Workflow Successfully Completed
2	209	CA	Workflow Successfully Completed
3	209	RE	Workflow Successfully Completed

To complete a transaction, the supplier must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.


#	SCICloudStatusCode	SCIResponseCode	Sample
1	100	IP	Document received successfully
2	102	IP	Document validated successfully
3	200	AP	Authorized by the tax authority
5	209	AP	Workflow Successfully Completed
6	400	RE	Rejected by the tax authority or the counterparty

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

GET /notifications/FR
GET /documents/FR/{documentId}/notifications

GET /notifications/FR

The supplier can send a GET request to the /notifications/FR 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 the `CompanyCode` set in the SBDH. Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the `sourceSystemId` parameter.
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. Note: 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 `SenderSystemId` in the SBDH.
includeAcknowledged	boolean	No	false	Enter "true" to specify whether previously acknowledged notifications must be included in the result.
processType	string	No		Enter "0" to only include notifications related to outbound documents.

Request sample

curl --location --request GET 'https://api-test.sovos.com/v1/notifications/FR?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: 057b5a5e-520c-4ea0-a948-9d583b4d121c' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx'

Response sample

{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 10,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "fr_Report__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/FR/{documentId}/notifications

The supplier can send a GET request to the /documents/FR/{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	Default	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/FR/{documentId}/notifications?' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx' \
--header 'x-correlationId: 6d49dcfe-fd6b-4fb5-a590-44f4e720d70b'

Response sample

{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 10,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "fr_Report__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=="
            }
        ]
    }
}

Step 8: Supplier Marks the Application Responses as Acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/FR endpoint.

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


Name	Type	Required	Description
status	string	Yes	Set it to read.
notificationId	string	Yes	Set it to the ID of the notification that must be marked as acknowledged.

Note:

Multiple notificationId values can be acknowledged using one Indirect Tax API call by including them in a single request.

Request Sample

curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/FR' \
--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."
}

Error Handling

Customers need to adhere to the error handling principles outlined on the responses page.

Sovos Docs

France

Prerequisites

Available products

Supported use cases

Supported document types

SCI format

Regulated formats

Supported documents

Custom formats

Available configuration formats

Manage lifecycle

Core principles of the invoice lifecycle

Status management

Lifecycle status definitions and procedures

Validate documents

High-level validations

Mandate-specific validations

Trading partners

Add trading partner endpoint

Edit trading partner endpoint

Add trading partner endpoint with Indirect Tax API

Samples for adding a trading partner

Request sample

Response sample

Edit trading partner endpoint with Indirect Tax API

Samples for updating a trading partner

Request sample

Response sample

Get a trading partner endpoint with Indirect Tax API

Samples for fetching a trading partner

Request sample

Response sample

Delete a trading partner endpoint with Indirect Tax API

Samples for removing a trading partner

Request sample

Response sample

Inbound company

Edit inbound company configuration

Configure inbound company with Indirect Tax API

Sample for configuring an inbound company

Request sample

Response sample

Sample for updating an inbound company configuration

Request sample

Response sample

Outbound company

Edit outbound company configuration

Configure outbound company with Indirect Tax API

Sample for configuring an outbound company

Request sample

Response sample

Sample for updating an outbound company configuration

Request sample

Response sample

French mandate inbound e-invoicing

Step 1: Sovos receives the documents from PDP

Step 2: Sovos processes document

Step 3: Sovos makes the documents available

Step 4: Buyer sends SBD with Lifecycle CDAR to Sovos

Step 5: Buyer retrieves application response

Step 6: Supplier marks application response as acknowledged

Error Handling

French mandate outbound e-invoicing

Step 1: Supplier Creates the Standard Business Document

Step 2: Supplier sends the SBD to Sovos

Step 3: Sovos processes the document

Step 4: Sovos transmits the document

Step 5: PDP sends the response to Sovos

Step 6: Buyer sends the response to Sovos

Step 7: Supplier sends SBD with Lifecycle CDAR to Sovos

Step 8: Supplier Marks the Application Responses as Acknowledged

Retrieve application responses

Error Handling

French mandate e-invoice reporting

Step 1: Supplier / Buyer Creates the Standard Business Document

Step 2: Supplier / Buyer sends the SBD to Sovos

Step 3: Sovos processes the document

Step 4: Sovos transmits the document

Step 5: PPF Processes the document