Transmission phase

The transmission phase covers the act of sending an invoice from the seller's platform to the buyer's platform. All statuses in this phase are set automatically by the PAs.

214, 215, and 216 are optional. The buyer's PA is not obligated to send them, and the PPF does not receive them. Their absence does not indicate a problem.

Treatment phase

The optional business actions posted against an invoice after it has been delivered to the buyer. These actions are initiated by the buyer organization — approving, refusing, disputing, or suspending the invoice — and sometimes require a subsequent seller response. Buyers and sellers submit treatment-phase statuses as SBDs. See Lifecycle status body for the submission format.

Submitted by the seller PA

SCICloudStatusCode 211, French Code 200 (Déposée)

Issued automatically by Sovos when the invoice passes validation and is transmitted. This is the primary confirmation that the invoice is in the system. The PPF has received a copy of the regulatory data (Flux 1), and the invoice is now a legal document. After this point it cannot be corrected and resubmitted. Any correction requires cancelling the original and issuing a new invoice.

See Send invoices for full detail.

Rejected by the seller PA or buyer PA

SCICloudStatusCode 212, French Code 213 (Rejetée)

Set by the seller's PA or the buyer's PA when functional validation fails. A rejection reason code is always present. Because Rejetée is mandatory, it is reported to the PPF.

See Send invoices for full remediation guidance depending on which PA rejected and whether the PPF had already received the invoice.

Refused by the buyer

SCICloudStatusCode 405, French Code 210 (Refusée)

The buyer refuses the invoice or credit note in its entirety. A reason code is required. Because Refusée is mandatory, it is reported to the PPF.

When a buyer sends Refusée, the seller must cancel the invoice in their accounting records by creating an internal credit note (avoir interne). This credit note is for accounting purposes only and must not be submitted to Sovos.

Once the accounting entry is cancelled, the seller may issue a corrected invoice as a new document.

Payment received by the seller

SCICloudStatusCode 220, French Code 212 (Encaissée)

In France, VAT on services is due when payment is received by default, not at invoice date. Sellers can elect TVA sur débits to make VAT due at invoice date instead, which is the same rule that applies to goods.

Encaissée is mandatory and reported to the PPF for the following scenarios.

• Service invoices where the seller has not elected TVA sur débits.

• Down payment invoices subject to the same VAT-on-collection rule.

Submit as soon as payment is reconciled. Encaissée does not apply to goods invoices, services where the seller has elected TVA sur débits, or intra-community and reverse charge transactions.

The seller may optionally send Encaissée outside the mandatory scope to notify the buyer of payment receipt. In that case it is transmitted to the buyer only, not to the PPF.

For a full overview of which transaction types require after-the-fact payment reporting compared to a lifecycle status, see E-reporting.

Seller cancels with corrective invoice (Annulée)

When a seller issues a corrective invoice that fully replaces a prior invoice, the original invoice's lifecycle is formally closed with an Annulée status. This status is not in the 200-213 reform code range. It is a specific treatment applied to the original invoice when its replacement is submitted.

How to handle mandatory and common statuses

Submit through the 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"
}

Include a unique x-correlationId on every request. This value is required when contacting support about a specific submission.

Success Response: HTTP 202 Accepted.

A 202 confirms Sovos received the SBD. It does not mean the status has been validated or delivered. Track the outcome through notifications.

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 during any PPF unavailability are retried automatically. Do not resubmit.

Retrieve notifications

Notifications provide status updates as the lifecycle status progresses. 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 the 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 acknowledgment.

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

Response lifecycle

After submission, Sovos validates the CDAR and routes it to the counterparty's PA. A lifecycle status workflow follows this pattern:

Submit → Sovos validates → Sovos routes to counterparty PA → PPF validates mandatory statuses

Success path: 102 → 221
Failure paths: 401 (fix and resubmit) or 221 → PPF rejection notification (fix and resubmit)

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.

Troubleshoot issues

SCICloudStatus 401 — Validation failure

A 401 notification contains multiple 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>ProcessConditionCode 212 requires PaymentAmount to be present</cbc:StatusReason>
</cac:Status>

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

Common causes of 401 on lifecycle status submissions:

• Missing or incorrect invoice reference (invoice number, issue date, or seller SIREN do not match the original invoice).

• Missing reason code on Rejetée (213) or Refusée (210).

• Invalid ProcessConditionCode value.

• Malformed CDAR structure or missing required SBDH scope values.

PPF rejection of mandatory statuses

For the four statuses mandatory to the PPF (Déposée, Rejetée, Refusée, and Encaissée), Sovos forwards your CDAR to the PPF after its own validation passes. The PPF then performs a second layer of validation and may reject the status with one or more rejection reason codes. This rejection arrives as a follow-up notification after you have already received SCICloudStatusCode 221.

These codes are distinct from the Sovos validation errors (SCICloudStatusCode 401). A PPF rejection means the CDAR passed Sovos validation but failed the PPF's functional checks.

REJ_ENCAISSEMENT applies specifically to Encaissée statuses where the payment amount submitted does not reconcile with the VAT rate breakdown on the original invoice.

For all PPF rejections, correct the CDAR and resubmit. The original mandatory status obligation remains. A PPF-rejected Encaissée or Refusée must be resubmitted with corrected data.