Before you begin

You must have completed account setup before submitting invoices:

• Your organization has the France e-invoicing product enabled.

• An ERP System ID is configured with event mappings for invoice notifications.

• Your SIREN is registered in the PPF Annuaire (directory) and active.

See Set up account for France for details on configuring your organization.

Build your invoice's Standard Business Document

Before submitting, you must wrap your invoice in a Standard Business Document (SBD). The SBD consists of a Standard Business Document Header (SBDH) routing container and the invoice XML body.

See Create a Standard Business Document for the universal SBDH structure, and Invoice body for the complete invoice schema, France-specific field requirements, and validation rules.

Submit through the API

Endpoint

POST /v1/documents

Request

curl --location --request POST 'https://api-test.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {accessToken}' \
--header 'x-correlationId: {uniqueValue}' \
--data-raw '{
    "data": "PD9...d4=",
    "dataEncoding": "base64"
}'

Important:

The access token (Bearer token) expires after one hour. To avoid authentication errors, request a new token before the current one expires. For details, see API authentication.

Success Response: HTTP 202 Accepted

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

A 202 confirms Sovos received the document. It doesn't mean the invoice was validated or delivered. You have to track the outcome through notifications (see Handle application responses).

For the complete list of HTTP status codes, error response schema, and retry guidance, see HTTP status codes and POST /v1/documents.

If the Sovos API is unavailable, check the Sovos status page for real-time operational status. Submissions that Sovos accepted during any PPF unavailability are retried automatically. Don't resubmit.

Reduce the payload size

• Avoid embedding attachments inline in the invoice.

• Split invoices when your business rules allow it.

• Avoid unnecessary details in line item descriptions.

Handle application responses

What happens after submission

When you submit an invoice, Sovos (acting as your PA-E) performs structural and functional validation, then routes the invoice to the buyer's PA-R through the Annuaire and transmits the required regulatory data (Flow 1) to the PPF simultaneously. The buyer's PA-R delivers the invoice to the buyer.

Throughout this process, you receive notifications as the invoice moves through each stage. The full lifecycle is:

1. Sovos validates the invoice (structural and France-specific Schematron rules).

2. Sovos transmits the invoice to the buyer's PA and to the PPF simultaneously.

3. The buyer's PA receives the invoice, validates it, and makes it available to the buyer.

4. The buyer may then take treatment-phase actions: acknowledge, approve, partially approve, dispute, refuse, or suspend. You receive notifications for each action they send.

5. As the seller, you might need to provide supporting documents through Completee (Completed) or submit Encaissée (Payment received) when payment is collected.

For events that occur after the buyer receives the invoice, see Invoice lifecycle and use cases.

Retrieving notifications

Notifications provide status updates as the document progresses through its lifecycle. Use the following parameters when polling outbound France notifications:

GET /v1/notifications/FR?taxId={SIREN}&sourceSystemId={SenderSystemId}&processType=0

taxId

Your SIRENfrom the SBDH

sourceSystemId

The SenderSystemId from the SBDH

processType

Use "0" (outbound)

Acknowledging notifications

After processing, mark notifications as read to prevent retrieving them again. You can do this manually through the API, or configure autoacknowledge on your ERP system ID in account setup. Use the PUT /v1/notifications/FR endpoint or configure your ERP System ID to autoacknowledge after receipt.

See Check notifications for full details, including setup, pagination, and acknowledgement.

For a full reference on application response structure, status codes, and how to interpret attachments, see Understanding application responses.

Understanding SCICloudStatusCode values

Each notification contains an application response with one or more status codes. The primary code to rely on is the SCICloudStatusCode, a Sovos platform code that tells you exactly where the document is in the workflow and the action that you need to take.

Note that SCICloudStatusCode values are three-digit numbers, as are HTTP status codes and French reform lifecycle codes. These are three independent code sets that don't overlap in meaning. The following XML sample shows how they appear together in a single response. For a full explanation of how all code types work together, see Understanding application responses.

Sample: invoice issued by platform (SCICloudStatusCode 204):

<ApplicationResponse>
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">204</cbc:StatusReasonCode>
        <cbc:StatusReason>Sent by platform</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIGovtStatusCode">201</cbc:StatusReasonCode>
        <cbc:StatusReason>Issued by the platform</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
    <cac:DocumentReference>
      <cbc:ID>INV-2024-001234</cbc:ID>
      <cbc:IssueDate>2024-10-07</cbc:IssueDate>
      <cbc:DocumentTypeCode>380</cbc:DocumentTypeCode>
    </cac:DocumentReference>
  </cac:DocumentResponse>
</ApplicationResponse>

Response lifecycle

After submission, track status progression through notifications. The workflow follows this pattern:

Optional statuses 214 and 215 are set by the buyer's PA-R. The buyer's PA-R isn't forced to send them, so you may not always receive them. Sovos sets the optional status 204.

102: transmission confirmed. When Sovos issues Déposée, the invoice has been validated and transmitted to the buyer's PA-R, and the regulatory data (Flow 1) has been sent to the PPF simultaneously. After this point, the invoice exists in the regulatory record. It can't be corrected and resubmitted. Any correction requires formally cancelling the original and issuing a new invoice.

Annuaire check

Before Sovos issues Déposée, Compliance Network now confirms in the Annuaire that the buyer has an active platform address. Déposée now confirms two things:

1. The invoice passed validation

2. The buyer's platform address (active and routable)

If the address check fails,Sovos still issues Déposée, but with a NON_TRANSMISE reason code.

Note:

See Lifecycle and use cases for the NON_TRANSMISE reference.

Response handling decision tree

Status code reference

SCICloudStatusCode	French reform code	Meaning	Action required
102	200 — Déposée (Submitted)	Invoice validated, and the buyer's platform address confirmed active in the Annuaire. PPF and buyer PA-R both notified. If the address check fails, Déposée is still issued with a NON_TRANSMISE reason code.	PPF has the invoice. Continue polling. If NON_TRANSMISE is present, verify the buyer's electronic address.
204	201 — Émise (Issued)	Sovos forwarded invoice to the buyer's PA-R.	Wait. Optional, may not arrive.
214	202 — Reçue (Received)	Buyer's PA-R confirmed receipt.	Wait. Optional, may not arrive.
215	203 — Made available	Invoice delivered to the buyer.	Buyer delivery confirmed. Optional, may not arrive.
401	213 — Rejetée (Rejected)	France schematron validation failed at PA-E or PA-R. Mandatory status. PPF is notified.	See Troubleshoot section.
409	221—Erreur_Routage (RoutingError)	Sovos couldn't route the document to the intended recipient. Sovos generates and delivers a Cross Domain Acknowledgement and Response (CDAR) for this status.	Verify that the buyer's address is registered and active in the Annuaire, then resubmit.

CDAR attachments

For status 102 and 401, the notification includes the official CDAR document from the rejecting PA as an attachment at cac:DocumentResponse/cac:DocumentReference/cac:Attachment. Sovos parses the CDAR and surfaces all error details in the notification's StatusReason fields. Y — you don't need to decode the CDAR to act on errors, but you may download and archive it for compliance records. For full details on attachment structure and extraction, see Understanding application responses.

PDF attachments

For status 204, the notification always includes two PDF attachments at cac:DocumentResponse/cac:DocumentReference/cac:Attachment, regardless of the sender's original format. You can download both attachments using the link at cac:Attachment/cac:ExternalReference/cbc:URI.

You can access your attachments:

• As open download links, in which the response contains a public URL to download the file.

• As secure download links, in which you need to use the Indirect Tax API's bearer token to download the attachment.

By default, Sovos configures your attachments as open download links to avoid potential size limitations when retrieving responses. To improve security, you should configure them as secure links. Then, make a GET call to the secure link returned by the Indirect Tax API, and include the API token. Sample request:

curl --location 'https://einvoicing-api.sovos.com/download/api/v1/download/JqYyqliXiJFKhXshnBQZfW3qpfwATVGE5Q73T41JUynNLJD8zHy5VH__9qzL9No-Kia9olSw3_lNX3KmaA9Je89Xx--vk5pQjyKx0iT_4CwPSABD0Yg7uxXZ8SNiliEhFY-4TOX7m1TV5FwwfqntehbGaiGMI2JVYu18VBDiC_0/plain%27 \
--header 'Authorization: Bearer TOKEN'

Attachment types:

Sovos Legal Document

A legally binding document in one of France's formats: UBL 2.1, CII (UN/CEFACT D22B), or Factur-X. For more information, see the authoritative schema definitions in the PPF external specifications page.

Sovos PDF

A human-readable rendering of the invoice data Sovos generates in the language specified at the product level. If you haven't configured a language, the PDF defaults to English.

Important:

The Sovos PDF and the Factur-X document are produced from the same source template. However, the Factur-X plugin has its own separate copy of the template and doesn't update automatically when the core template changes. If you notice differences between the two attachments, contact Sovos Support to verify that both templates are aligned.

Troubleshoot issues

Errors

The France invoice workflow has three distinct error types, each occurring at a different stage and requiring different remediation:

Technical or structural validation failure (SCICloudStatusCode 401)

Sovos didn't treat the document as a valid invoice. Nothing was transmitted.

Déposée carries a NON_TRANSMISE reason code

If Déposée carries a NON_TRANSMISE reason code, the invoice passed validation, but Compliance Network couldn't confirm an active platform address for the buyer in the Annuaire. The invoice is not rejected, but it was not transmitted to the buyer's platform. Verify that the buyer's electronic address is registered and active in the Annuaire, or contact Sovos support.

France's Schematron validation failure (SCICloudStatusCode 401)

The document was accepted as an invoice but its legal content failed French regulatory checks. Remediation depends on which PA rejected it.

PPF Flow 1 rejection ("REJ_" codes)

The invoice reached the buyer (215), but the PPF rejected the regulatory data extract. The buyer has the invoice, but the PPF copy failed.

Validation errors (SCICloudStatusCode 401)

An SCICloudStatusCode 401 notification can mean Sovos identified a technical or structural error and didn't treat the document as a real invoice, so nothing was transmitted to the buyer or the PPF. The notification contains multiple <cac:Status> elements. The top-level status uses SCICloudStatusCode and each individual error uses SCIInternalValidationStatusCode:

<!-- Workflow status -->
<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>Error processing document</cbc:StatusReason>
</cac:Status>

<!-- Per-error detail (one element per error) -->
<cac:Status>
  <cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>BR-FR-11: Buyer SIREN not found in PPF Annuaire [BT-47]</cbc:StatusReason>
</cac:Status>

Review all SCIInternalValidationStatusCode elements, fix the problems, and resubmit.

For the authoritative rule set, download the most recent PPF external specifications from https://www.impots.gouv.fr/specifications-externes-b2b and open Annexe 7 (Règles de gestion).

Rejected invoices (SCICloudStatusCode 401)

SCICloudStatusCode 401 can also mean the France-specific schematron validation failed — the document content doesn't meet the legal requirements of the reform. This is distinct from a technical error on a document Sovos didn't consider as a real invoice. It means the document was treated as real, but its legal content is incorrect.

401 can be triggered by either PA. The remediation path depends on which PA rejected it:

Rejected by Sovos as PA-E (before transmission)

The PPF has not yet received the invoice. You can correct the identified errors and resubmit. Review the rejection reason in the notification, fix the invoice data, and submit a corrected version. For the full list of validated fields and their rules, see Invoice body.

• If rejected for uniqueness (duplicate invoice number + issue year + seller's SIREN): You must assign a new invoice number because you can't reuse the original.

• If rejected for a routing error (buyer electronic address not found in the Annuaire): Verify that the address is registered and active before resubmitting.

Rejected by the buyer's PA-R (after Déposée / SCICloudStatusCode 102 has been issued)

The PPF already received the invoice when Déposée (102) was issued. Because Rejetée is a required lifecycle status, the PPF is notified of the rejection and considers the original invoice to no longer exist from a regulatory standpoint. You must:

1. Cancel the original invoice in your accounting records.

2. Correct the errors identified in the rejection notification.

3. Issue a new invoice with a new invoice number because you can't reuse the original number.

PPF rejection of regulatory data

When Sovos receives SCICloudStatusCode 102, it extracts the required regulatory data (Flow 1) and transmits it to the PPF. The PPF validates this independently and may reject it. If this happens, you receive a follow-up notification containing a "REJ_" rejection code.

The invoice was still delivered to the buyer, even if the PPF's copy of the regulatory data failed validation.

Code	Check	Meaning
REJ_SEMAN	Semantic format	One or more field values don't conform to the required format
REJ_UNI	Uniqueness	This regulatory data has already been transmitted and processed
REJ_COH	Data coherence	One or more data elements are inconsistent with each other

These are the only three codes defined for Flow 1 regulatory data rejections.

Remediation depends on the cause. The PPF specification defines two scenarios:

Sovos-originated error

The error is in how Sovos generated the Flow 1 extract (not in the original invoice). Sovos can regenerate and resubmit a corrected Flow 1 using the same invoice number. Contact Sovos support to start this.

Error in the original invoice data

The seller must correct the data at the source. This requires issuing either a credit note to cancel the original invoice plus a new corrected invoice, or a corrective invoice (facture rectificative) that cancels and replaces it. The regulatory data for the corrective document is then transmitted to the PPF. The original invoice's regulatory data is not considered by the tax authority.

Note:

If you are unsure which scenario applies, contact Sovos support and provide the "REJ_" code and the affected field.

Notifications

When Sovos processes an outbound document, it sends response notifications to the endpoint included in the submitted invoice. The endpoint must be set up in the system to receive notifications.

Sovos looks for the endpoint value at different paths depending on the invoice type:

Regular outbound invoice

/Invoice/cac:AccountingSupplierParty/cac:Party/cbc:EndpointID

Self-billing invoice

/Invoice/cac:AccountingCustomerParty/cac:Party/cbc:EndpointID

If the endpoint is not properly set up, the API calls return no notifications. Sovos still generates the notifiications, but doesn't deliver them to the endpoint. You can view them in the application.

To fix this, check that the endpoint on the submitted invoice is set up in the system. After the endpoint is set up, Sovos delivers response notifications to that endpoint.