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

POST /v1/documents
Content-Type: application/json
Authorization: Bearer {token}
x-correlationId: {unique-value}

{
  "data": "base64_encoded_SBD",
  "dataEncoding": "base64"
}

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

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, suspend, or report payment. You receive notifications for each action they send.

5. You (the seller) may need to respond: provide supporting documents through Completee (Completed), or submit Encaissee (Payment received) when payment is collected.

This article covers 1-3, the sending of the invoice through to when the buyer receives it. See Invoice Lifecycle and Use Cases to learn about all events that may happen after the buyer receives the invoice.

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 SCICloudStatusCodes

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

<ApplicationResponse>
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">214</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, 215, 216) 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.

211 — transmission confirmed. When Sovos issues Déposée, the invoice has been validated, transmitted to the buyer's PA-R, and the regulatory data (Flux 1) 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	—	Sovos validation passed.	Wait.
211	200 — Déposée/Submitted	Invoice validated and transmitted. PPF and buyer PA-R both notified.	PPF has invoice. Continue polling.
214	201 — Émise/Issued	Sovos forwarded invoice to buyer PA-R.	Wait — optional, may not arrive.
215	202 — Reçue/Received	Buyer PA-R confirmed receipt.	Wait — optional, may not arrive.
216	203 — Made available	Invoice delivered to buyer.	Buyer delivery confirmed — optional, may not arrive.
212	213 — Rejetée/Rejected	France schematron validation failed at PA-E or PA-R. Mandatory status — PPF is notified.	See troubleshoot section.
401	—	Technical/structural error. Sovos did not treat this as a real invoice — nothing was sent.	Fix and resubmit.

CDAR attachments

For status 211 and 212, the notification includes the official CDAR document from the PDP 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.

Troubleshoot issues

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

• SCICloudStatusCode 401 — Technical/structural failure. Sovos did not treat the document as a real invoice. Nothing was sent anywhere.

• SCICloudStatusCode 212 — France schematron validation failure. The document was considered a real invoice, so the PPF is involved. Remediation depends on which PA rejected it.

• PPF Flux 1 rejection (REJ_ codes) — The invoice reached the buyer (216), 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 means 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 212)

SCICloudStatusCode 212 means France-specific schematron validation failed — the document content does not meet the legal requirements of the reform. This is distinct from a 401: where 401 is a technical error on a document Sovos did not consider a real invoice, 212 means the document was treated as real but its legal content was found to be incorrect.

212 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 211)

The PPF already received the invoice when Déposée (211) 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 reuse.

PPF rejection of regulatory data

When Sovos receives SCICloudStatusCode 211, 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:

• If 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.

• If the error is 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.

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