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.

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.

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 PA 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 PA validates all documents against the French mandate's standards and specifications, defined in Annex 7 of External Specifications 3.0.

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: 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).

Reporting scope and requirements

Understand e-reporting system requirements, how platforms must send B2B and B2C transaction data, transmission timing based on VAT regimes, and the complete process for corrections and status tracking.

To see how the requirements for pass thorough reporting have been integrated into Compliance Network, refer to French mandate e-reporting (pass through).

E-reporting scope

E-reporting covers two main categories of operations:

International inter-company operations:
- B2Bi (Business to Business international): French company to foreign company.
- Bi2B (international Business to Business): Foreign company to French company.
- Bi2Bi (international Business to international Business): Foreign company to foreign company, but subject to French VAT.
Operations with non-liable entities (B2C). Transactions between companies and:
- Final consumers.
- Private legal entities not liable to VAT.

Report data

To fulfill e-reporting requirements, send two types of data, transaction and payment. This data covers seller and buyer operations. The PA aggregates this data before sending it.

Your PA handles this automatically for every invoice and lifecycle document sent through the platform. However, if you send documents through other channels, generate the report data and send it through your PA.

Report transaction data

Send transaction data for these operations:

International operations that resulted in an invoice (B2Bi, Bi2B, Bi2Bi).
Operations with non-liable entities (B2C), even if they didn't result in an invoice. Send a daily aggregated report instead of reporting each transaction separately.

Report payment data

Send payment data for these operations:

Payments that occurred during international operations that resulted in an invoice (B2Bi, Bi2B, Bi2Bi).
Payments that occurred during operations with non-liable entities (B2C), even if they didn't result in an invoice. Send a daily aggregated report instead of reporting each transaction separately.

Data aggregation requirements

Your PA sends transaction and payment data to the PPF aggregated by:

Declarant at SIREN level.
Declarant role in the operation. It can be either a supplier or a buyer.

Transmission period determined by the declarant's VAT regime and transaction date.


VAT Regime	Invoice and transaction data		Payment data
VAT Regime	Period	Deadline	Period	Deadline
Normal monthly real	10 day period (decade): From the 1st until, and including, the 10th of the month From the 11th until, and including, the 20th of the month From the 21st until, and including, the end of the month	10 days after the end of the period: The 20th of the month The end of the month The 10th of the following month	Monthly	10th of the following month
Quarterly normal real	Monthly	10th of following month	Monthly	10th of the following month
Simplified VAT	Monthly	Between the 25th and 30th of the following month	Monthly	Between the 25th and 30th of the following month
VAT exemption scheme	Bimonthly (every two months)	Between the 25th and 30th of the following month	Bimonthly (every two months)	Between the 25th and 30th of the following month

Note: The PA sends data to the PPF within 8 hours after each period's deadline.

Report, correct and rectify

The DGFiP defines three operational behaviors during and after the reporting period: Initial/Additional, Correction, and Rectification.

Initial/Additional: During the current period, send the initial load, then any new transactions discovered within the same period. This doesn't affect previous data.
Correction: If you find an error in a submission during the current period, resend the data and mark it as a correction. This replaces previously reported data.
Rectification: If you find an error after the period closes, send a rectification. This replaces the previous period's information while keeping a record of the change.

Functional Controls over transaction and payment data

Your report data must pass the following checks:

Semantic checks: Checks compliance with EN16931 and French electronic invoicing reform requirements.
Data structure checks: Checks that data structure is correct.
Data consistency checks: Checks that fields are logically consistent.
Uniqueness checks: Checks that data is unique based on transmission number, SIREN, and transmission period.

You'll receive the status of the checks in a lifecycle document.

The following table shows the possible statuses:


Code	Status	Mandatory	Description
300	Filed	Yes	The PPF considers the data compliant and sends it to the tax authorities.
301	Rejected	Yes	The PPF considers the data non-compliant and does not send it to the tax authorities.
303	Rejected by the administration	Yes	The tax authorities consider the data non-compliant.
304	Accepted by the administration	Yes	The tax authorities consider the data compliant.

The following table shows the possible reasons for rejection:


Code	Check	Description
REJ_PER	Semantic control	The semantic format of one or more data points doesn't meet requirements.
REJ_UNI	Uniqueness	The data has already been sent and processed.
REJ_COH	Data consistency	One or more data points are inconsistent.
REJ_PER	Period control	The send date doesn't match the declared period.

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 PA 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
}

Retrieve invoice

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:

Step 1: Sovos receives the document

Sovos receives documents from the Supplier's PA.

Step 2: Sovos processes document

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

ℹ️ 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 document available

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

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.

ℹ️ 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	Yes, only for Sovos' direct customers		Set it to include only notifications related to the specified taxId.
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. ⚠️ 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/bulk endpoint. Multiple application responses can be acknowledged using one call by including them in a single request.

To make this request, set the request body to an array of the following 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.

Request Sample

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

Response Sample

{
  "timestamp": 1601673284,
  "status": 207,
  "success": true,
  "message": "Notifications acknowledged successfully.",
  "data": [
    {
      "notificationId": "51341d39-...-a73d73e0de76",
      "success": "true,",
      "message": "Notification marked as read"
    }
  ]
}

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.

Issue invoice

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.

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 PA based on the buyer's information left in the Directory and if integration is configured with the PA receiver (Not available).

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

Step 5: PA sends the response to Sovos

After performing its services, PA 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 PA, and the PA 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.

ℹ️ Follow steps 1 and 2.

Step 8: Supplier Marks the Application Responses as Acknowledged

To make this request, set the request body to an array of the following 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.

Request Sample

curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/FR/bulk' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-...-a73d73e0de76"
    }
]'

Response Sample

{
  "timestamp": 1601673284,
  "status": 207,
  "success": true,
  "message": "Notifications acknowledged successfully.",
  "data": [
    {
      "notificationId": "51341d39-...-a73d73e0de76",
      "success": "true,",
      "message": "Notification marked as read"
    }
  ]
}

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. ℹ️ 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. ⚠️ 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

When handling errors, the client application must follow the Indirect Tax API's error handling principles, as specified in the error handling documentation.

French mandate e-reporting (pass through)

Learn how to report transactions and payments with Sovos Indirect Tax API.

Note:

Use this flow to report transactions and payments which your PA cannot report automatically. This flow applies only to the pass-through version and the e-reporting format (flow 10).

The flow is based on the Reporting business process. The following diagram provides a detailed overview of the workflow.

Step 1: Issuer creates the Standard Business Document

Every transaction or payment 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 the specific format to be processed. 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:


Node	Required	Attributes	Value
StandardBusinessDocumentHeader.Sender.Identifier	Yes	Authority="FR"	SIREN/SIRET of the Issuer
StandardBusinessDocumentHeader.DocumentIdentification.Standard	Yes		urn.cpro.gouv.fr:1p0:ereporting
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion	Yes		1.0
StandardBusinessDocumentHeader.DocumentIdentification.Type	Yes		Flow10
StandardBusinessDocumentHeader.DocumentIde ntification.MultipleType	Yes		False
StandardBusinessDocumentHeader.DocumentIde ntification .CreationDateAndTime			Date of creation with format "yyyy-mm-ddThh:mm:ssZ" (ex: 2024-01-01T12:00:00Z)
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: SIREN/SIRET of the Issuer
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		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

You need to encode the report document in Base64 before you can add it as part of the SBD. Here is a sample:

    </sbd:StandardBusinessDocumentHeader>
    <svs:SovosDocument>
        <svs:SovosLegalDocument>
            <enc:Base64Document>
                <enc:EmbeddedDocument id="1" fileName="invoice.xml" mimeCode="application/xml">PD94bWwgdmVyc...FrdHVyYT4NCg==</enc:EmbeddedDocument>
            </enc:Base64Document>
        </svs:SovosLegalDocument>
    </svs:SovosDocument>
</svs:StandardBusinessDocument>

Note:

Include all the mandatory nodes, as specified in the SBDH schema. If the information cannot be provided, and the respective mandatory node has not been mentioned on the current page, for example the receiver.identifier, you can leave the node empty but must still include it in the SBDH.

SBD sample for flow 10.1 & 10.3 SBD sample for flow 10.2 & 10.4 SBD sample for flow 10.1 & 10.3 correction

<?xml version="1.0" encoding="UTF-8"?>
<sbd:StandardBusinessDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://uri.etsi.org/01903/v1.4.1#"
	xmlns:ad="http://www.sovos.com/namespaces/additionalData"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:n0="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
	xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
	xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
	xmlns:crn="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
	xmlns:dbn="urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2"
	xmlns:enc="http://www.sovos.com/namespaces/base64Document"
	xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
	xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
	xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2"
	xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
	xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2"
	xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
	xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice"
	xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions"
	xmlns:svs="http://www.sovos.com/namespaces/sovosDocument"
	xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2"
	xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
	xmlns:ccts-cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="FR">100000008</sbd:Identifier>
			<!-- Always Siren - 9 digits -->
		</sbd:Sender>
		<sbd:DocumentIdentification>
			<sbd:Standard>urn.cpro.gouv.fr:1p0:ereporting</sbd:Standard>
			<sbd:TypeVersion>1.0</sbd:TypeVersion>
			<sbd:InstanceIdentifier />
			<sbd:Type>Flow10</sbd:Type>
			<sbd:MultipleType>false</sbd:MultipleType>
			<sbd:CreationDateAndTime>2024-01-01T12:00:00Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Version</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>1.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>CompanyCode</sbd:Type>
				<!-- The tax ID of the company sending the request. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>100000008</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderDocumentId</sbd:Type>
				<!-- The unique document ID for the Sender used to identify the document. The value
				content is not constrained, but Sovos recommends using the unique ERP document
				identification. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>UC1_2023001_F</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderSystemId</sbd:Type>
				<!-- the Sender system ID used to create the document. Examples of used values are:
				Sandboxes1, Development2, SAPUAT, SAPERC, etc. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>SystemERP</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Outbound</sbd:Identifier>
				<!-- Used to distinguish the direction of the document submitted -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Mapping.OutputSchema</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Report</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>BusinessProcess</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:BusinessService>
					<sbd:BusinessServiceName>Reporting</sbd:BusinessServiceName>
				</sbd:BusinessService>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Report.Type</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR_Reporting_Transaction_Report</sbd:Identifier>
			</sbd:Scope>
		</sbd:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<enc:Base64Document>
				<enc:EmbeddedDocument id="REP_RM_0006" fileName="report_flow10.xml"
					mimeCode="application/xml">
					<!-- 5 MB limit for the Embedded Document -->
					PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxSZXBvcnQgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+DQoJPFJlcG9ydERvY3VtZW50Pg0KCQk8SWQ+UkVQX1JNXzAwMDU8L0lkPg0KCQk8TmFtZT5SRVBfUk1fMDAwNTwvTmFtZT4NCgkJPElzc3VlRGF0ZVRpbWU+DQoJCQk8RGF0ZVRpbWVTdHJpbmc+MjAyMzA5MTUxNTM0MzA8L0RhdGVUaW1lU3RyaW5nPg0KCQk8L0lzc3VlRGF0ZVRpbWU+DQoJCTxUeXBlQ29kZT5JTjwvVHlwZUNvZGU+DQoJCTxTZW5kZXI+DQoJCQk8SWQgc2NoZW1lSWQ9IjAwMDIiPjExMTExMTExMTwvSWQ+DQoJCQk8TmFtZT5QRFAgRk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+V0s8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQHBkcC5mcjwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvU2VuZGVyPg0KCQk8SXNzdWVyPg0KCQkJPElkIHNjaGVtZUlkPSIwMDAyIj4xMDAwMDAwMDg8L0lkPg0KCQkJPE5hbWU+Rk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+U0U8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQGZvdXJuaXNzZXVyLmNvbTwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvSXNzdWVyPg0KCTwvUmVwb3J0RG9jdW1lbnQ+DQoJPFRyYW5zYWN0aW9uc1JlcG9ydD4NCgkJPFJlcG9ydFBlcmlvZD4NCgkJCTxTdGFydERhdGU+MjAyMjA1MDE8L1N0YXJ0RGF0ZT4NCgkJCTxFbmREYXRlPjIwMjIwNTMxPC9FbmREYXRlPg0KCQk8L1JlcG9ydFBlcmlvZD4NCgkJPEludm9pY2U+DQoJCQk8SUQ+VUM4LTAxLVJFUDIwMjIxMDAxPC9JRD4NCgkJCTxJc3N1ZURhdGU+MjAyMjAxMzE8L0lzc3VlRGF0ZT4NCgkJCTxUeXBlQ29kZT4zODA8L1R5cGVDb2RlPg0KCQkJPEN1cnJlbmN5Q29kZT5FVVI8L0N1cnJlbmN5Q29kZT4NCgkJCTxUYXhEdWVEYXRlVHlwZUNvZGU+MjwvVGF4RHVlRGF0ZVR5cGVDb2RlPg0KCQkJPEJ1c2luZXNzUHJvY2Vzcz4NCgkJCQk8SUQ+TTE8L0lEPg0KCQkJCTxUeXBlSUQ+dXJuLmNwcm8uZ291di5mcjoxcDA6ZXJlcG9ydGluZzwvVHlwZUlEPg0KCQkJPC9CdXNpbmVzc1Byb2Nlc3M+DQoJCQk8U2VsbGVyPg0KCQkJCTxDb21wYW55SWQgc2NoZW1lSWQ9IjAwMDIiPjEwMDAwMDAwODwvQ29tcGFueUlkPg0KCQkJCTxUYXhSZWdpc3RyYXRpb25JZCBxdWFsaWZ5aW5nSWQ9IlZBVCI+RlIxMDAwMDAwMDAwMDwvVGF4UmVnaXN0cmF0aW9uSWQ+DQoJCQkJPFBvc3RhbEFkZHJlc3M+DQoJCQkJCTxDb3VudHJ5SWQ+RlI8L0NvdW50cnlJZD4NCgkJCQk8L1Bvc3RhbEFkZHJlc3M+DQoJCQk8L1NlbGxlcj4NCgkJCTxTZWxsZXJUYXhSZXByZXNlbnRhdGl2ZT4NCgkJCQk8IS0tIFRHLTE2IC8gQkctMTEgOiBSRVBSw4lTRU5UQU5UIEZJU0NBTCBEVSBWRU5ERVVSIC0tPg0KCQkJCTxUYXhSZWdpc3RyYXRpb25JZCBzY2hlbWVJZD0iMDAwMiI+RlI0MDAwMDAwMDAwMDwvVGF4UmVnaXN0cmF0aW9uSWQ+DQoJCQkJPCEtLSBUVC00MCAvIEJULTYzIDogSWRlbnRpZmlhbnQgw6AgbGEgVFZBIGR1IHJlcHLDqXNlbnRhbnQgZmlzY2FsIGR1IHZlbmRldXIgLS0+DQoJCQk8L1NlbGxlclRheFJlcHJlc2VudGF0aXZlPg0KCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJPFN0YXJ0RGF0ZT4yMDIyMDEwMTwvU3RhcnREYXRlPg0KCQkJCTxFbmREYXRlPjIwMjIxMjMxPC9FbmREYXRlPg0KCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJPEFsbG93YW5jZUNoYXJnZSBDaGFyZ2VJbmRpY2F0b3I9InRydWUiPg0KCQkJCTxBbW91bnQ+NS4wMDwvQW1vdW50Pg0KCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQk8QWxsb3dhbmNlQ2hhcmdlIENoYXJnZUluZGljYXRvcj0idHJ1ZSI+DQoJCQkJPEFtb3VudD41LjAwPC9BbW91bnQ+DQoJCQk8L0FsbG93YW5jZUNoYXJnZT4NCgkJCTxNb25ldGFyeVRvdGFsPg0KCQkJCTxUYXhFeGNsdXNpdmVBbW91bnQ+MjUwLjAwPC9UYXhFeGNsdXNpdmVBbW91bnQ+DQoJCQkJPFRheEFtb3VudCBDdXJyZW5jeUNvZGU9IlN0cmluZyI+MDwvVGF4QW1vdW50Pg0KCQkJPC9Nb25ldGFyeVRvdGFsPg0KCQkJPFRheFN1YlRvdGFsPg0KCQkJCTxUYXhhYmxlQW1vdW50PjEwMDwvVGF4YWJsZUFtb3VudD4NCgkJCQk8VGF4QW1vdW50PjIwPC9UYXhBbW91bnQ+DQoJCQkJPFRheENhdGVnb3J5Pg0KCQkJCQk8Q29kZT5TPC9Db2RlPg0KCQkJCQk8UGVyY2VudD4yMC4wMDwvUGVyY2VudD4NCgkJCQk8L1RheENhdGVnb3J5Pg0KCQkJPC9UYXhTdWJUb3RhbD4NCgkJCTxUYXhTdWJUb3RhbD4NCgkJCQk8VGF4YWJsZUFtb3VudD4xMDA8L1RheGFibGVBbW91bnQ+DQoJCQkJPFRheEFtb3VudD41LjU8L1RheEFtb3VudD4NCgkJCQk8VGF4Q2F0ZWdvcnk+DQoJCQkJCTxDb2RlPlM8L0NvZGU+DQoJCQkJCTxQZXJjZW50PjUuNTA8L1BlcmNlbnQ+DQoJCQkJPC9UYXhDYXRlZ29yeT4NCgkJCTwvVGF4U3ViVG90YWw+DQoJCQk8VGF4U3ViVG90YWw+DQoJCQkJPFRheGFibGVBbW91bnQ+NTA8L1RheGFibGVBbW91bnQ+DQoJCQkJPFRheEFtb3VudD4wPC9UYXhBbW91bnQ+DQoJCQkJPFRheENhdGVnb3J5Pg0KCQkJCQk8Q29kZT5FPC9Db2RlPg0KCQkJCQk8UGVyY2VudD4wPC9QZXJjZW50Pg0KCQkJCQk8VGF4RXhlbXB0aW9uUmVhc29uPkRFQk9VUlM8L1RheEV4ZW1wdGlvblJlYXNvbj4NCgkJCQkJPFRheEV4ZW1wdGlvblJlYXNvbkNvZGU+VkFURVgtRVUtNzktQzwvVGF4RXhlbXB0aW9uUmVhc29uQ29kZT4NCgkJCQk8L1RheENhdGVnb3J5Pg0KCQkJPC9UYXhTdWJUb3RhbD4NCgkJCTxMaW5lPg0KCQkJCTxCaWxsZWRRdWFudGl0eSBVbml0Q29kZT0iQmllbnMgZGUgdHlwZSAxIj4xLjAwMDA8L0JpbGxlZFF1YW50aXR5Pg0KCQkJCTxJbnZvaWNlUGVyaW9kPg0KCQkJCQk8U3RhcnREYXRlPjIwMjIwMTAxPC9TdGFydERhdGU+DQoJCQkJCTxFbmREYXRlPjIwMjIxMjMxPC9FbmREYXRlPg0KCQkJCTwvSW52b2ljZVBlcmlvZD4NCgkJCQk8QWxsb3dhbmNlQ2hhcmdlIENoYXJnZUluZGljYXRvcj0iZmFsc2UiPg0KCQkJCQk8QW1vdW50PjQwLjAwPC9BbW91bnQ+DQoJCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQkJPEFsbG93YW5jZUNoYXJnZSBDaGFyZ2VJbmRpY2F0b3I9InRydWUiPg0KCQkJCQk8QW1vdW50PjIwLjAwPC9BbW91bnQ+DQoJCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQkJPFByaWNlPg0KCQkJCQk8UHJpY2VBbW91bnQ+MTIwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPkxCIExpZ25lIDE8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQkJPExpbmU+DQoJCQkJPEJpbGxlZFF1YW50aXR5IFVuaXRDb2RlPSJCaWVucyBkZSB0eXBlIDIiPjIuMDAwMDwvQmlsbGVkUXVhbnRpdHk+DQoJCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJCTxTdGFydERhdGU+MjAyMjAxMDE8L1N0YXJ0RGF0ZT4NCgkJCQkJPEVuZERhdGU+MjAyMjEyMzE8L0VuZERhdGU+DQoJCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJCTxQcmljZT4NCgkJCQkJPFByaWNlQW1vdW50PjUwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPkxCIExpZ25lIDI8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQkJPExpbmU+DQoJCQkJPEJpbGxlZFF1YW50aXR5IFVuaXRDb2RlPSJTZXJ2aWNlcyBkZSB0eXBlIDMiPjEuMDAwMDwvQmlsbGVkUXVhbnRpdHk+DQoJCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJCTxTdGFydERhdGU+MjAyMjAxMDE8L1N0YXJ0RGF0ZT4NCgkJCQkJPEVuZERhdGU+MjAyMjEyMzE8L0VuZERhdGU+DQoJCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJCTxQcmljZT4NCgkJCQkJPFByaWNlQW1vdW50PjUwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPlBTIExpZ25lIDM8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQk8L0ludm9pY2U+DQoJPC9UcmFuc2FjdGlvbnNSZXBvcnQ+DQo8L1JlcG9ydD4=
					</enc:EmbeddedDocument>
			</enc:Base64Document>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</sbd:StandardBusinessDocument>

<?xml version="1.0" encoding="UTF-8"?>
<sbd:StandardBusinessDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://uri.etsi.org/01903/v1.4.1#"
	xmlns:ad="http://www.sovos.com/namespaces/additionalData"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:n0="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
	xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
	xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
	xmlns:crn="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
	xmlns:dbn="urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2"
	xmlns:enc="http://www.sovos.com/namespaces/base64Document"
	xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
	xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
	xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2"
	xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
	xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2"
	xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
	xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice"
	xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions"
	xmlns:svs="http://www.sovos.com/namespaces/sovosDocument"
	xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2"
	xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
	xmlns:ccts-cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="FR">100000008</sbd:Identifier>
			<!-- Always Siren - 9 digits -->
		</sbd:Sender>
		<sbd:DocumentIdentification>
			<sbd:Standard>urn.cpro.gouv.fr:1p0:ereporting</sbd:Standard>
			<sbd:TypeVersion>1.0</sbd:TypeVersion>
			<sbd:InstanceIdentifier />
			<sbd:Type>Flow10</sbd:Type>
			<sbd:MultipleType>false</sbd:MultipleType>
			<sbd:CreationDateAndTime>2024-01-01T12:00:00Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Version</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>1.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>CompanyCode</sbd:Type>
				<!-- The tax ID of the company sending the request. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>100000008</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderDocumentId</sbd:Type>
				<!-- The unique document ID for the Sender used to identify the document. The value
				content is not constrained, but Sovos recommends using the unique ERP document
				identification. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>UC1_2023001_F</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderSystemId</sbd:Type>
				<!-- the Sender system ID used to create the document. Examples of used values are:
				Sandboxes1, Development2, SAPUAT, SAPERC, etc. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>SystemERP</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Outbound</sbd:Identifier>
				<!-- Used to distinguish the direction of the document submitted -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Mapping.OutputSchema</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Report</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>BusinessProcess</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:BusinessService>
					<sbd:BusinessServiceName>Reporting</sbd:BusinessServiceName>
				</sbd:BusinessService>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Report.Type</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR_Reporting_Payment_Report</sbd:Identifier>
			</sbd:Scope>
		</sbd:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<enc:Base64Document>
				<enc:EmbeddedDocument id="REP_RM_0006" fileName="report_flow10.xml"
					mimeCode="application/xml">
					<!-- 5 MB limit for the Embedded Document -->
					PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxSZXBvcnQgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+DQoJPFJlcG9ydERvY3VtZW50Pg0KCQk8SWQ+VUM4LTAxLVJFUDwvSWQ+DQoJCTxOYW1lPlVDOC0wMS1SRVAtRE9DPC9OYW1lPg0KCQk8SXNzdWVEYXRlVGltZT4NCgkJCTxEYXRlVGltZVN0cmluZyBmb3JtYXQ9IjIwNCI+MjAyMzA5MTUxNTM0MzA8L0RhdGVUaW1lU3RyaW5nPg0KCQk8L0lzc3VlRGF0ZVRpbWU+DQoJCTxUeXBlQ29kZT5JTjwvVHlwZUNvZGU+DQoJCTxTZW5kZXI+DQoJCQk8SWQgc2NoZW1lSWQ9IjAwMDIiPjExMTExMTExMTwvSWQ+DQoJCQk8TmFtZT5QRFAgRk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+V0s8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQHBkcC5mcjwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvU2VuZGVyPg0KCQk8SXNzdWVyPg0KCQkJPElkIHNjaGVtZUlkPSIwMDAyIj4xMDAwMDAwMDA8L0lkPg0KCQkJPE5hbWU+Rk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+U0U8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQGZvdXJuaXNzZXVyLmNvbTwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvSXNzdWVyPg0KCTwvUmVwb3J0RG9jdW1lbnQ+DQoJPFBheW1lbnRzUmVwb3J0Pg0KCQk8UmVwb3J0UGVyaW9kPg0KCQkJPFN0YXJ0RGF0ZT4yMDIyMDUwMTwvU3RhcnREYXRlPg0KCQkJPEVuZERhdGU+MjAyMjA1MzE8L0VuZERhdGU+DQoJCTwvUmVwb3J0UGVyaW9kPg0KCQk8SW52b2ljZT4NCgkJCTxJbnZvaWNlSUQ+ZmFjLTIzMDUyMDIyLTAwMTwvSW52b2ljZUlEPg0KCQkJPElzc3VlRGF0ZT4yMDIyMDUzMTwvSXNzdWVEYXRlPg0KCQkJPFBheW1lbnQ+DQoJCQkJPERhdGU+MjAyMjA1MjM8L0RhdGU+DQoJCQkJPFN1YlRvdGFscz4NCgkJCQkJPFRheFBlcmNlbnQ+MjAuMDA8L1RheFBlcmNlbnQ+DQoJCQkJCTxDdXJyZW5jeUNvZGU+RVVSPC9DdXJyZW5jeUNvZGU+DQoJCQkJCTxBbW91bnQ+MTUwLjAwPC9BbW91bnQ+DQoJCQkJPC9TdWJUb3RhbHM+DQoJCQk8L1BheW1lbnQ+DQoJCTwvSW52b2ljZT4NCgk8L1BheW1lbnRzUmVwb3J0Pg0KPC9SZXBvcnQ+
					</enc:EmbeddedDocument>
			</enc:Base64Document>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</sbd:StandardBusinessDocument>

<sbd:StandardBusinessDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://uri.etsi.org/01903/v1.4.1#"
	xmlns:ad="http://www.sovos.com/namespaces/additionalData"
	xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
	xmlns:n0="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
	xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
	xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
	xmlns:crn="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
	xmlns:dbn="urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2"
	xmlns:enc="http://www.sovos.com/namespaces/base64Document"
	xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"
	xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
	xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2"
	xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2"
	xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2"
	xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"
	xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice"
	xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions"
	xmlns:svs="http://www.sovos.com/namespaces/sovosDocument"
	xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2"
	xmlns:xades="http://uri.etsi.org/01903/v1.3.2#"
	xmlns:ccts-cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="FR">100000008</sbd:Identifier>
			<!-- Always Siren - 9 digits -->
		</sbd:Sender>
		<sbd:DocumentIdentification>
			<sbd:Standard>urn.cpro.gouv.fr:1p0:ereporting</sbd:Standard>
			<sbd:TypeVersion>1.0</sbd:TypeVersion>
			<sbd:InstanceIdentifier />
			<sbd:Type>Flow10</sbd:Type>
			<sbd:MultipleType>false</sbd:MultipleType>
			<sbd:CreationDateAndTime>2024-01-01T12:00:00Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Version</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>1.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>CompanyCode</sbd:Type>
				<!-- The tax ID of the company sending the request. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>100000008</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderDocumentId</sbd:Type>
				<!-- The unique document ID for the Sender used to identify the document. The value
				content is not constrained, but Sovos recommends using the unique ERP document
				identification. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>UC1_2023001_F</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- optional -->
				<sbd:Type>SenderSystemId</sbd:Type>
				<!-- the Sender system ID used to create the document. Examples of used values are:
				Sandboxes1, Development2, SAPUAT, SAPERC, etc. -->
				<sbd:InstanceIdentifier />
				<sbd:Identifier>SystemERP</sbd:Identifier>
				<!-- Must be passed in the metadata of the notification relating to the document
				sent -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Outbound</sbd:Identifier>
				<!-- Used to distinguish the direction of the document submitted -->
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>Mapping.OutputSchema</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>Report</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<!-- Mandatory -->
				<sbd:Type>BusinessProcess</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:BusinessService>
					<sbd:BusinessServiceName>Reporting</sbd:BusinessServiceName>
				</sbd:BusinessService>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Report.Type</sbd:Type>
				<sbd:InstanceIdentifier />
				<sbd:Identifier>FR_Reporting_Transaction_Report</sbd:Identifier>
			</sbd:Scope>
		</sbd:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<enc:Base64Document>
				<enc:EmbeddedDocument id="REP_RM_0006" fileName="report_flow10.xml"
					mimeCode="application/xml">
					<!-- 5 MB limit for the Embedded Document -->
					PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxSZXBvcnQgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSI+DQoJPFJlcG9ydERvY3VtZW50Pg0KCQk8SWQ+UkVQX1JNXzAwMDY8L0lkPg0KCQk8TmFtZT5SRVBfUk1fMDAwNjwvTmFtZT4NCgkJPElzc3VlRGF0ZVRpbWU+DQoJCQk8RGF0ZVRpbWVTdHJpbmc+MjAyMzA5MTUxNTM0MzA8L0RhdGVUaW1lU3RyaW5nPg0KCQk8L0lzc3VlRGF0ZVRpbWU+DQoJCTxUeXBlQ29kZT5SRTwvVHlwZUNvZGU+DQoJCTxSZWZlcmVuY2VzPg0KCQkJPFJlcG9ydElkIHNjaGVtZUlkPSdJTic+UkVQX1JNXzAwMDU8L1JlcG9ydElkPg0KCQk8L1JlZmVyZW5jZXM+DQoJCTxTZW5kZXI+DQoJCQk8SWQgc2NoZW1lSWQ9IjAwMDIiPjExMTExMTExMTwvSWQ+DQoJCQk8TmFtZT5QRFAgRk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+V0s8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQHBkcC5mcjwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvU2VuZGVyPg0KCQk8SXNzdWVyPg0KCQkJPElkIHNjaGVtZUlkPSIwMDAyIj4xMDAwMDAwMDg8L0lkPg0KCQkJPE5hbWU+Rk9VUk5JU1NFVVI8L05hbWU+DQoJCQk8Um9sZUNvZGU+U0U8L1JvbGVDb2RlPg0KCQkJPFVSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCQkJPFVSSUlEPmZvdXJuaXNzZXVyQGZvdXJuaXNzZXVyLmNvbTwvVVJJSUQ+DQoJCQk8L1VSSVVuaXZlcnNhbENvbW11bmljYXRpb24+DQoJCTwvSXNzdWVyPg0KCTwvUmVwb3J0RG9jdW1lbnQ+DQoJPFRyYW5zYWN0aW9uc1JlcG9ydD4NCgkJPFJlcG9ydFBlcmlvZD4NCgkJCTxTdGFydERhdGU+MjAyMjA1MDE8L1N0YXJ0RGF0ZT4NCgkJCTxFbmREYXRlPjIwMjIwNTMxPC9FbmREYXRlPg0KCQk8L1JlcG9ydFBlcmlvZD4NCgkJPEludm9pY2U+DQoJCQk8SUQ+VUM4LTAxLVJFUDIwMjIxMDAxPC9JRD4NCgkJCTxJc3N1ZURhdGU+MjAyMjAxMzE8L0lzc3VlRGF0ZT4NCgkJCTxUeXBlQ29kZT4zODA8L1R5cGVDb2RlPg0KCQkJPEN1cnJlbmN5Q29kZT5FVVI8L0N1cnJlbmN5Q29kZT4NCgkJCTxUYXhEdWVEYXRlVHlwZUNvZGU+MjwvVGF4RHVlRGF0ZVR5cGVDb2RlPg0KCQkJPEJ1c2luZXNzUHJvY2Vzcz4NCgkJCQk8SUQ+TTE8L0lEPg0KCQkJCTxUeXBlSUQ+dXJuLmNwcm8uZ291di5mcjoxcDA6ZXJlcG9ydGluZzwvVHlwZUlEPg0KCQkJPC9CdXNpbmVzc1Byb2Nlc3M+DQoJCQk8U2VsbGVyPg0KCQkJCTxDb21wYW55SWQgc2NoZW1lSWQ9IjAwMDIiPjEwMDAwMDAwODwvQ29tcGFueUlkPg0KCQkJCTxUYXhSZWdpc3RyYXRpb25JZCBxdWFsaWZ5aW5nSWQ9IlZBVCI+RlIxMDAwMDAwMDAwMDwvVGF4UmVnaXN0cmF0aW9uSWQ+DQoJCQkJPFBvc3RhbEFkZHJlc3M+DQoJCQkJCTxDb3VudHJ5SWQ+RlI8L0NvdW50cnlJZD4NCgkJCQk8L1Bvc3RhbEFkZHJlc3M+DQoJCQk8L1NlbGxlcj4NCgkJCTxTZWxsZXJUYXhSZXByZXNlbnRhdGl2ZT4NCgkJCQk8IS0tIFRHLTE2IC8gQkctMTEgOiBSRVBSw4lTRU5UQU5UIEZJU0NBTCBEVSBWRU5ERVVSIC0tPg0KCQkJCTxUYXhSZWdpc3RyYXRpb25JZCBzY2hlbWVJZD0iMDAwMiI+RlI0MDAwMDAwMDAwMDwvVGF4UmVnaXN0cmF0aW9uSWQ+DQoJCQkJPCEtLSBUVC00MCAvIEJULTYzIDogSWRlbnRpZmlhbnQgw6AgbGEgVFZBIGR1IHJlcHLDqXNlbnRhbnQgZmlzY2FsIGR1IHZlbmRldXIgLS0+DQoJCQk8L1NlbGxlclRheFJlcHJlc2VudGF0aXZlPg0KCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJPFN0YXJ0RGF0ZT4yMDIyMDEwMTwvU3RhcnREYXRlPg0KCQkJCTxFbmREYXRlPjIwMjIxMjMxPC9FbmREYXRlPg0KCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJPEFsbG93YW5jZUNoYXJnZSBDaGFyZ2VJbmRpY2F0b3I9InRydWUiPg0KCQkJCTxBbW91bnQ+NS4wMDwvQW1vdW50Pg0KCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQk8QWxsb3dhbmNlQ2hhcmdlIENoYXJnZUluZGljYXRvcj0idHJ1ZSI+DQoJCQkJPEFtb3VudD41LjAwPC9BbW91bnQ+DQoJCQk8L0FsbG93YW5jZUNoYXJnZT4NCgkJCTxNb25ldGFyeVRvdGFsPg0KCQkJCTxUYXhFeGNsdXNpdmVBbW91bnQ+MjUwLjAwPC9UYXhFeGNsdXNpdmVBbW91bnQ+DQoJCQkJPFRheEFtb3VudCBDdXJyZW5jeUNvZGU9IlN0cmluZyI+MDwvVGF4QW1vdW50Pg0KCQkJPC9Nb25ldGFyeVRvdGFsPg0KCQkJPFRheFN1YlRvdGFsPg0KCQkJCTxUYXhhYmxlQW1vdW50PjEwMDwvVGF4YWJsZUFtb3VudD4NCgkJCQk8VGF4QW1vdW50PjIwPC9UYXhBbW91bnQ+DQoJCQkJPFRheENhdGVnb3J5Pg0KCQkJCQk8Q29kZT5TPC9Db2RlPg0KCQkJCQk8UGVyY2VudD4yMC4wMDwvUGVyY2VudD4NCgkJCQk8L1RheENhdGVnb3J5Pg0KCQkJPC9UYXhTdWJUb3RhbD4NCgkJCTxUYXhTdWJUb3RhbD4NCgkJCQk8VGF4YWJsZUFtb3VudD4xMDA8L1RheGFibGVBbW91bnQ+DQoJCQkJPFRheEFtb3VudD41LjU8L1RheEFtb3VudD4NCgkJCQk8VGF4Q2F0ZWdvcnk+DQoJCQkJCTxDb2RlPlM8L0NvZGU+DQoJCQkJCTxQZXJjZW50PjUuNTA8L1BlcmNlbnQ+DQoJCQkJPC9UYXhDYXRlZ29yeT4NCgkJCTwvVGF4U3ViVG90YWw+DQoJCQk8VGF4U3ViVG90YWw+DQoJCQkJPFRheGFibGVBbW91bnQ+NTA8L1RheGFibGVBbW91bnQ+DQoJCQkJPFRheEFtb3VudD4wPC9UYXhBbW91bnQ+DQoJCQkJPFRheENhdGVnb3J5Pg0KCQkJCQk8Q29kZT5FPC9Db2RlPg0KCQkJCQk8UGVyY2VudD4wPC9QZXJjZW50Pg0KCQkJCQk8VGF4RXhlbXB0aW9uUmVhc29uPkRFQk9VUlM8L1RheEV4ZW1wdGlvblJlYXNvbj4NCgkJCQkJPFRheEV4ZW1wdGlvblJlYXNvbkNvZGU+VkFURVgtRVUtNzktQzwvVGF4RXhlbXB0aW9uUmVhc29uQ29kZT4NCgkJCQk8L1RheENhdGVnb3J5Pg0KCQkJPC9UYXhTdWJUb3RhbD4NCgkJCTxMaW5lPg0KCQkJCTxCaWxsZWRRdWFudGl0eSBVbml0Q29kZT0iQmllbnMgZGUgdHlwZSAxIj4xLjAwMDA8L0JpbGxlZFF1YW50aXR5Pg0KCQkJCTxJbnZvaWNlUGVyaW9kPg0KCQkJCQk8U3RhcnREYXRlPjIwMjIwMTAxPC9TdGFydERhdGU+DQoJCQkJCTxFbmREYXRlPjIwMjIxMjMxPC9FbmREYXRlPg0KCQkJCTwvSW52b2ljZVBlcmlvZD4NCgkJCQk8QWxsb3dhbmNlQ2hhcmdlIENoYXJnZUluZGljYXRvcj0iZmFsc2UiPg0KCQkJCQk8QW1vdW50PjQwLjAwPC9BbW91bnQ+DQoJCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQkJPEFsbG93YW5jZUNoYXJnZSBDaGFyZ2VJbmRpY2F0b3I9InRydWUiPg0KCQkJCQk8QW1vdW50PjIwLjAwPC9BbW91bnQ+DQoJCQkJPC9BbGxvd2FuY2VDaGFyZ2U+DQoJCQkJPFByaWNlPg0KCQkJCQk8UHJpY2VBbW91bnQ+MTIwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPkxCIExpZ25lIDE8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQkJPExpbmU+DQoJCQkJPEJpbGxlZFF1YW50aXR5IFVuaXRDb2RlPSJCaWVucyBkZSB0eXBlIDIiPjIuMDAwMDwvQmlsbGVkUXVhbnRpdHk+DQoJCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJCTxTdGFydERhdGU+MjAyMjAxMDE8L1N0YXJ0RGF0ZT4NCgkJCQkJPEVuZERhdGU+MjAyMjEyMzE8L0VuZERhdGU+DQoJCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJCTxQcmljZT4NCgkJCQkJPFByaWNlQW1vdW50PjUwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPkxCIExpZ25lIDI8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQkJPExpbmU+DQoJCQkJPEJpbGxlZFF1YW50aXR5IFVuaXRDb2RlPSJTZXJ2aWNlcyBkZSB0eXBlIDMiPjEuMDAwMDwvQmlsbGVkUXVhbnRpdHk+DQoJCQkJPEludm9pY2VQZXJpb2Q+DQoJCQkJCTxTdGFydERhdGU+MjAyMjAxMDE8L1N0YXJ0RGF0ZT4NCgkJCQkJPEVuZERhdGU+MjAyMjEyMzE8L0VuZERhdGU+DQoJCQkJPC9JbnZvaWNlUGVyaW9kPg0KCQkJCTxQcmljZT4NCgkJCQkJPFByaWNlQW1vdW50PjUwLjAwMDA8L1ByaWNlQW1vdW50Pg0KCQkJCTwvUHJpY2U+DQoJCQkJPFByb2R1Y3Q+DQoJCQkJCTxOYW1lPlBTIExpZ25lIDM8L05hbWU+DQoJCQkJPC9Qcm9kdWN0Pg0KCQkJPC9MaW5lPg0KCQk8L0ludm9pY2U+DQoJPC9UcmFuc2FjdGlvbnNSZXBvcnQ+DQo8L1JlcG9ydD4=
					</enc:EmbeddedDocument>
			</enc:Base64Document>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</sbd:StandardBusinessDocument>

Step 2: Issuer sends the SBD to Sovos

Send 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".

If you receive an error response, correct your request and retry. An error at this point does not start the flow and does not result in a notification.

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

Sovos validates the document based on mandate specifications. If any of the validations fail, the flow stops and Sovos generates a notification with the error information.

The validation consists of two steps:

Schema validation
Schematron validation, which will become available after the French tax authority releases the official Schematron files

The resulting system notification will have an application response status of:

102, if validation passed
401, if validation failed

Step 4: Sovos transmits the document

Sovos sends the document to the PPF through the predefined channel.

Step 5: PPF reviews the report and communicates the integration status

The PPF receives the report and returns the status Recevable, confirming the transmission. Then, the PPF performs functional and technical validations which can result in:

Status 300 (Déposée): The report is accepted by the PPF (Filed).
Status 301 (Rejetée): The report is not accepted by the PPF (Rejected). Send another corrected report to replace the previous one. Use TypeCode element set to RE and a reference to the corrected report.

The PPF validates if the data is compliant in addition to the reception checks, which can result in:

Status 304 (Acceptée par l'administration): Accepted by administration
Status 303 (Refusée par l'administration): Refused by administration

Step 6: Issuer retrieves the application responses

Attachments: Retrieve the attachments from the Base64-encoded binary data, embedded in the application response .

When you initially send the document, you receive a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that you must retrieve the application responses that become available for the duration of the flow. They provide status information and documents encoded in Base64 after they become 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.

There are two layers of responses in the e-reporting flow 10:

Sovos flow 10 validation responses, which include schema and Schematron validations
PPF technical and functional validation responses

Sovos validations PPF validations


#	SCICloudStatusCode	SCIResponseCode	Sample
1	102	IP	Successfully validated
2	401	RE	Validation error


#	PPF Status	SCICloudStatusCode	SCIResponseCode	Sample
1	Recevable	tbd	tbd	tbd
2	Déposée	tbd	tbd	tbd
3	Rejetée	tbd	tbd	tbd
4	Refusée par l'administration	tbd	tbd	tbd
5	Acceptée par l'administration	tbd	tbd	tbd

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

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

GET /notifications/FR

The issuer 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. ℹ️ 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. ⚠️ 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 issuer 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 7: Issuer marks the application responses as acknowledged

After retrieving application responses, you need to process them and mark them as acknowledged. This is done by sending a PUT request to the /notifications/FR/bulk endpoint. Multiple application responses can be acknowledged using one Indirect Tax API call by including them in a single request.

If not acknowledged the application response will remain in the queue and will be returned the next time you fetch application responses. This can lead to duplicate processing or duplication errors on your side.

To make this request, set the request body to an array of the following 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.

Request Sample

curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/FR/bulk' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-...-a73d73e0de76"
    }
]'

Response Sample

{
  "timestamp": 1601673284,
  "status": 207,
  "success": true,
  "message": "Notifications acknowledged successfully.",
  "data": [
    {
      "notificationId": "51341d39-...-a73d73e0de76",
      "success": "true,",
      "message": "Notification marked as read"
    }
  ]
}

Error handling

Note:

Not all 400 range errors defined in our error handling documentation apply to the reporting flow but many do. The best approach is to analyze the error messages to discover the source of the issue.

All errors in the 500 range apply to the reporting flow. Read our error handling documentation on how to handle this types of errors.

When handling errors, the client application must follow the Indirect Tax API's error handling principles, as specified in the error handling documentation.

Error messages

Market codes

The market codes list France-specific messages that come from the tax authority.


Code	Code Service	Code Category	Sequence	Component	Original Code	Original Message	User Error Message
Company Validation
M-FR-2009001	1	9	1	Company Validation	CountryCode	Country code value should be FR.	Country code should be FR.
M-FR-2009002	1	9	2	Company Validation	TaxId	Tax ID is required.	Company TaxId is required.
M-FR-2009003	1	9	3	Company Validation	TaxId	Operation cannot be executed due to mismatch between Tax ID and Siren/Siret.	Operation cannot be executed due to mismatch between TaxId and Siren/Siret.
Components Validation
M-FR-2008001	1	8	1	Components Validator	CodeComponentsRequired	No valid fields found.	No valid fields found.
M-FR-2008002	1	8	2	Components Validator	MATRICULE_PLATEFORME	It should be the only code component available.	It should be the only code component available.
M-FR-2008003	1	8	3	Components Validator	SIREN	Siren is Mandatory.	Siren is Mandatory.
M-FR-2008004	1	8	4	Components Validator	SIREN	Invalid Format.	Invalid Format.
M-FR-2008005	1	8	5	Components Validator	SIREN	Must be unique.	Must be unique.
M-FR-2008006	1	8	6	Components Validator	SIRET	Must be unique.	Must be unique.
M-FR-2008007	1	8	7	Components Validator	SIRET	Invalid Format.	Invalid Format.
M-FR-2008008	1	8	8	Components Validator	SIRET	The SIRET and the SIREN must be related.	The SIRET and the SIREN must be related.
M-FR-2008009	1	8	9	Components Validator	SIRET	When exists siret field, it must have value.	When exists siret field, it must have value.
M-FR-2008010	1	8	10	Components Validator	SUFFIXE_ADRESSAGE	Must be unique.	Must be unique.
M-FR-2008011	1	8	11	Components Validator	SUFFIXE_ADRESSAGE	Invalid Format.	Invalid Format.
M-FR-2008012	1	8	12	Components Validator	SUFFIXE_ADRESSAGE	Siret must be null when suffix field exists.	Siret must be null when suffix field exists.
M-FR-2008013	1	8	13	Components Validator	SUFFIXE_ADRESSAGE	Code Routage must be null when suffix field exists.	Code Routage must be null when suffix field exists.
M-FR-2008014	1	8	14	Components Validator	SUFFIXE_ADRESSAGE	When exists suffixe field, it must have value.	When exists suffixe field, it must have value.
M-FR-2008015	1	8	15	Components Validator	CODE_ROUTAGE	Must be unique.	Must be unique.
M-FR-2008016	1	8	16	Components Validator	CODE_ROUTAGE	Invalid Format.	Invalid Format.
M-FR-2008017	1	8	17	Components Validator	CODE_ROUTAGE	Siret is Mandatory when Route Code exists.	Siret is Mandatory when Route Code exists.
M-FR-2008018	1	8	18	Components Validator	CODE_ROUTAGE	Suffix must be null when Code Routage field exists.	Suffix must be null when Code Routage field exists.
M-FR-2008019	1	8	19	Components Validator	CODE_ROUTAGE	When exists code routage field, it must have value.	When exists code routage field, it must have value.
Update Endpoint
M-FR-2002001	1	2	1	Update Endpoint	Siret	The Siret and the Siren must be related.	The Siret and the Siren must be related.
M-FR-2002002	1	2	2	Update Endpoint	Siren	Field Siren was not found.	Siren is not found.
M-FR-2002003	1	2	3	Update Endpoint	Siren	Siren value is null or empty	Siren is Required.
M-FR-2002004	1	2	4	Update Endpoint	ValidityPeriodStartRequired	ValidityPeriod Start is different from the start date of the current line	ValidityPeriod Start date is required.
M-FR-2002005	1	2	5	Update Endpoint	(Code From Load Configurations)	(Message From Load Configurations)	An error occurred while loading configurations.
M-FR-2002006	1	2	6	Update Endpoint	(Code From Response)	(Message From Response)	An error occurred while trying to retrieve the Ligne Annuaire.
M-FR-2002007	1	2	7	Update Endpoint	PutLigneAnnuaireError	An error occurred while trying to save the Ligne Annuaire.	An error occurred while trying to save the Ligne Annuaire.
M-FR-2002008	1	2	8	Update Endpoint	(Code From Response)	(Message From Response)	An error occurred perform save operation on Peppol.
Register Endpoint
M-FR-2005001	1	5	1	Register Endpoint	ObjectRequired	Data is Required	Data is Required!
M-FR-2005002	1	5	2	Register Endpoint	InvalidOperation	Outbound endpoint creation is not supported unless it is a LifeCycle document type.	Outbound endpoint creation is not supported unless it is a LifeCycle document type.
M-FR-2005003	1	5	3	Register Endpoint	EndpointCodeRequired	Endpoint Code is required.	Endpoint Code is required.
M-FR-2005004	1	5	4	Register Endpoint	EndpointSchemeRequired	Endpoint Scheme is required.	Endpoint Scheme is required.
M-FR-2005005	1	5	5	Register Endpoint	PdpRegistrationNotSupported	Invalid Operation: cannot register a PDP.	Invalid Operation: cannot register a PDP.
M-FR-2005006	1	5	6	Register Endpoint	ValidityPeriodStartRequired	ValidityPeriod Start date is required.	ValidityPeriod Start date is required.
M-FR-2005007	1	5	7	Register Endpoint	Siren	Field Siren was not found.	Siren is not found.
M-FR-2005008	1	5	8	Register Endpoint	Siren	Siren value is null or empty.	Siren is Required.
M-FR-2005009	1	5	9	Register Endpoint	IdInstanceRequired	Could not get IdInstance from Public Directory	Could not get IdInstance from Public Directory
M-FR-2005010	1	5	10	Register Endpoint	CodeRoutageRequired	Siret and IdentifiantRoutage are required for Code Routage	Siret and IdentifiantRoutage are required for Code Routage
M-FR-2005011	1	5	11	Register Endpoint	GetLigneAnnuaireByCodeError	(Code From Response)	(Message From Response)
M-FR-2005012	1	5	12	Register Endpoint	UpdateLigneAnnuaireError	(Code From Response)	(Message From Response)
M-FR-2005013	1	5	13	Register Endpoint	CreateLigneAnnuaireError	(Code From Response)	(Message From Response)
M-FR-2005014	1	5	14	Register Endpoint	GetCodeRoutageError	(Code From Response)	(Message From Response)
M-FR-2005015	1	5	15	Register Endpoint	CreateCodeRoutageError	(Code From Response)	(Message From Response)
M-FR-2005016	1	5	16	Register Endpoint	LoadConfigurationError	(Code From Load Configuration)	(Message From Load Configuration)
Delete Endpoint
M-FR-2003001	1	3	1	Delete Endpoint	ValidityPeriodEndRequired	ValidityPeriod End date is required.	ValidityPeriod End date is required.
M-FR-2003002	1	3	2	Delete Endpoint	Siren	Field Siren was not found.	Siren is not found.
M-FR-2003003	1	3	3	Delete Endpoint	Siren	Siren value is null or empty.	Siren is Required.
M-FR-2003004	1	3	4	Delete Endpoint	(Code From Load Config)	(Message From Load Config)	An error occurred while loading configurations.
M-FR-2003005	1	3	5	Delete Endpoint	(Code From Response)	(Message From Response)	An error occurred while trying to delete the Ligne Annuaire.
Dynamically Discovery
M-FR-2004001	1	4	1	Dynamically Discovery	SearchParametersRequired	EndpointCode is required.	EndpointCode is required.
M-FR-2004002	1	4	2	Dynamically Discovery	(Code From Load Config)	(Message From Load Config)	An error occurred while loading configurations.
M-FR-2004003	1	4	3	Dynamically Discovery	(Code From Response)	(Messages From Response)	An error occurred while trying to retrieve the endpoint.
Fetch Endpoint
M-FR-2007001	1	7	1	Fetch Endpoint	SearchParametersRequired	IdInstance or EndpointCode are required.	IdInstance or EndpointCode are required.
M-FR-2007002	1	7	2	Fetch Endpoint	MetadataRequired	Metadata is required.	Metadata is required.
M-FR-2007003	1	7	3	Fetch Endpoint	(Code From Load Config)	(Message From Load Config)	An error occurred while loading configurations.
M-FR-2007004	1	7	4	Fetch Endpoint	(Code From Response)	(Messages From Response)	An error occurred while trying to retrieve the Ligne Annuaire by Instance Id.
M-FR-2007004	1	7	4	Fetch Endpoint	(Code From Response)	(Messages From Response)	An error occurred while trying to retrieve the Ligne Annuaire by Code/Identifiante.
Identify Endpoint
M-FR-2006001	1	6	1	Identify Endpoint	CodeComponentsRequired	CodeComponents is required	C

System codes

The system codes list network-related messages that come from Compliance Network.


Code	Description
NS-11001001	Workspace ID is mandatory and must be provided.
NS-11001002	The value provided for workspace ID is not valid.
NS-11001003	Endpoint code is mandatory and must be provided.
NS-11001004	Network type is mandatory and must be provided.
NS-11001005	Document type is mandatory and must be provided.
NS-11001006	Document subtype is mandatory and must be provided.
NS-11001007	The endpoint data is not valid.
NS-11001008	No supported documents found for the endpoint.
NS-11001009	No communications configured for the endpoint.
NS-12001001	An unexpected error occurred while doing the dynamic discovery of the endpoint.
NS-12001002	The network was not found.
NS-12001003	Supported documents and parent cannot both be filled.
NS-12001004	Supported documents or parent must be provided.
NS-12001005	Parent trading partner endpoint must exist.
NS-12001006	Parent partner must exist in the communications gateway.
NS-12001007	Error while creating partner on the communications gateway.
NS-12001008	Error while updating partner on the communications gateway.
NS-12001009	Error while creating the endpoint code components.
NS-12001010	Error while creating the trading partner endpoint.
NS-12001011	Error while updating the trading partner endpoint.
NS-16001001	An unexpected error occurred creating the error transaction.
NS-16002001	An unexpected error occurred creating the invoice transaction.
NS-16003001	An unexpected error occurred creating the lifecycle transaction.
NS-17001001	An unexpected error occurred while processing a document shortcut transaction.
NS-17001002	An error occurred while reading the internal format from the transaction.
NS-17002001	An unexpected error occurred while reading the internal format from the transaction.
NS-17003001	An unexpected error occurred while reading the internal format from the transaction.
NS-17003002	An unexpected error occurred while reading the internal format from the transaction.
NS-17003003	Failed to associate the original document to the transaction.
NS-17003004	Failed to associate the internal document to the transaction.
NS-17003005	Transaction with multiple internal formats is not supported in this use case.
NS-17004001	An unexpected error occurred while mapping to internal format.
NS-17004002	The original file was not found on the storage.
NS-17004003	No internal format generated from the original document.
NS-17004004	Failed to generate the internal format from the original document.
NS-17005001	An unexpected error occurred while processing a new document.
NS-17005002	An unexpected error occurred while processing an existent document.
NS-17005003	An unexpected error occurred while processing an shorcut document.
NS-17006001	An unexpected error occurred while creating the document.
NS-17006002	Could not create document.
NS-17006003	Could not create document because of invalid internal format.
NS-17006004	Could not get seller information from invoice.
NS-17006005	Could not get seller country from invoice.
NS-17006006	Could not get buyer information from invoice.
NS-17006007	Could not get buyer country from invoice.
NS-17007001	An unexpected error occurred while checking the document duplicates.
NS-17007002	An invoice must have a unique document number for a supplier in a given financial year.
NS-17008001	An unexpected error occurred while updating document direction.
NS-17008002	Could not update existing document direction.
NS-17009001	Document direction changed.
NS-17010001	An unexpected error occurred while adding additional data to the document.
NS-17010002	An internal validation failed.
NS-17011001	An unexpected error occurred while validating the validation format.
NS-17011002	The validation format could not be obtained.
NS-17011003	The validation format could not be associated with the document.
NS-17011004	The validation format failed on the schematron validations.
NS-17012001	Skipped mandate validations as the delivery product was not set.
NS-17012002	Skipped mandate validations as the delivery product does not have a validation format configured.
NS-17013001	An unexpected error occurred while enriching the document.
NS-17013002	Failed to add amounts to the document during enrichment.
NS-17013003	Failed to check self-billing during document enrichment.
NS-17013004	Failed to add document tag during enrichment.
NS-17013005	Failed to add document references during enrichment.
NS-17013006	Failed to add emails to the document during enrichment.
NS-17013007	Failed to add document attachments during enrichment.
NS-17014001	An unexpected error occurred while adding additional data to the document.
NS-17015001	No update was made to Tax Authority information.
NS-17015002	Updated Tax Authority information.
NS-17015003	No additional formats were added.
NS-17015004	Additional formats were added.
NS-17016001	An unexpected error occurred while adding additional data to the document.
NS-17016002	An error occurred while associating the PDF file with the document. Please ensure that the PDF file is properly linked and associated with the corresponding document.
NS-17016003	An error occurred during the extraction of the PDF file. Please verify the PDF file integrity and ensure it is compatible with the document extraction process.
NS-17017001	An unexpected error occurred while delivering the document to the recipient.
NS-17017002	Delivery failed because the recipient party was not set on the document.
NS-17017003	Delivery failed due to recipient endpoint identifier with invalid data on the document.
NS-17017004	No endpoint was found for recipient endpoint ID.
NS-17017005	Could not find invoice integration mapper for endpoint when delivering document.
NS-17017006	Failed to generate the integration format.
NS-17017007	Failed to generate the legal format.
NS-17017008	Failed to associate the integration format to the document.
NS-17017009	Failed to associate the legal format to the document.
NS-17017010	An error occurred while delivering the integration format to the recipient.
NS-17017011	An error occurred while adding the destination reference on the delivery transaction.
NS-17018001	Skipped delivery as the delivery product was not set.
NS-17018002	Document should not be notified by email.
NS-17018003	Skipped legal format generation.
NS-17019001	An unexpected error occurred while delivering the document to the recipient.
NS-17019002	Company name is mandatory and must be provided.
NS-17019003	Company country is mandatory and must be provided.
NS-17019004	Company tax ID is mandatory and must be provided.
NS-17019005	Legal format name is mandatory and must be provided.
NS-17019006	Legal format type is mandatory and must be provided.
NS-17019007	Legal format full name is mandatory and must be provided.
NS-17019008	Integration format is mandatory and must be provided.
NS-17019009	Integration format name is mandatory and must be provided.
NS-17019010	Integration format type is mandatory and must be provided.
NS-17019011	Integration format full name is mandatory and must be provided.
NS-17019012	Integration format ID is mandatory and must be provided.
NS-17020001	An unexpected error occurred while delivering the document to the recipient.
NS-17020002	Partner not found in the communications gateway.
NS-17020003	Failed to communicate with the communications gateway.
NS-17020004	An unexpected error occurred in the communications gateway.
NS-17021001	An unexpected error occurred while transmitting the transmission format.
NS-17021002	The transmission product does not have a compliance services product ID set.
NS-17021003	The transmission product does not have transmission format set for invoice.
NS-17021004	Could not obtain or generate the transmition format.
NS-17021005	Failed to associate the transmission format to the document.
NS-17021006	Could not send transmission format to the transmission middleware.
NS-17022001	Skipped transmission as the CTC product was not set.
NS-17023001	An unexpected error occurred when trying to serialize the Application Response to base64 string.
NS-17024001	An unexpected error occurred while archiving the document.
NS-17024002	Could not archive document using transmission middleware.
NS-17025001	Skipped archiving as the product was not set.
NS-18001001	An unexpected error occurred while issuing the lifecycle.
NS-18002001	An unexpected error occurred while processing a lifecycle transaction.
NS-18003001	Could not find document for lifecycle association.
NS-18004001	An unexpected error occurred while associating document to lifecycle.
NS-18004002	Error while associating document to lifecycle.
NS-18005001	An unexpected error occurred while delivering the lifecycle.
NS-18005002	Delivery failed due to recipient endpoint identifier with invalid data on the lifecycle.
NS-18005003	No Endpoint was found for recipient endpoint ID.
NS-18005004	No communication set for the supported document.
NS-18005005	Failed to generate the integration format.
NS-18005006	Failed to generate the legal format.
NS-18005007	Failed to associate the integration format to the lifecycle.
NS-18005008	Failed to associate the legal format to the lifecycle.
NS-18005009	An error occurred while delivering the integration format to the recipient.
NS-18005010	An error occurred while adding the destination reference on the delivery transaction.
NS-18006001	Skipped lifecycle delivery as the delivery product was not set.
NS-18006002	Skipped legal format generation as the delivery product was not set for recipient or issuer.
NS-18006003	Skipped legal format generation as there is no legal format set for the product.
NS-18007001	An unexpected error occurred while delivering the document do the recipient.
NS-18007002	Lifecycle must be associated to a document.
NS-18007003	Company name is mandatory and must be provided.
NS-18007004	Company country is mandatory and must be provided.
NS-18007005	Company tax ID is mandatory and must be provided.
NS-18007006	The lifecycle status could not be mapped to application response status.
NS-18007007	Original format name is mandatory and must be provided.
NS-18007008	Original format type is mandatory and must be provided.
NS-18007009	Original format full name is mandatory and must be provided.
NS-18007010	Integration format is mandatory and must be provided.
NS-18007011	Integration format name is mandatory and must be provided.
NS-18007012	Integration format type is mandatory and must be provided.
NS-18007013	Integration format full name is mandatory and must be provided.
NS-18007014	Integration format ID is mandatory and must be provided.
NS-18008001	An unexpected error occurred while delivering the document do the recipient.
NS-18008002	Partner not found in the communications gateway.
NS-18008003	Failed to communicate with the communications gateway.
NS-18008004	An unexpected error occurred in the communications gateway.
NS-18008005	Error while getting the integration document.
NS-18008006	The transaction doesn't have a parent transaction.
NS-18010001	An unexpected error occurred while transmitting the transmission format.
NS-18010002	The transmission product does not have a compliance services product ID set.
NS-18010003	The transmission product does not have transmission format set for lifecycle.
NS-18010004	Could not obtain or generate the transmission format.
NS-18010005	Failed to associate the transmission format to the lifecycle.
NS-18010006	Could not send transmission format to the transmission middleware.
NS-18011001	Skipped transmission as the life cycle does not qualify for reporting to the Tax Authority.
NS-18011002	Skipped lifecycle transmission as the CTC product was not set.
NS-18012001	An unexpected error occurred while updating document.
NS-18013001	An unexpected error occurred while mapping to internal format.
NS-18013002	The original file was not found on the storage.
NS-18013003	No internal format generated from the original document.
NS-18013004	Failed to generate the internal format from the original document.
NS-18014001	An unexpected error occurred while receiving a lifecycle transaction.

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

Reporting scope and requirements

E-reporting scope

Report data

Report transaction data

Report payment data

Data aggregation requirements

Report, correct and rectify

Functional Controls over transaction and payment data

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

Retrieve invoice

Step 1: Sovos receives the document

Step 2: Sovos processes document

Step 3: Sovos makes the document 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

Issue invoice

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