What changed at a glance

New electronic address validation rules

AFNOR v1.3 adds five groups of validation rules for electronic addresses. Earlier specification drafts defined these rules but did not enforce them. Starting with v1.38.0, Sovos enforces them using schematron validation before sending any document.

Buyer and seller electronic address presence (BR-FR-12 and BR-FR-13)

When a buyer or seller electronic address is present in the invoice, both the address value and the scheme identifier must be present together. Neither can appear without the other.

Scheme 0225 conditional rules (BR-FR-21 and BR-FR-22)

If the buyer or seller electronic address uses scheme identifier 0225 (the French Annuaire identifier), the address value must be a valid SIREN or SIRET-based identifier. Addresses using other scheme IDs are unaffected by this rule.

Electronic address format constraints (BR-FR-23 and BR-FR-24)

Electronic address values must conform to the format expected by the declared scheme. Malformed addresses, such as a value that does not match the pattern for its declared scheme, now fail validation.

Electronic address length constraints (BR-FR-25 and BR-FR-26)

Electronic address values and routing codes have the largest length constraints defined in the specification. Values exceeding these limits now cause a validation failure.

What this means for you

If you submit invoices with buyer or seller electronic addresses, verify that:

• Both the address value and scheme ID (BT-49 and BT-34 and their scheme attributes) are always present together.

• If using scheme 0225, the value is a valid SIREN (9 digits), SIREN and SIRET (14 digits), or SIREN with suffix pattern.

• Address values do not exceed the length constraints defined in the AFNOR XP Z12-012 specification.

No change is needed if you consistently supply well-formed electronic addresses. Invoices that before were accepted with malformed or incomplete addresses will now be rejected at the Sovos validation stage (status 401) before reaching the tax authority.

New article attribute and object identifier validation rules

Line-level article attribute consistency rules (BR-FR-27 to BR-FR-31)

New rules govern the consistency and format of article attribute codes and object identifiers at the invoice line level. Specifically:

• Article attribute identifiers and their values must appear together when one is present.

• Object identifiers at the line level must conform to expected format and scheme constraints.

• Rejection motifs (reason codes) are now included explicitly in the validation error for each rule, so you can identify which constraint failed.

What this means for you

If your invoices include line-level article attributes (for example, product classification codes or item property key-value pairs), verify they conform to the format and pairing needs in the AFNOR XP Z12-012 v1.3 specification. Invoices that violate these rules will get a status 401 with a specific BR-FR code identifying the failure.

Invoice ID length in e-reporting Flow 10 extended to 35 characters

Before, the invoice ID field (<ID>) within Flow 10 transaction reports accepted up to 20 characters. AFNOR v1.3 aligns with the broader European standard and extends this limit to 35 characters, matching the largest length defined in EN 16931.

What this means for you

If your invoice IDs are longer than 20 characters, you can now include them in Flow 10 reports without truncation. No action is needed if your IDs are already 20 characters or fewer.

MDT-39 payment means code now required

MDT-39 is the payment means code field within Flow 6 lifecycle statuses for payment events.

In v1.37.0, Sovos implemented a default value for MDT-39 when it is absent from incoming lifecycle data. This prevents processing failures if you omit the field.

In v1.38.0, MDT-39 is enforced as required. Submissions without it no longer fall back to a default. The field must be present in your lifecycle status payload.

What this means for you

If you send payment lifecycle statuses (for example, Encaissée events using Flow 6), verify that MDT-39 is populated in your submissions. The specific accepted values for MDT-39 are defined in the AFNOR XP Z12-012 v1.3 specification, Annexe — Listes de codes.

ProfileID (BT-23) presence check before Flow 2 generation

A new pre-generation check verifies that BT-23 (ProfileID) is present in the submitted document before Sovos attempts to generate Flow 2 (the invoice sending envelope). Before, a missing BT-23 could result in a malformed Flow 2 being generated and then rejected downstream.

What this means for you

BT-23 has always been needed for France. This change adds an explicit early check rather than failing later in the pipeline. If your submissions reliably include BT-23, no change is needed.

New mappings for BT-97, BT-98, BT-104, BT-105

AFNOR v1.3 adds explicit mapping support for four business terms that before were unmapped or only partially mapped:

These mappings apply to all supported formats: UBL, CII, and SCI (both coreset and extended).

What this means for you

If your invoices include document-level allowance or charge reason codes, these values are now correctly mapped through Sovos' internal format and will appear correctly in transformed output formats. There is no action needed; this is a transparent improvement.

UBL extended V1.1 to V1.3 gap analysis

The gap between UBL extended specification versions V1.1 and V1.3 has been implemented. This covers elements that were added or modified in the AFNOR extended profile between the two versions.

What this means for you

If you use UBL extended format, the additional elements introduced in V1.3 are now supported. Elements from V1.1 continue to work unchanged. If you are using extended elements that were only defined in V1.3, those elements will now be accepted and mapped correctly.

SCI extended full round-trip mapping

The full SCI extended to InvoiceDTO to SCI round-trip mapping is now implemented. Before, SCI extended elements were partially mapped; this update covers all extended elements defined in the AFNOR SCI extended profile.

What this means for you

If you use SCI extended format, all extended elements are now correctly preserved through Sovos' processing pipeline. No action is needed.

Updated CII extended and Factur-X extended coreset mapper

The coreset mapper for CII extended and Factur-X extended formats has been updated to reflect the AFNOR June 2026 (v1.3) specification. This includes changes to field mappings and cardinality rules for coreset elements in these formats.

What this means for you

If you use CII extended or Factur-X extended format, verify that your implementation aligns with the v1.3 coreset field needs. The specific mapping changes are documented in the AFNOR XP Z12-012 v1.3 Annexe — Format sémantique.

Factur-X PDF template updated

The Factur-X PDF rendering template has been aligned with the latest Sovos pipeline PDF rendering template. Visual layout and field placement changes may be present in generated PDFs.

What this means for you

If your workflow processes or archives Factur-X PDFs, review the updated template output for any changes that affect your downstream processing.

Additional Flow 6 lifecycle non-schematron validation rules

Additional lifecycle validation rules have been implemented for Flow 6 (CDV/CDR — correction and dispute statuses):

• Business rules governing correction lifecycle status content (BR-FR-CDV-01 through BR-FR-CDV-15).

• Code list validation for correction lifecycle statuses (BR-FR-CDV-CL-01 through BR-FR-CDV-CL-11).

• An additional cross-cutting rule for lifecycle processing (BR-FR-04).

What this means for you

If you send correction or dispute lifecycle statuses, verify that your status payloads conform to the rules defined in AFNOR XP Z12-012 v1.3 for the CDV/CDR status types.

Additional Flow 8 and Flow 9 output and input validation rules

Additional validation rules have been implemented for Flow 8 (outbound e-invoicing) and Flow 9 (B2C and inbound):

• Content and consistency rules applied at the output and input stages (BR-FR-CO-01, BR-FR-CO-02, BR-FR-CO-11).

• Required value rule (BR-FR-MV-04).

• Mapping validation rule (BR-FR-MVMAP-01).

What this means for you

These rules enforce constraints that the AFNOR specification defined but that were not before enforced in the Sovos pipeline. If your invoices already conform to the AFNOR specification, no change is needed.

E-reporting schematron updated for B2B

The schematron validation files used for B2B e-reporting transactions have been updated to reflect the AFNOR v1.3 rule set. Before, the schematron enforced the v1.2 rule set.

The v1.3 extended schematron has been associated with plugin version 1.0 (July 2025 release), making the v1.3 extended rules available to you if you use that plugin version.

What this means for you

B2B e-reporting submissions are now validated against the v1.3 rule set. If your reports comply with v1.2, review the delta rules in the AFNOR XP Z12-012 v1.3 specification (Annexe 7, Règles de gestion) to confirm compliance with any new or modified rules.

New e-reporting consolidation product bundles

Four new product bundles and their corresponding operations have been added to support the full consolidation mode for e-reporting:

These bundles correspond to the four consolidation document streams documented on the Send e-reports page. They are a platform-side addition and do not need changes to your submission format or SBDH setup.

What this means for you

If you are using consolidation mode for e-reporting, these bundles are now available and active. No action is needed unless Sovos support has told you to reference a specific product bundle in your setup.

Specification versions and references

The official AFNOR specifications are available at the AFNOR standards portal and the French tax authority mandate page. The Sovos implementation is based on the published external specifications (Dossier de spécifications externes, version referenced at time of release).

Questions and support

If you have questions about how these changes affect your specific implementation, contact Sovos support or contact your implementation contact. For questions about the AFNOR specification itself, refer to the official AFNOR documentation or the DGFiP external specification documents.