Pass-through

In pass-through, you build the complete Flow 10 XML report internally and submit it as a ready-made payload. Sovos validates the report against the Flow 10 schema and sends it directly to the PPF.

Key characteristics:

You control timing

No scheduler; you decide when to submit.

SBDH routing

DocumentIdentification.Type = Flow10, Mapping.OutputSchema = Report, Report.Type = FR_Reporting_Flow10.

Responsibility

You are responsible for aggregating transaction data, calculating period totals, and constructing the XML.

Consolidation

In consolidation, you submit individual documents to Sovos across four input types:

• B2B transaction invoices (UBL, CII, or SCI).

• B2B payment receipts (CDAR).

• B2C daily transaction aggregates (ReportTransactions XML).

• B2C daily payment aggregates (CDAR).

Sovos stores the documents, then generates, validates, and sends the Flow 10 report to the PPF at the right time for your tax regime.

Key characteristics:

Sovos manages timing

A scheduler runs per your tax regime and generates Flow 10 (flows 10.1-10.4).

Customer buffer period

After each reporting period closes, a buffer period lets you add or remove documents. The length of the buffer depends on your VAT regime.

System period lock

Sovos locks the period for consolidation. No additions or removals are allowed once generation starts.

SBDH routing

Mapping.OutputSchema is set to one of:

• TransactionB2B

• TransactionB2C

• PaymentsB2B

• PaymentsB2C

See Document types and SBDH routing for the full table.

Consolidation end-to-end flow

Each document you submit passes through five stages before it is included in a Flow 10 report.

Stage 1: You submit a document

Use POST /v1/documents to submit one of the supported document types:

• B2B transaction invoice (UBL, CII, or SCI coreset).

• B2B payment received in CDAR format.

• B2C daily transaction aggregate in ReportTransactions XML format.

• B2C daily payment aggregate in CDAR format.

The SBDH DocumentIdentification.Type is Consolidation for all four types.

Stage 2: Sovos validates the document

Sovos runs schematron validation and France-specific BR-FR business rules against the document. If validation fails, you get a status 401 notification. Fix the document and resubmit. The document is not stored until it passes validation.

Stage 3: Reporting service stores the document

The validated document is stored and linked to your SIREN and the applicable reporting period. It remains available for addition or removal during the reporting period and the five-day customer buffer that follows it.

Stage 4: Scheduler generates Flow 10

At the end of your system period, the Sovos scheduler generates the Flow 10 XML (flows 10.1-10.4 as applicable) from all stored documents for that SIREN and period. Generation timing is based on your set-up VAT regime and the statutory deadline. See Reporting periods and deadlines.

Stage 5: Schema validation and sending to DGFiP

Sovos validates the generated Flow 10 against the PPF schema, then sends it to the DGFiP. You get status notifications as the report moves through the PPF pipeline. See Handle application responses.

Sovos validation fails → 401  (fix and resubmit)

Sovos validation passes → 102
  → 104 (sent to PPF)
      → 235 (PPF received, processing — wait for 228 or 407)
      	 → 234 (PPF did not receive — Sovos handles)
     	 → 407 (PPF rejected — fix errors and resubmit)
     	 → 228 ✅ (PPF accepted — workflow complete)

Buffer and system periods

Error recovery during system period

Network errors cause automatic retries. A generation failure sets an error status and unlocks the period for modification. Manual re-trigger is available for sending failures.

Consolidation product bundles

Sovos uses the following product bundles internally to route each consolidation document stream. These are platform-side identifiers and do not appear in your SBDH setup.

No action is needed unless Sovos support has told you to reference a specific product bundle in your setup.

Pass-through SBDH fields

For pass-through, you submit one fully constructed Flow 10 XML per reporting period.

Consolidation SBDH fields

For consolidation, you submit one document at a time. The DocumentIdentification.Type is always Consolidation. The Mapping.OutputSchema, Report.Type, and MetaSchema values vary by document type as shown below.

Fields common to all consolidation submissions:

Per-document-type SBDH scope values:

PPF connectivity status

Test environment (UAT)

Sovos UAT connects to a Sovos-built mock that simulates PPF responses. This mock validates Flow 10 format and structure but might not replicate all PPF validation scenarios.

Production environment

Full PPF connection with complete validation is available. Sovos is currently in the pilot phase with the PPF.

Data preparation

Identify which transactions need e-reporting rather than e-invoicing. Cross-border B2B and B2C transactions fall under e-reporting, while domestic B2B between French VAT-registered entities use e-invoicing.

B2C data (flows 10.3 and 10.4)

Aggregate transactions by date, currency, and category. Calculate daily totals per tax rate and currency. Transaction count is optional. Separate goods (TLB1) from services (TPS1) since payment reporting applies only to services.

B2B international data (flows 10.1 and 10.2)

Keep individual invoice and payment details per transaction. Track payment dates when VAT is due on collection.

Seller VAT number (BT-48)

The seller's international VAT number, shown in Flow 10 as <TaxRegistrationId> within the <Seller> block, is optional. The French mandate needs only the SIREN, given in <CompanyId>. You do not need to include <TaxRegistrationId> in your reports.

Note:

The French international VAT number (BT-48) follows the format: FR + 2 check digits + 9-digit SIREN, for a total of 13 characters. This is distinct from the SIREN alone. For example, a company with SIREN 123456789 would have a VAT number in the form FRxx123456789, where xx represents the calculated check digits. If you include <TaxRegistrationId> in your submission, Sovos validates the value.

CategoryCode values for B2C aggregates:

For transactions that include both goods and services, categorize based on the primary operation. For example, if a customer buys a suit and the tailor includes alterations as part of the sale, the entire transaction is categorized as goods (TLB1) since alterations are incidental to the suit purchase. However, if alterations are sold independently from a garment purchase, they are categorized as services (TPS1). When goods and services are truly independent in the same transaction, create separate <Transactions> entries for each category.

SBDH setup

The SBDH wraps every submission, whether pass-through or consolidation. The key differences between the two methods are the value of DocumentIdentification.Type, Mapping.OutputSchema, and Report.Type.

Critical SBDH fields: pass-through:

Critical SBDH fields: consolidation (B2B UBL example):

Consolidation SBDH sample: B2B UBL outbound:

<?xml version="1.0" encoding="UTF-8"?>
<sbd:StandardBusinessDocument xmlns:sbd="...">
  <sbd:StandardBusinessDocumentHeader>
    <sbd:Sender>
      <sbd:Identifier Authority="FR">100000008</sbd:Identifier>
    </sbd:Sender>
    <sbd:DocumentIdentification>
      <sbd:Standard>urn.cpro.gouv.fr:1p0:ereporting</sbd:Standard>
      <sbd:TypeVersion>1.0</sbd:TypeVersion>
      <sbd:Type>Consolidation</sbd:Type>
      <sbd:MultipleType>false</sbd:MultipleType>
      <sbd:CreationDateAndTime>2024-05-15T10:30:00Z</sbd:CreationDateAndTime>
    </sbd:DocumentIdentification>
    <sbd:BusinessScope>
      <sbd:Scope><sbd:Type>Version</sbd:Type><sbd:Identifier>1.0</sbd:Identifier></sbd:Scope>
      <sbd:Scope><sbd:Type>Country</sbd:Type><sbd:Identifier>FR</sbd:Identifier></sbd:Scope>
      <sbd:Scope><sbd:Type>CompanyCode</sbd:Type><sbd:Identifier>100000008</sbd:Identifier></sbd:Scope>
      <sbd:Scope><sbd:Type>Mapping.OutputSchema</sbd:Type><sbd:Identifier>TransactionB2B</sbd:Identifier></sbd:Scope>
      <sbd:Scope><sbd:Type>Report Type</sbd:Type><sbd:Identifier>FR_Reporting_Transaction_UBL</sbd:Identifier></sbd:Scope>
      <sbd:Scope><sbd:Type>MetaSchema</sbd:Type><sbd:Identifier>outbound</sbd:Identifier></sbd:Scope>
    </sbd:BusinessScope>
  </sbd:StandardBusinessDocumentHeader>
</sbd:StandardBusinessDocument>

B2C input format for consolidation: ReportTransactions XML

When submitting B2C transactions for consolidation, use the Sovos-defined ReportTransactions XML format. This is the payload you Base64-encode and embed in the <enc:EmbeddedDocument> element, with Report.Type = FR_Reporting_Transaction_B2C.

Embedding Flow 10 data (pass-through)

For pass-through submissions, Flow 10 XML must be Base64-encoded and embedded in the SovosDocument structure. The Flow 10 XML has three main sections:

ReportDocument

Identifies the report, parties, and role (seller or buyer).

TransactionsReport

Transaction and invoice data (optional).

PaymentsReport

Payment data (optional).

At least one of TransactionsReport or PaymentsReport should be present.

Report structures (pass-through)

The content and structure of transaction and payment reports follow French tax authority requirements. For complete schema and structure references, see the official Flow 10 specifications at https://www.impots.gouv.fr/specifications-externes-b2b. Download the most recent version, open the zip file, and go to the [3-XSD...]/[1-E-reporting] folder for .xsd files outlining schema and structure.

Every Flow 10 report must begin with a ReportDocument header that identifies the report and specifies the reporting role:

The Issuer/RoleCode determines your reporting perspective and is critical for compliance. Use SE (Seller) when reporting transactions where you are the seller — this covers B2C sales to consumers, cross-border B2B sales (exports), and sales to non-VAT registered entities. Use BY (Buyer) when reporting transactions where you are the buyer — this covers imports with reverse charge VAT, intra-community acquisitions, and purchases from non-VAT registered suppliers.

Rectification reports (pass-through)

Submit a rectification report (TypeCode=RE) when you discover errors in data already reported or for a closed period. Key differences from initial reports:

• <TypeCode>RE</TypeCode> instead of IN.

• Has corrected data for the entire period (not just the changes).

Rectify when you need to correct errors in a previously accepted report (one that got status 228), or when adding or removing transactions from a closed period that was successfully reported. Rectification replaces the entire period. You must resubmit all data for that period with corrections.

Submitting through API

Endpoint

POST /v1/documents

Request

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

Responses

Success response = HTTP 202 Accepted.

For the complete list of HTTP status codes, error response schema, and retry guidance, see HTTP status codes and Document endpoint specification.

If the Sovos API is unavailable, check the Sovos status page for real-time operational status and incident history. You can subscribe to email alerts directly from the page.

Response lifecycle

After submission, track status progression through notifications. Errors can occur at three distinct points: at Sovos validation, after the PPF gets the report, or after PPF processing.

Sovos validation fails → 401  (fix and resubmit)

Sovos validation passes → 102
  → 104 (sent to PPF)
      → 235 (PPF received, processing — wait for 228 or 407)
      	 → 234 (PPF did not receive — Sovos handles)
     	 → 407 (PPF rejected — fix errors and resubmit)
     	 → 228 ✅ (PPF accepted — workflow complete)

Retrieving notifications

API call

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

Parameters

taxId

Your SIREN from SBDH

sourceSystemId

Matches SenderSystemId from SBDH

processType

0 (outbound)

Response handling

When you get a notification, check sciCloudStatusCode:

Status code reference

The PPF Code column shows the corresponding ProcessConditionCode from the PPF CDAR response; 300 for accepted (status 228) and 301 for rejected (status 407). The CDAR is a UN/CEFACT D22B standard message.

Acknowledging notifications

Mark as read

Mark notifications as read after processing:

PUT
     /v1/notifications/{notificationId}/markAsRead

Validation errors (Status 401)

A 401 notification has multiple status elements. The high-level status uses SCICloudStatusCode, while detailed validation errors use SCIInternalValidationStatusCode.

Review all SCIInternalValidationStatusCode status elements for specific error details. Correct the issues in the XML and resubmit.

Sovos pre-validates your report before sending to the tax authority, using the same rule set as the PPF. To see the authoritative Flow 10 rule set, download the most recent version of the PPF external specifications from https://www.impots.gouv.fr/specifications-externes-b2b and open Annexe 7 (Règles de gestion) from the downloaded package.

Integration errors (Status 407)

When status 407 occurs, Sovos gets the PPF rejection response (CDAR format), parses it, and includes all error details in the notification. Review the Sovos error codes and messages in the notification to understand what corrections are needed.

Next steps depend on what was rejected:

• If your initial submission (TypeCode=IN) was rejected: Fix the errors and resubmit with TypeCode=IN.

• If your rectification (TypeCode=RE) was rejected: Fix the errors and resubmit with TypeCode=RE.

TypeCode shows what you're trying to do, not the outcome; a rejected initial attempt is still an initial submission.

PPF rejection reason codes

When status 407 occurs, the PPF response includes one or more rejection reason codes:

Sovos parses these codes from the PPF CDAR response and includes the error details in the StatusReason field with specific field paths and error messages.

For complete Flow 10 schema and field specifications, download the most recent version of the PPF external specifications from https://www.impots.gouv.fr/specifications-externes-b2b, open the zip file, and go to the [3-XSD...]/[1-E-reporting] folder for the Flow 10 XSD files.

Example 1: Transaction report combining B2B and B2C (flows 10.1 and 10.3)

Download complete sample

Scenario

Company reporting B2B international invoices and B2C aggregated transactions for October 2025.

SBDH setup

Report.Type FR_Reporting_Flow10, TypeCode IN (initial submission), ReportPeriod October 1-31, 2025.

Structure

One <Invoice> element with complete B2B international invoice details including seller and buyer information, delivery address, line items, and tax breakdown (Flow 10.1). Two <Transactions> elements representing daily B2C aggregates: September 22 (TLB1 goods — 100 transactions, €10,000 net, €2,000 VAT at 20%) and September 16 (TPS1 services — 100 transactions, €10,000 net, €2,000 VAT at 20%).

Example 2: Payment report combining B2B and B2C (flows 10.2 and 10.4)

Download complete sample

Scenario

Company reporting B2B international payments and B2C aggregated payments for October 2025.

SBDH setup

Report.Type FR_Reporting_Flow10, TypeCode IN (initial submission), ReportPeriod October 1-31, 2025.

Structure

Two <Invoice> elements with nested <Payment> sections for B2B international service payments (Flow 10.2): Invoice S2F3 (payment of €30,000 on October 30) and Invoice S2F4 (payment of €400,000 on October 30). Two <Transactions> elements with nested <Payment> sections for B2C payment aggregates (Flow 10.4): September 22 (€20,000 at 20% VAT) and September 16 (€20,000 at 20% VAT).

Example 3: Rectification report

Download complete sample

Scenario

October transaction report had errors; submitting correction in November.

Key differences

TypeCode RE (not IN), complete corrected data for October period, otherwise identical SBDH structure and Report.Type.

PPF response attachments (optional)

Application responses for statuses 228 and 407 include the official PPF response document (CDAR format) as an attachment. The attachment has two key sections: an acknowledgment block (references your submitted report and has the ProcessConditionCode) and a status detail block (present on rejections only — one entry per error with the business rule code, field name, and error message).

Validation success (Status 102)

Sample

App_Response_102_Validation_ok.xml

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">102</cbc:StatusReasonCode>
  <cbc:StatusReason>Document validated successfully</cbc:StatusReason>
</cac:Status>

Validation failure (Status 401)

Sample

App_Response_401_Validation_nok.xml

<cac:Status>
  <cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>The element 'AllowanceCharge' has invalid child element 'Tax'.</cbc:StatusReason>
</cac:Status>

Sent to PPF (Status 104)

Sample

App_Response_104_Transmitted.xml

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">104</cbc:StatusReasonCode>
  <cbc:StatusReason>Transmitted to the tax authority</cbc:StatusReason>
</cac:Status>

Integration success (Status 228)

Sample

App_Response_228_Integration_Ok.xml

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">228</cbc:StatusReasonCode>
  <cbc:StatusReason>Report accepted by Tax Authority</cbc:StatusReason>
</cac:Status>

Integration failure (Status 407)

Sample

App_Response_407_Not_Integrated.xml

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">407</cbc:StatusReasonCode>
  <cbc:StatusReason>Report rejected by Tax Authority</cbc:StatusReason>
</cac:Status>
<cac:Status>
  <cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
  <cbc:StatusReason>Request to re-issue a corrected new report or fix the error and resend the report</cbc:StatusReason>
</cac:Status>

Received by PPF (Status 235)

Sample

App_Response_235_Received.xml

Status 235 means the PPF has got the report and is still validating. No action is needed. The expected progression is 228 (accepted) or 407 (rejected).

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">235</cbc:StatusReasonCode>
  <cbc:StatusReason>Report received by Tax Authority</cbc:StatusReason>
</cac:Status>

Not received by PPF (Status 234)

Sample

App_Response_234_Not_Received.xml

Status 234 means the report was sent but not delivered to the PPF due to a report schema error or filename error. This error is handled by Sovos. No action is needed from you; contact Sovos support if the status does not resolve.

<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">234</cbc:StatusReasonCode>
  <cbc:StatusReason>Report was not received by Tax Authority</cbc:StatusReason>
</cac:Status>