Send e-reports

E-reporting transmits transaction and payment data summaries to French tax authorities for transactions outside the B2B domestic e-invoicing scope. E-reports are submitted per SIREN, not per establishment (SIRET).

Sovos uses a pass-through method in which you prepare the e-report per tax authority specifications and Sovos transmits your data directly to the PPF with minimal transformation. In the future, Sovos will launch a second method to automatically generate reports from documents submitted for e-reporting.

E-reporting vs e-invoicing


Aspect	E-invoicing	E-reporting
Scope	B2B domestic (both parties VAT-registered in France)	B2C, cross-border B2B, out-of-scope
Format	Full invoice (UBL/CII)	Flow 10 transaction data (XML)
Recipient	Buyer's PDP via Annuaire	PPF (Tax Authority)
Submission	One SBD per invoice	One SBD per reporting period
Report.Type	N/A	FR_Reporting_Flow10

Both e-invoicing and e-reporting can apply to your business. Use e-invoicing for French B2B customers and e-reporting for B2C or cross-border transactions.

Suppliers: Must e-report for B2C transactions (sales to consumers or non-VAT entities), cross-border B2B transactions (where at least one party is outside France), and out-of-scope supplies such as exempt transactions or margin scheme sales.
Buyers: Must e-report for imports with reverse charge, intra-community acquisitions, and purchases from non-VAT registered suppliers.

Flow 10 report types

Flow 10 is the French government-defined XML format for transmitting transaction and payment data to the PPF.

Flow 10 has four data block types:


Flow	What you're reporting	Who/What	Report frequency
10.1	Invoice data	B2B international transactions	Individual detail per invoice
10.2	Payment data	B2B international transactions	Individual detail per payment
10.3	Invoice data	B2C transactions	Daily aggregates
10.4	Payment data	B2C transactions	Daily aggregates

B2B International scenario:
- Use flows 10.1 and 10.2.
- You have cross-border B2B transactions (at least one party outside France).
- Submit individual invoice detail (Flow 10.1).
- Submit individual payment detail for services (Flow 10.2).
- Each invoice and payment is reported separately.
B2C scenario:
- Use flows 10.3 and 10.4.
- You have consumer sales or transactions with non-VAT entities.
- Submit daily aggregated transaction data (Flow 10.3).
- Submit daily aggregated payment data for services (Flow 10.4).
- Data is summarized by date, currency, and transaction category.

Go to Report structures for more detail.

Note:

Both report types support rectification (TypeCode=RE) when you need to correct previously submitted data. See Rectification Reports section for details.

Reporting periods and deadlines

Reporting frequency depends on your VAT regime. Transaction data and payment data have separate periods and deadlines.


VAT regime	Transaction Data - Period	Transaction Data - Deadline	Payment Data - Period	Payment Data - Deadline
Monthly normal	10-day period (décade): 1-10, 11-20, 21-end of month	10 days after period end: 20th, end of month, 10th of following month	Monthly	10th of following month
Quarterly normal	Monthly	10th of following month	Monthly	10th of following month
Simplified VAT	Monthly	Between 25th-30th of following month	Monthly	Between 25th-30th of following month
VAT exemption scheme	Bimonthly (every 2 months)	Between 25th-30th of following month	Bimonthly (every 2 months)	Between 25th-30th of following month

Before you start

PPF connectivity status

Test environment (UAT): Sovos UAT environment connects to a Sovos-built mock that simulates PPF responses. This mock validates Flow 10 format and structure but may not replicate all PPF validation scenarios.
Production environment: Full PPF connection with complete validation available when mandate becomes effective (September 2026).

Data preparation

Identify which transactions require 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/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/10.2)

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

CategoryCode values for B2C aggregates


Code	Description	Use case
TLB1	Delivery of goods subject to VAT	Retail goods sales
TPS1	Provision of services subject to VAT	Services to consumers
TNT1	Goods/services not subject to French VAT	Exempt supplies, intra-community distance sales
TMA1	Margin scheme transactions	Travel agencies, second-hand goods, art/antiques

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.

Configure e-reporting

The e-reporting product must be added to your organization before you can submit reports. Contact Sovos to enable the France e-reporting product for your organization.

To set up ERP system for e-reporting, create a dedicated ERP System ID specifically for e-reporting:

Go to ERP Setup in Settings.
Create a new ERP System ID specifically for e-reporting (For example, "ERP_eReporting").
Under Communication Method, choose polling or pushing V2 (Beta).

Under Event Mapping - Optional, configure the following events:


Select event	Attachment
Validated	No attachments
Error	No attachments
Transmitted	No attachments
Report received by tax authority	LegalResponse
Report notification was not received by tax authority	LegalResponse
Report accepted by tax authority	LegalResponse
Report rejected by tax authority	LegalResponse

Note:

If events are not configured, you will not receive notifications for status updates. Event configuration is required for e-reporting workflows.

Create and submit a report

SBDH configuration

Critical SBDH fields for e-reporting:


SBDH element	Value	Notes
Sender.Identifier	Your SIREN (9 digits)	Authority="FR"
DocumentIdentification.Standard	urn.cpro.gouv.fr:1p0:ereporting	Flow 10 schema
DocumentIdentification.Type	Flow10	Document type
Scope: Country	FR	France
Scope: CompanyCode	Your SIREN	Reporting party
Scope: ProcessType	Outbound	Always outbound
Scope: Mapping.OutputSchema	Report	Triggers e-reporting routing
Scope: BusinessService.BusinessServiceName	Reporting	Distinguishes from e-invoicing
Scope: Report.Type	FR_Reporting_Flow10	Determines content type
Scope: SenderDocumentId	Unique report ID	Recommend ERP reference
Scope: SenderSystemId	Your ERP system ID, defined during setup	For example: "ERP_eReporting"

Check complete SBDH examples in the Complete Examples section and see how to create a Standard Business Document to learn more about the overall structure of it.

Note:

The Flow 10 schema version referenced in this guide is Version 3.1. The PPF publishes schema updates at https://www.impots.gouv.fr/specifications-externes-b2b. Monitor this page for new versions and update your implementation accordingly.

Embedding Flow 10 data

Flow 10 XML must be Base64-encoded and embedded in the SovosDocument structure. The Flow 10 XML contains three main sections:

ReportDocument: Identifies the report, parties, and role (seller or buyer).
TransactionsReport: Transaction/invoice data (optional).
PaymentsReport: Payment data (optional).

At least one of TransactionsReport or PaymentsReport should be present.

xml
<svs:SovosDocument>
  <svs:SovosLegalDocument>
    <enc:Base64Document>
      <enc:EmbeddedDocument id="123456789" 
                           fileName="report_flow10.xml" 
                           mimeCode="application/xml">
        [Base64-encoded Flow 10 XML - 5 MB limit]
      </enc:EmbeddedDocument>
    </enc:Base64Document>
  </svs:SovosLegalDocument>
</svs:SovosDocument>

Note:

The complete request payload must not exceed 5 MB. This limit is imposed by the Sovos API gateway and applies to the full request including the SBDH envelope and Base64-encoded Flow 10 XML. See API limits for details. If your data volume approaches this limit, split into multiple reports using separate SenderDocumentId values, multiple submissions per period per SIREN are supported.

Report structures

The content and structure of transaction and payment reports are dictated by the French tax authority. For complete schema and structure references, see the official Flow 10 specifications.

Go to https://www.impots.gouv.fr/specifications-externes-b2b.
Download the most recent version.
Open the zip file.
Open the folder structure: [3-XSD...]/[1-E-reporting] for .xsd files outlining schema and structure.

ReportDocument header

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


Field	Required	Description	Values/Format
Id	Yes	Unique report identifier	Your report reference (For example, MC_0001)
Name	No	Report name	Optional descriptor
IssueDateTime/DateTimeString	Yes	Report creation timestamp	YYYYMMDDHHmmss format
TypeCode	Yes	Submission type	IN (initial) or RE (rectification)
Sender	Yes	Platform information	Sovos provides these values
Sender/Id	Yes	Platform matricule	4 characters, schemeId="0238"
Sender/Name	Yes	Platform name	Platform company name
Sender/RoleCode	Yes	Platform role	WK (approved platform)
Sender/URIUniversalCommunication/URIID	Yes	Platform email	CEF network address
Issuer	Yes	Your company information	Company submitting the report
Issuer/Id	Yes	Your SIREN	9 digits, schemeId="0002"
Issuer/Name	Yes	Your company name	Legal company name
Issuer/RoleCode	Yes	Your reporting role	SE (seller) or BY (buyer)
Issuer/URIUniversalCommunication/URIID	Yes	Your email	CEF network address

Understanding RoleCode

The Issuer/RoleCode determines your reporting perspective and is critical for compliance:

SE (Seller): Use when reporting transactions where you are the seller.
- B2C sales to consumers
- Cross-border B2B sales (exports)
- Sales to non-VAT registered entities
BY (Buyer): Use when reporting transactions where you are the buyer.
- Imports with reverse charge VAT
- Intra-community acquisitions
- Purchases from non-VAT registered suppliers

Important:

If your company has both seller and buyer e-reporting obligations for the same period, you must submit two separate reports with different RoleCodes. For example, a French company that exports goods (SE) and also imports with reverse charge (BY) would submit two transaction reports: one with Issuer/RoleCode=SE and one with Issuer/RoleCode=BY.

Sample ReportDocument structure

xml
<Report>
  <ReportDocument>
    <Id>MC_0001</Id>
    <Name>REP-MC_0001</Name>
    <IssueDateTime>
      <DateTimeString>20251119123000</DateTimeString>
    </IssueDateTime>
    <TypeCode>IN</TypeCode>
    <Sender>
      <Id schemeId="0238">0201</Id>
      <Name>PDP_0201</Name>
      <RoleCode>WK</RoleCode>
      <URIUniversalCommunication>
        <URIID>PDP_0201@pdp.fr</URIID>
      </URIUniversalCommunication>
    </Sender>
    <Issuer>
      <Id schemeId="0002">331062130</Id>
      <Name>FOURNISSEUR</Name>
      <RoleCode>SE</RoleCode>
      <URIUniversalCommunication>
        <URIID>fournisseur@fournisseur.com</URIID>
      </URIUniversalCommunication>
    </Issuer>
  </ReportDocument>
  <!-- Followed by <TransactionsReport> and/or <PaymentsReport> -->
</Report>

Flow 10.1 - B2B International Invoices

Contains individual <Invoice> elements for cross-border B2B transactions where at least one party is outside France:

xml
<TransactionsReport>
  <ReportPeriod>
    <StartDate>20251001</StartDate>
    <EndDate>20251031</EndDate>
  </ReportPeriod>
  <Invoice>
    <ID>S1F1_REPORT2025_xxx</ID>
    <IssueDate>20250901</IssueDate>
    <TypeCode>380</TypeCode>
    <CurrencyCode>EUR</CurrencyCode>
    <Seller>
      <CompanyId schemeId="0002">100000009</CompanyId>
      <TaxRegistrationId qualifyingId="VAT">FR99999999999</TaxRegistrationId>
      <PostalAddress><CountryId>FR</CountryId></PostalAddress>
    </Seller>
    <Buyer>
      <CompanyId schemeId="0002">200000008</CompanyId>
      <TaxRegistrationId qualifyingId="VAT">IT00987654321</TaxRegistrationId>
      <PostalAddress><CountryId>IT</CountryId></PostalAddress>
    </Buyer>
    <MonetaryTotal>
      <TaxExclusiveAmount>10000.00</TaxExclusiveAmount>
      <TaxAmount CurrencyCode="EUR">0</TaxAmount>
    </MonetaryTotal>
    <TaxSubTotal>
      <TaxableAmount>10000.00</TaxableAmount>
      <TaxAmount>0</TaxAmount>
      <TaxCategory>
        <Code>E</Code>
        <Percent>0.00</Percent>
        <TaxExemptionReasonCode>VATEX-EU-151</TaxExemptionReasonCode>
      </TaxCategory>
    </TaxSubTotal>
  </Invoice>
  <!-- Repeat <Invoice> for each B2B international invoice -->
</TransactionsReport>

Flow 10.2 - B2B International Payments

Contains individual <Invoice> elements with payment data for services:

xml
<PaymentsReport>
  <ReportPeriod>
    <StartDate>20251001</StartDate>
    <EndDate>20251031</EndDate>
  </ReportPeriod>
  <Invoice>
    <InvoiceID>S2F3_REPORT2025_xxx</InvoiceID>
    <IssueDate>20250903</IssueDate>
    <Payment>
      <Date>20251030</Date>
      <SubTotals>
        <TaxPercent>0</TaxPercent>
        <CurrencyCode>EUR</CurrencyCode>
        <Amount>30000.00</Amount>
      </SubTotals>
    </Payment>
  </Invoice>
  <!-- Repeat <Invoice> for each paid invoice -->
</PaymentsReport>

Flow 10.3 - B2C Transaction Aggregates

Contains aggregated <Transactions> elements representing daily summaries:

xml
<TransactionsReport>
  <ReportPeriod>
    <StartDate>20251001</StartDate>
    <EndDate>20251031</EndDate>
  </ReportPeriod>
  <Transactions>
    <Date>20250922</Date>
    <TransactionsCurrency>EUR</TransactionsCurrency>
    <CategoryCode>TLB1</CategoryCode>
    <TaxExclusiveAmount>10000</TaxExclusiveAmount>
    <TaxTotal>2000</TaxTotal>
    <TransactionsCount>100</TransactionsCount>
    <TaxSubtotal>
      <TaxPercent>20</TaxPercent>
      <TaxableAmount>10000</TaxableAmount>
      <TaxTotal>2000</TaxTotal>
    </TaxSubtotal>
  </Transactions>
  <!-- One <Transactions> element per day/currency/category combination -->
</TransactionsReport>

Flow 10.4 - B2C Payment Aggregates

Contains aggregated <Transactions> with payment data:

xml
<PaymentsReport>
  <ReportPeriod>...</ReportPeriod>
  <Transactions>
    <Payment>
      <Date>20250922</Date>
      <SubTotals>
        <TaxPercent>20</TaxPercent>
        <Amount>20000</Amount>
      </SubTotals>
    </Payment>
  </Transactions>
</PaymentsReport>

Rectification reports

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
Contains corrected data for entire period (not just changes)

When to rectify

To correct errors in a previously ACCEPTED report (one that received status 228).
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.

Note that earlier versions of France-defined schema included a reference to the original report ID number. The tax authority has since simplified the rectification structure; no explicit reference to the original report ID is required in the XML payload.

Example

xml
<ReportDocument>
  <Id>MC_0002</Id>
  <TypeCode>RE</TypeCode>
  <!-- Standard ReportDocument fields -->
</ReportDocument>
<TransactionsReport>
  <!-- Complete corrected data for entire period -->
</TransactionsReport>

Submitting through API

Endpoint

POST /v1/documents

Request

json
{
  "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.

Handle application responses

Response lifecycle

After submission, track status progression through notifications. The workflow follows this pattern:

Submit → Sovos validates → Sovos transmits → PPF validates → Final status

Success path: 102 → 104 → 228 ✅  or  102 → 104 → 235 → 228 ✅
Failure paths: 401 (fix and resubmit) or 104 → 407 (submit rectification)

Note:

PPF availability is outside Sovos' control. During PPF maintenance or incidents, monitor the French tax authority channels at https://www.impots.gouv.fr for official communications. Submissions accepted by Sovos during PPF unavailability will be retried automatically; continue polling for notifications and do not resubmit.

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

When you receive a notification, check sciCloudStatusCode:

Decision logic:


Code status	Action
`401`	Fix and resubmit immediately
`102`	Wait (validation passed)
`104`	Wait (transmitted to PPF)
`235`	Wait for final status
`228`	✅Success; archive confirmation
`234`	Wait (Not received. Sovos retries)
`407`	Decode PPF response, correct data issues, then: If this was `initial submission` (IN) that was rejected: resubmit corrected report with TypeCode=IN. If this was rectification (RE) that was rejected: fix and resubmit with TypeCode=RE.

Status code reference


SCICloudStatusCode	PPF code	Meaning	What happens next	Action required
`102`	N/A	Sovos validation passed	Sovos will transmit to PPF (expect status 104)	Wait
`104`	N/A	Transmitted to PPF	PPF performs validations	Wait for PPF response
`228`	300	PPF accepted report	Workflow complete	Archive confirmation
`235`	500	PPF received, processing	PPF still validating	Wait for final status (228 or 407)
`234`	501	PPF did not receive	File packaging error	Sovos automatically retries
`401`	N/A	Sovos validation failed	Check notification for error details	Fix XML or SBDH errors and resubmit. See Validation Errors (Status 401) troubleshooting.
`407`	301	PPF rejected report	Sovos notification contains parsed error details from PPF	Review Sovos error codes in notification, correct data issues. If this was your first submission attempt for the period, fix and resubmit with TypeCode=IN. If correcting a previously accepted report, submit TypeCode=RE.

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. Its authoritative XSD is available at https://unece.org/trade/documents/2024/12/standards/cross-domain-acknowledgement-and-response-d22b and the French implementation profile is in AFNOR XP Z12-012, downloadable from https://www.impots.gouv.fr/specifications-externes-b2b.

Note:

Status 228 and 407 responses include the official PPF response document (CDAR format) attached to the notification. Sovos interprets these response documents and shows all necessary information in Sovos status codes. You can optionally download these attachments for your records.

Acknowledging notifications

Mark notifications as read after processing:

PUT /v1/notifications/{notificationId}/markAsRead

Troubleshoot issues

Validation errors (Status 401)

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

xml
<!-- High-level workflow status (matches Status Code Reference table) -->
<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>Error processing document</cbc:StatusReason>
</cac:Status>

<!-- Detailed validation errors (one per error found) -->
<cac:Status>
  <cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>The element 'AllowanceCharge' has invalid child element 'Tax'. 
  List of possible elements expected: 'TaxCategoryCode, TaxPercent'.</cbc:StatusReason>
</cac:Status>
<cac:Status>
  <cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
  <cbc:StatusReason>The element 'Line' has invalid child element 'AllowanceCharge'. 
  List of possible elements expected: 'Product'.</cbc:StatusReason>
</cac:Status>

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

Sovos pre-validates your report before transmitting to the tax authority, with the same rule set used by 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 receives 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 indicates 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:


Code	Control type	Description
REJ_SEMAN	Semantic format control	Data format does not conform to semantic requirements.
REJ_UNI	Uniqueness control	Data has already been transmitted and processed.
REJ_COH	Data coherence control	One or more data elements are incoherent.
REJ_PER	Period control	Transmission date not coherent with declared period.

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 navigate to the [3-XSD...]/[1-E-reporting] folder for the Flow 10 XSD files.

Complete examples

The sample files referenced below are complete, production-ready Standard Business Document (SBD) payloads in the exact format required for POST /v1/documents submission. Each sample contains a full SBDH wrapper with the Flow 10 XML Base64-encoded inside the <enc:EmbeddedDocument> element.

To inspect the Flow 10 structure, decode the Base64 content from the <enc:EmbeddedDocument> tag to view the complete ReportDocument header, TransactionsReport/PaymentsReport sections, and all data elements. This encoding matches the production format; your payloads must also Base64-encode Flow 10 data before embedding.

These samples can be submitted directly to test the complete workflow. To use them with your own data, decode the embedded Flow 10 XML, replace it with your transaction/payment information, re-encode, update the SBDH identification fields, and submit.

Example 1: Transaction Report Combining B2B and B2C (Flows 10.1 and 10.3)

Scenario

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

Sample

Download complete sample

SBDH configuration

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

Structure

Contains 1 <Invoice> element with complete B2B international invoice details including seller/buyer information, delivery address, line items, and tax breakdown (Flow 10.1).
Contains 2 <Transactions> elements representing daily B2C aggregates:
- September 22: TLB1 (goods) - 100 transactions, €10,000 net, €2,000 VAT at 20%.
- 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)

Scenario

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

Sample

Download complete sample

SBDH configuration

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

Structure

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

Example 3: Rectification Report

Scenario

October transaction report contained errors, submitting correction in November.

Sample

Download complete sample

Key differences

TypeCode: RE (not IN)
Contains complete corrected data for October period
Otherwise identical SBDH structure and Report.Type

Note:

Sample files may contain <References> elements from earlier schema versions. The current Flow 10 schema (v3.1) does not include References in ReportDocument. Omit this element when building rectification reports.

Sample application responses

PPF response attachments (Optional)

Application responses for statuses 228 and 407 include the official PPF response document (CDAR format) as an attachment. The attachment is located in the response structure as follows:

xml
<ApplicationResponse>
  <cac:DocumentResponse>
    <cac:Response>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">228</cbc:StatusReasonCode>
        <cbc:StatusReason>Report accepted by Tax Authority</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
    <cac:DocumentReference>
      <cbc:ID>[document_id]</cbc:ID>
      <cbc:DocumentTypeCode>LegalResponse</cbc:DocumentTypeCode>
      <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="application/xml">
          [Base64-encoded PPF response in CDAR format]
        </cbc:EmbeddedDocumentBinaryObject>
      </cac:Attachment>
    </cac:DocumentReference>
  </cac:DocumentResponse>
</ApplicationResponse>

You can optionally download these attachments for your records. The attachment contains a CDAR message with two key sections:

Acknowledgment block: References your submitted report and contains the ProcessConditionCode; 300 for accepted (status 228) or 301 for rejected (status 407).
Status detail block: Present on rejections (status 407) only. Repeatable, one entry per error. Each entry identifies the business rule code that triggered the rejection, the name of the invalid field, and a human-readable error message.

Validation Success (Status 102)

Sample: App_Response_102_Validation_ok.xml

xml
<cac:Status>
  <cbc:StatusReasonCode listID="SCICloudStatusCode">102</cbc:StatusReasonCode>
  <cbc:StatusReason>Document validated successfully</cbc:StatusReason>
</cac:Status>
<cac:Status>
  <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
  <cbc:StatusReason>No action required</cbc:StatusReason>
</cac:Status>

Validation Failure (Status 401)

Sample: App_Response_401_Validation_nok.xml

Contains multiple status elements describing each validation error:

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

Review all status elements, fix issues, and resubmit.

Transmitted to PPF (Status 104)

Sample: App_Response_104_Transmitted.xml

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

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

May include embedded PPF acknowledgment in Base64 format within DocumentReference/Attachment.

Integration Failure (Status 407)

Sample: App_Response_407_Not_Integrated.xml

Contains embedded PPF rejection response. Decode Base64 content from EmbeddedDocumentBinaryObject to access PPF error codes.

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 indicates PPF has received the report and is still validating. No action is required. The expected progression is 228 (accepted) or 407 (rejected).

xml
<cac:Status>
	<cbc:StatusReasonCode listID="SCICloudStatusCode">235</cbc:StatusReasonCode>
	<cbc:StatusReason>Report received by Tax Authority</cbc:StatusReason>
</cac:Status>
<cac:Status>
	<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
	<cbc:StatusReason>No action required</cbc:StatusReason>
</cac:Status>

Not Received by PPF (Status 234)

Sample: App_Response_234_Not_Received.xml

Status 234 indicates the report was transmitted but not received by PPF due to a rare connectivity issue. No action is required; Sovos retries automatically. Processing will resume and you can expect a subsequent 228 or 407 notification.

xml
<cac:Status>
	<cbc:StatusReasonCode listID="SCICloudStatusCode">234</cbc:StatusReasonCode>
	<cbc:StatusReason>Report was not notification received 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>

Sovos Docs

Send e-reports

E-reporting vs e-invoicing

Flow 10 report types

Reporting periods and deadlines

Before you start

PPF connectivity status

Data preparation

Configure e-reporting

Create and submit a report

SBDH configuration

Embedding Flow 10 data

Report structures

Rectification reports

Submitting through API

Handle application responses

Response lifecycle

Retrieving notifications

Response handling decision tree

Status code reference

Acknowledging notifications

Troubleshoot issues

Validation errors (Status 401)

Integration errors (Status 407)

PPF rejection reason codes

Complete examples

Example 1: Transaction Report Combining B2B and B2C (Flows 10.1 and 10.3)

Example 2: Payment Report Combining B2B and B2C (Flows 10.2 and 10.4)

Example 3: Rectification Report

Sample application responses

PPF response attachments (Optional)

Validation Success (Status 102)

Validation Failure (Status 401)

Transmitted to PPF (Status 104)

Integration Success (Status 228)

Integration Failure (Status 407)

Received by PPF (Status 235)

Not Received by PPF (Status 234)

sovos-footer