Delivery phase

The delivery phase covers the act of sending an invoice from the seller's platform to the buyer's platform. This phase covers events initiated by the Plateforme Agréée (PA), which report the delivery of an invoice or credit note moving from the seller through the seller's PA and buyer's PA to the buyer. The PAs set all statuses in this phase automatically.

204, 214, and 215 are optional. The buyer's PA isn't compelled to send them. The PPF doesn't receive them. Their absence doesn't indicate a problem.

Treatment phase

The treatment phase covers business actions posted against an invoice after the buyer receives it. The buyer starts these actions:

• Approving the invoice

• Refusing the invoice

• Disputing the invoice

• Suspending the invoice

Some actions require a later response from the seller. Buyers and sellers submit treatment-phase statuses as SBDs. See Lifecycle status body for the submission format.

Submitted by the seller PA

SCICloudStatusCode 102, 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 (Flow 1), and the invoice is now a legal document. After this point, the invoice can't be corrected and resubmitted. Any correction requires canceling the original and issuing a new invoice.

See Send invoices for full detail.

Rejected by the seller PA or buyer PA

SCICloudStatusCode 401, 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 included. Because Rejetée is required, 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 required, 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.

After the accounting entry is cancelled, the seller can 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 (VAT on debit) to make VAT due at invoice date instead, which is the same rule that applies to goods.

Encaissée is required 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 intracommunity and reverse charge transactions.

The seller might 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 required and common statuses

SCICloudStatusCode 102 (Submitted / Déposée)

Invoice accepted and in transit. No action required, unless the status carries a NON_TRANSMISE reason code. In that case, verify that the buyer's electronic address is registered and active in the Annuaire before resubmitting.

SCICloudStatusCode 401 (Rejected / Rejetée)

As the seller, parse the reason code. See Send invoices for remediation based on which PA rejected.

SCICloudStatusCode 405 (Buyer refused / Refusée)

As the seller, create an internal credit note in your accounting records only. Don't submit it to Sovos. Issue a corrected invoice as a new document if the transaction is still valid.

SCICloudStatusCode 220 (Seller reports payment received / Encaissée)

As the buyer, reconcile against payment records.

SCICloudStatusCode 219 (Buyer is waiting for documents / Suspendue)

Buyer has placed the invoice on hold pending supporting documents. As the seller, respond with SCICloudStatusCode 206 (Complétée) and attach the requested documents.

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"
}'

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 and acknowledge 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).

After processing, mark notifications as read to prevent retrieving them again. Use the endpoint PUT /v1/notifications/FR, or configure auto-acknowledge on your ERP System ID in account setup.

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.

You can also track lifecycle status outcomes in the document detail view in the Compliance Network portal.

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 → 204
Failure paths: 401 (fix and resubmit) or 204 → 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.

PPF response for mandatory statuses

After Sovos delivers a mandatory status to the PPF (SCICloudStatusCode 204), the PPF performs its own validation and returns a result. This response arrives as a follow-up notification referencing the original lifecycle submission. A successful PPF response confirms the status is recorded by the tax authority. A PPF rejection means the CDAR passed Sovos validation but failed the PPF's functional checks.

Important:

PPF response tracking applies only to lifecycles you submit directly, as a buyer or seller. Lifecycles issued or received from platforms are not tracked in this way.

SCICloudStatus 401 — Validation failure

A 401 notification contains multiple Status elements. The top-level status uses SCICloudStatusCode. Each individual error uses SCIInternalValidationStatusCode.

CODECopy

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

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

Note: SCIInternalValidationStatusCode values are free-text error messages generated by the Sovos validation engine, not a fixed enumerated list. Each element's StatusReason field describes the specific rule or field that failed. There is no published list for these values. Read the StatusReason text directly to identify what needs to be corrected.

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

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.

Code	Check	Meaning
REJ_INC	Status consistency	One or more statuses are inconsistent with the invoice's current lifecycle state.
REJ_INEX	Status conformity	One or more statuses are incorrect or not permitted at this point in the lifecycle.
REJ_RG	Business rule	One or more business rules are not satisfied.
REJ_HAB	Authorization	The request is not authorized or requires a permission not held.
REJ_ENCAISSEMENT	Payment amount	One or more collected amounts do not match the VAT breakdown declared on the invoice.

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.