Before you start

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 SBD

Before submitting, you must wrap your invoice in a Standard Business Document (SBD). The SBD consists of an 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 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 does not mean the invoice was validated or delivered — 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 accepted by Sovos during any PPF unavailability are retried automatically — do not resubmit.

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 (Flux 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 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. You (the seller) may need to respond: 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 SIREN from the SBDH

• sourceSystemId: The SenderSystemId from the SBDH

• processType: 0 (outbound)

Acknowledging notifications: After processing, mark notifications as read to prevent retrieving them again. You can do this manually through API, or configure auto-acknowledge on your ERP system ID in account setup. Use endpoint PUT /v1/notifications/FR or configure your ERP System ID to auto-acknowledge 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 SCI CloudStatusCode 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 what, if any, action you need to take.

Note that SCICloudStatusCode values are three-digit numbers, as are HTTP status codes and French reform lifecycle codes — but these are three independent code sets that do not overlap in meaning. The XML sample below 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 is not obligated to send them, and you may not always receive them. Optional status 204 is set by Sovos.

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 (Flux 1) has been sent to the PPF simultaneously. After this point, the invoice exists in the regulatory record — it cannot be corrected and resubmitted. Any correction requires formally cancelling the original and issuing a new invoice.

Response handling decision tree

Status code reference

SCICloudStatusCode	French reform code	Meaning	Action required
102	200 — Déposée/Submitted	Invoice validated and transmitted. PPF and buyer PA-R both notified.	PPF has invoice. Continue polling.
204	201 — Émise/Issued	Sovos forwarded invoice to buyer PA-R.	Wait — optional, may not arrive.
214	202 — Reçue/Received	Buyer PA-R confirmed receipt.	Wait — optional, may not arrive.
215	203 — Made available	Invoice delivered to 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.

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 — you do not 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.

There are three ways you can access your attachments:

• As binary data, so the file is embedded in the Base64-encoded application response.

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

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

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

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

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 have not 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 does not 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

There are three distinct error types in the France invoice workflow, each occurring at a different stage and requiring different remediation:

Technical or structural validation failure (SCICloudStatusCode 401)

Sovosdid not treat the document as a valid invoice. Nothing was transmitted.

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 Flux 1 rejection ("REJ_" codes)

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

Validation errors (SCICloudStatusCode 401)

An SCICloudStatusCode 401 notification can mean Sovos identified a technical or structural error and did not treat the document as a real invoice — nothing was transmitted to the buyer or the PPF. The notification contains multiple <cac:Status> elements. The top-level status uses SCICloudStatusCode; 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 issues, 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 does not meet the legal requirements of the reform. This is distinct from a technical error on a document Sovos did not consider a real invoice. It means the document was treated as real, but its legal content was found to be 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 SIREN): Assign a new invoice number — the original cannot be reused.

• If rejected for a routing error (buyer electronic address not found in the Annuaire): Verify 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 mandatory 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 — the original number cannot be reused.

PPF rejection of regulatory data

When Sovos receives SCICloudStatusCode 102, it extracts the required regulatory data (Flux 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 — only the PPF's copy of the regulatory data failed validation.

Code	Check	Meaning
REJ_SEMAN	Semantic format	One or more field values do not 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 Flux 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 Flux 1 extract (not in the original invoice). Sovos can regenerate and resubmit a corrected Flux 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 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 counted by the tax authority.

Note:

If you are unsure which scenario applies, contact Sovos support with 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 set up correctly, API calls return no notifications. Sovos still generates them, 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. Once the endpoint is set up, Sovos delivers response notifications to it.