From 68ca02c0828a6861bd247d17c26c40e1c687357e Mon Sep 17 00:00:00 2001 From: Svante Schubert Date: Fri, 16 Feb 2024 11:03:24 +0100 Subject: [PATCH] Adding the latest general document of France in English as HTML to make content referable by URL (transformed by LibreOffice HTML export) --- .../1. General document_EN_310723.html" | 5203 +++++++++++++++++ 1 file changed, 5203 insertions(+) create mode 100644 "docs/fr/Dossier de sp\303\251cifications externes de la facturation \303\251lectronique, annexes et swaggers/1. General document_EN_310723.html" diff --git "a/docs/fr/Dossier de sp\303\251cifications externes de la facturation \303\251lectronique, annexes et swaggers/1. General document_EN_310723.html" "b/docs/fr/Dossier de sp\303\251cifications externes de la facturation \303\251lectronique, annexes et swaggers/1. General document_EN_310723.html" new file mode 100644 index 0000000..e438c37 --- /dev/null +++ "b/docs/fr/Dossier de sp\303\251cifications externes de la facturation \303\251lectronique, annexes et swaggers/1. General document_EN_310723.html" @@ -0,0 +1,5203 @@ + + + + + + + + +Note + + + + + + + + + + + + + + + + + + + + + +

 

+ +
+

+

 

 

 

 

 

 +

French Agency for State Financial Information Technology

+

 

+

31/07/2023

+

 

 

+

External specification file for electronic invoicing

+

 

+

General document

+

 

+

Version history

+
+ +
+

Date

+		 +

Distribution

+		 +

Status / change tracking

+
+

30/09/2021

+		 +

Version v1

+

 

 

+

30/12/2021

+

 

 

 +

Version v1.1

+

  • Addition of e-reporting formats 

  • Addition of further information on special use cases and the directory 

  • Taking account of editors’ and companies’ comments following publication of the 1st version 

  • Expansion of the annexes 

+

31/03/2022

+		 +

Version v1.2

+

  • Addition of use cases 

  • Operation of PDF submission and its trajectory 

  • Functioning of rejection/inadmissibility of flows 

  • Management of the readable invoice 

  • Update of e-reporting 

  • Introduction to the APIs 

  • Initialisation and expansion of the directory 

+

30/06/2022

+		 +

Version v2.0

+

  • Update of management cases 

    • onos. 13, 24, 25, 26, 28, 29 

  • Addition of management cases 

    • onos. 22b, 30, 31, 32, 33, 34 

  • Update of the description and use of e-reporting flows and methods of sending (§3.2.10) 

  • Update of life-cycle statuses (§2.8.2) 

  • Clarification on document management (§3.2.9) 

  • Further information on the addressing code (§5.5.2) 

  • Update of information on newly created companies in the directory (§5.7.4) 

+

29/07/2022

+		 +

Release v2.1

+

  • Management case update #25 

+

31/01/2023

+		 +

Release v2.2

+

  • Addition of 2 mandatory e-invoicing data items 

  • Changes to standard EN16931 

  • Changes to management cases: 

    • oCases 8 to 10: factoring management 

    • oCase 18: Debit note management 

    • oCases 20 and 21: Prepayment invoice and final invoice after prepayment invoice 

    • oCase 22a: Invoice paid with discount on supply of services for which VAT is due on receipt of payment 

    • oCase 33: Transactions subject to the VAT margin scheme 

  • Addition of management cases: 

    • oCase 35: Author’s notes 

    • oCase 12: Transparent intermediary 

  • Removal of EDI mode (§3.2.7. Document management) 

  • Update of chapter §4.6 and its two use cases: 

    • oAdding an attachment to an invoice 

    • oQuota management in case of submission of a flow 

  • ·§2.8.3: amendment to producers of statuses 200, 210 and 213: it is the platforms (supplier or buyer) that have the legal obligation to produce these statuses 

  • ·Addition of §2.9 Retaining invoices 

  • ·Modification to §5.7.4 Newly-established companies 

  • ·Modification to §2.10.2 Frequencies and time limits for the transmission of e-reporting 

  • ·Modification to §3.2.10.5 Procedures for sending transmissions and addition of §3.10.6 and §3.10.7 

  • ·5.4.1.: details have been given of the role of PDPs in the initial input and updating of the directory 

  • ·3.2.5: the EXTENDED FR B2B profile, including the new fields from the extensions to the French scope of cross-company electronic invoicing, has been added 

  • ·3.2.6.2: a reminder that the "PAYER" block makes it possible to identify the payer. 

  • ·: partial reformulation of cases 3 and 4 

  • ·3.2.6.4: modification to the description of rows 1 and 2 of the table and the general description of the chapter 

  • ·Error: Reference source not foundmodification to the description in row 3 - "Creating the invoice" (option 1) 

+

31/07/2023

+		 +

Release v2.3

+		 +

Removal of the chapters on individual cases of use and creation of a separate document (External Electronic Invoicing Specifications File - Use Case)

+

 

+

Modification of the following chapters:

+

  • Types of stakeholder (2.3.3) 

  • Gradual application of the requirement (2.3.4) 

  • The "Y" scheme (2.4.1) 

  • Invoicing circuits (2.4.2) 

  • Choice of the public invoicing portal (2.4.3) 

  • Role of registered private platforms (2.4.4.1) 

  • Obligations of registered private platforms (2.4.4.3) 

  • Mandatory data for e-invoicing (2.4.6.1) 

  • Submission of PDF invoices (2.4.6.2) 

  • Status data (life cycle) (2.4.6.3) 

  • E-reporting data (2.4.6.4) 

  • Interoperability (2.4.7) 

  • Identification of companies on the public invoicing portal (2.5.1) 

  • Directory Identification (2.5.2) 

  • Service offer for registered private platforms (2.6) 

  • Summary of the public invoicing portal service offer (2.7) 

  • The nominal life cycle of the invoice (2.8) 

  • Key principles of the life-cycle flow (2.8.1) 

  • Status management (2.8.2) 

  • Life-cycle status definition and procedures (2.8.3) 

  • Retaining invoices (2.9) 

  • E-reporting scope (2.10.1) 

  • Frequencies and deadlines for transmitting e-reporting data (2.10.2)  

  • Controls carried out (2.11) 

  • Flow technical controls (2.11.1) 

  • Data structure controls (2.11.3.1) 

  • Focus on the unicity control (2.11.3.2) 

  • Summary of the various controls carried out (2.11.4) 

  • Management of invoice inadmissibility/rejection/refusal (2.12.1) 

  • Life-cycle process for a flow and an invoice issued on the public invoicing portal (PPF) (2.12.1.1) 

  • Life-cycle process for a flow and an invoice received within the PPF (2.12.1.2) 

  • Invoice management in the event of inadmissibility, rejection or refusal (2.12.1.3) 

  • Reasons for different types of controls (2.12.2) 

  • E-invoicing flow (3.2.2) 

  • Managing a multi-order / multi-delivery invoices (3.2.6.1) 

  • Managing a payer in an invoice (PAYER) (3.2.6.2) 

  • Adding a qualifier for the beneficiary (PAYEE) (3.2.6.3) 

  • Adding the INVOICEE role within an invoice (3.2.6.4) 

  • Considering other parties to be added to EN16931 (3.2.6.5) 

  • Data alignment for the beneficiary role (BG-10) (3.2.6.6) 

  • Request to allow attachments to be categorised (3.2.6.7) 

  • Readable version of the invoice issued or received for the recipient (3.2.7.2) 

  • E-reporting flows (3.2.10) 

  • Invoice flows (3.2.10.1.1) 

  • Transaction and Payment Data e-reporting flows (invoices off format / flow 10) (3.2.10.1.2) 

  • B2C transaction data e-reporting: transmission of aggregated data (3.2.10.2) 

  • E-reporting flow (3.2.10.3.2) 

  • Globalised transaction payment date e-reporting B2C only (3.2.10.4) 

  • Procedures for sending transmissions (3.2.10.4.1) 

  • Correction of transmissions (3.2.10.4.2) 

  • Rectification of transmissions (3.2.10.4.3) 

  • Summary of the various cases of e-reporting and the associated flows (3.2.10.5) 

  • Directory flow (3.2.11) 

  • Life-cycle flow (3.2.12) 

  • Introduction to the service offer (4.1.1) 

  • E-invoicing APIs (4.3) 

  • E-reporting APIs (4.4) 

  • Directory APIs (4.5) 

  • Exchange System domain APIs (4.6) 

  • Quota management for submission of an attachment (4.7.2) 

  • Typical directory structure (5.2.1) 

  • Directory structure for addressing at SIRET level (5.2.3) 

  • Keeping the directory up to date over time (5.4.2) 

  • The directory and invoicing flows (5.5.2) 

  • Methods for declaring and changing platform (5.6) 

  • Addressing line status (5.7.1) 

  • Companies with non-visible SIRET numbers (5.7.2) 

  • Exchange protocols for connection of EDI partners (6.1) 

  • PeSIT HS E (6.2) 

+

 

+ +

Creation of the following chapters:

+

  • Cardinality control (2.11.3.1.1) 

  • Management rule control for the data transmission to the tax authority (2.11.3.1.2) 

  • Naming of flows (3.2.1) 

  • Readable version of the invoice submitted for the issuer (3.2.7.1) 

  • Correspondence between certain mandatory information[1]to be found on the readable part of the invoice and the structured data on the invoice (3.2.7.3) 

  • "Flow" life cycle (3.2.12.1)  

  • "Business object" life cycle (3.2.12.2)  

  • E-invoicing invoice life cycle (3.2.12.2.1)  

  • E-reporting transmission life cycle (3.2.12.2.2) 

  • Regulatory data life cycle (flow 1) (3.2.12.2.3) 

  • Directory life cycle (3.2.12.2.4)  

  • Status life cycle (flow 6) (3.2.12.2.5)  

  • "Subrogation" life cycle (3.2.12.3) 

  • Reference texts (8) 

+

Removal of the following chapters:

+

  • Modification of the cardinality of the buyer identifier (BT-46) 

  • Authorisation of multiple, type-classified contacts for all parties 

  • Management of amounts 

  • Single taxable entity 

  • Input Output table 

  • Detail of e-invoicing resource APIs 

  • Flow I/O table 

  • Flow 1 Invoicing Data I/O table 

  • Invoice I/O table 

  • Document I/O table 

  • Detail of e-reporting resource APIs 

  • E-reporting I/O table 

  • Directory I/O table 

  • The directory and the life cycle 

  • Coding of the invoicing line code 

 

 

+ +

 

+ + +

+

 

+

       

+ +

1        Introductory remarks        10

+ +

1.1        Purpose of the document        10

+ +

1.2        Content of the document        10

+ +

2        Introduction        11

+ +

2.1        Reminder of the existing status of invoice dematerialisation        11

+ +

2.2        Context and purpose of electronic invoicing        11

+ +

2.3        Scope of invoice dematerialisation        12

+ +

2.3.1        Requirement for e-invoicing        12

+ +

2.3.2        Requirement for e-reporting        12

+ +

2.3.3        Types of stakeholder        13

+ +

2.3.4        Gradual application of the requirement        13

+ +

2.4        Functional description of the solution        14

+ +

2.4.1        The “Y” scheme        14

+ +

2.4.2        Invoicing circuits        15

+ +

2.4.3        Choice of the public invoicing portal        16

+ +

2.4.4        The choice of a registered private platform        17

+ +

2.4.5        Directory        18

+ +

2.4.6        Main data exchanged        19

+ +

2.4.7        Interoperability        23

+ +

2.5        Identification of stakeholders        23

+ +

2.5.1        Identification of companies on the public invoicing portal        23

+ +

2.5.2        Identification in the directory        24

+ +

2.5.3        Identification of Intermediary platforms        24

+ +

2.6        Service offer for registered private platforms        25

+ +

2.6.1        Issuing and receiving invoices        25

+ +

2.6.2        Consulting and updating the directory        25

+ +

2.7        Summary of the public invoicing portal service offer        25

+ +

2.8        The nominal life cycle of the invoice        27

+ +

2.8.1        Key principles of the life-cycle flow        28

+ +

2.8.2        Status management        28

+ +

2.8.3        Life-cycle status definitions and procedures        29

+ +

2.9        Retaining invoices        31

+ +

2.10        E-reporting        31

+ +

2.10.1        Scope of e-reporting        31

+ +

2.10.2        Frequencies and deadlines for transmitting e-reporting data        32

+ +

2.11        Controls performed        33

+ +

2.11.1        Flow technical controls        33

+ +

2.11.2        Application controls        34

+ +

2.11.3        Functional controls        34

+ +

2.11.4        Summary of the various controls carried out        37

+ +

2.12        Grounds for rejection and inadmissibility        38

+ +

2.12.1        Management of invoice inadmissibility/rejection/refusal        38

+ +

2.12.2        Reasons for different types of controls        47

+ +

3        Introduction to flows        50

+ +

3.1        Mapping of flows described in the external specifications        50

+ +

3.2        Overview of flows around the public invoicing portal        55

+ +

3.2.1        Naming of the flows        55

+ +

3.2.2        E-invoicing flow        57

+ +

3.2.3        UBL format        60

+ +

3.2.4        CII format        60

+ +

3.2.5        Factur-X format        60

+ +

3.2.6        Changes to standard EN16931        61

+ +

3.2.7        Managing the readable invoice        63

+ +

3.2.8        Document management        66

+ +

3.2.9        B2G flow (compatible with standard 16931)        66

+ +

3.2.10        E-reporting flow        66

+ +

3.2.11        Directory flow        80

+ +

3.2.12        Life-cycle flow        81

+ +

4        Introduction to service mode        87

+ +

4.1.        Overview of the APIs        87

+ +

4.1.1.        Introduction to the service offer        87

+ +

4.1.2.        API exchange formats        88

+ +

4.1.3.        API versioning        88

+ +

4.1.4.        Introduction to VERBS        88

+ +

4.2.        Prerequisites for using API mode        88

+ +

4.2.1.        PISTE and authentication in Oauth2 mode        88

+ +

4.2.2.        Connection in API mode        89

+ +

4.2.3.        Return code for API queries        90

+ +

4.2.4.        Description of the APIs        91

+ +

4.3.        E-invoicing APIs        92

+ +

4.4.        E-reporting APIs        92

+ +

4.5.        Directory APIs        93

+ +

4.6.        Exchange System domain APIs        93

+ +

4.7.        API usage cases        93

+ +

4.7.1.        Making an invoice available with an attachment        93

+ +

4.7.2.        Quota management for submission of an attachment        94

+ +

5.        Directory        95

+ +

5.1.        Definition of the directory and its guiding principles        95

+ +

5.2.        Directory structure and addressing invoices        95

+ +

5.2.1.        Typical directory structure        96

+ +

5.2.2.        Directory structure for addressing at SIREN level        97

+ +

5.2.3.        Directory structure for addressing at SIRET level        97

+ +

5.2.4.        Directory structure for addressing by routing code        97

+ +

5.3.        Directory data and addressing invoices        98

+ +

5.4.        Roles and responsibilities of ecosystem stakeholders        98

+ +

5.4.1.        Initial population of the directory        99

+ +

5.4.2.        Keeping the directory up to date over time        99

+ +

5.5.        How the new directory works        100

+ +

5.5.1.        The directory and invoicing circuits        100

+ +

5.5.2.        The directory and invoicing flows        100

+ +

5.5.3.        The directory and the self-billing use case        101

+ +

5.5.4.        The directory and the third-party invoicing use case        102

+ +

5.6.        Methods for declaring and changing platform        102

+ +

5.7.        Special cases and directory management rules        104

+ +

5.7.1.        Addressing line status        104

+ +

5.7.2.        Companies with non-visible SIRET numbers        104

+ +

5.7.3.        Newly created companies        105

+ +

6.        Connection protocols        105

+ +

6.1.        Exchange protocols for connection of EDI partners        105

+ +

6.2.        PeSIT HS E        106

+ +

6.3.        SFTP        106

+ +

6.3.1.        General principles        106

+ +

6.3.2.        Exchange terms and conditions        107

+ +

6.4.        AS/2        108

+ +

6.4.1.        General principles        108

+ +

6.4.2.        Exchange terms and conditions        110

+ +

6.5.        AS/4        112

+ +

6.5.1.        General principles        112

+ +

6.5.2.        Exchange terms and conditions        112

+ +

7.        Glossary        114

+ +

8.        Reference texts        117

+ +

9.        Contacts        118

+

 

 

 

 

+

FIGURES

+ +

Figure 1: The reform aims to transform the invoicing chain for the benefit of all parties        13

+ +

Figure 2: The Y scheme        15

+ +

Figure 3: Invoicing circuits within the Y scheme        16

+ +

Figure 4: The directory within the Y scheme        19

+ +

Figure 5: Public invoicing portal service offer        26

+ +

Figure 6: Invoice life cycle and status list        28

+ +

Figure 7: Checks performed by the Public invoicing portal        33

+ +

Figure 8: Life-cycle process for a flow and an invoice issued on the public invoicing portal (PPF)        39

+ +

Figure 9: Life-cycle process for a flow and an invoice received on the PPF        40

+ +

Figure 10: Management of discharges and rejections in B1 and C circuits        41

+ +

Figure 11: Management of rejections and refusals in circuit A        42

+ +

Figure 12: Management of rejections and refusals in circuit B2        43

+ +

Figure 13: Mapping of all the flows        50

+ +

Figure 14: Semantic format of EN16931 standard        59

+ +

Figure 15: Representation of the transmission of transaction and payment data        67

+ +

Figure 16: Representation of the semantic format of the e-reporting flow        69

+ +

Figure 17: Representation of data transmission with the public invoicing portal as an e-reporting data transmit platform        73

+ +

Figure 18: Representation of data transmission with a registered private platform as the e-reporting data transmit platform        74

+ +

Figure 19: Representation of the correction of a transmission        75

+ +

Figure 20: Representation of the correction of a transmission made directly in the invoice        75

+ +

Figure 21: Representation of the transmission of a correcting invoice        76

+ +

Figure 22: Representation of the correction of transmissions        76

+ +

Figure 23: e-reporting, circuits A, B1 and B2        77

+ +

Figure 24: e-reporting, circuits B1 and B2        78

+ +

Figure 25: e-reporting, circuit C        78

+ +

Figure 26: Semantic format of the directory        79

+ +

Figure 27: Representation of the semantic format of the life-cycle flow        80

+ +

Figure 28: Diagram of the send of a life cycle message following public invoicing portal control of a flow        82

+ +

Figure 29: Diagram of the send of life cycle messages after processing business objects        82

+ +

Figure 30: "IN", "CO", and "MO" transmission life cycle        83

+ +

Figure 31: Life cycle of an "RE" transmission        84

+ +

Figure 32: Integration methods        86

+ +

Figure 33: The creation of a connection        88

+ +

Figure 34: Connection of a hub:        89

+ +

Figure 35: Connection of a third-party software publisher:        89

+ +

Figure 36: Adding an attachment to an invoice        93

+ +

Figure 37: Quota management for submission of an attachment        93

+ +

Figure 38: Directory data category        95

+ +

Figure 39: Role of parties in relation to the directory        99

+ +

Figure 40: Invoice and directory data blocks        100

+ +

Figure 41: Methods for changing the platforms declared in the directory        102

+ +

Figure 42: Management of directory addressing line statuses        103

+ +

Figure 43: Diagram of the outbound circuit of an SFTP protocol transfer        107

+ +

Figure 44: Diagram of the return circuit of an SFTP protocol transfer        107

+ +

Figure 45: Diagram of the outbound circuit of an AS/2 protocol transfer        109

+ +

Figure 46: Diagram of the return circuit of an AS/2 protocol transfer        110

+ +

Figure 47: Diagram of the outbound circuit of an AS/4 protocol transfer        112

+ +

Figure 48: Diagram of the return circuit of an AS/4 protocol transfer        112

+

 

  1. 1Introductory remarks 

    1. 1.1Purpose of the document 

 

+

The external specification file contains all the documents describing the formats for exchanging data with the public invoicing portal in the context of the general adoption of electronic invoicing between parties subject to value added tax and the transmission of data to the administration, pursuant to Article 26 of Amending Finance Act no. 2022-1157 of 16 August 2022.

+

 

+

This document is divided into several parts defining the context and purpose of e-invoicing, its regulatory framework, the functional description of the solution and the formats for exchange flows. Details of the directory, invoicing cases and connection protocols are also provided in this document.

+

 

+

The external specifications fall within the scope of the organisation, development and management of the information systems involved in this project.

+

 

+

This document is intended for:

+

    1. 1.2Content of the document 

 

+

This document specifies the requirements for submission, reception and transmission of e-invoices, retrieving information on the invoice life cycle, and transmission of data to the tax authority in the context of international business-to-business transactions and transactions between businesses and the end consumer in France.

+

 

+

This document is not a user guide but provides all e-invoicing stakeholders with a functional overview of the target solution for business-to-business exchanges. It also specifies essential points such as formats, the directory and exchange protocols.

+

 

 

  1. 2Introduction 

    1. 2.1Reminder of the existing status of invoice dematerialisation 

 

+

The Modernisation of the Economy Act (LME) of 4 August 2008 already required the State to accept invoices issued by its suppliers in dematerialised form as from 1 January 2012. Since then, the State has implemented the “Chorus Factures” solution for suppliers to public entities (B2G relations). Using this platform, suppliers to public entities could, if they wished, send their invoices in electronic format (PDF, online entry, or EDI).

+

 

+

Order No. 2014-697 of 26 June 2014 (repealed), transposing European Directive 2014/55/EU, extended this obligation to the entire public sphere as from 1 January 2017. This Order also sets out a timetable for the gradual implementation of mandatory electronic invoicing of public entities. “Chorus Factures” was therefore replaced by “Chorus Pro” on 1 January 2017, its use gradually becoming mandatory for suppliers to the public sphere according to their size.

+ +

The legal framework for B2G electronic invoicing is now enshrined in the Public Procurement Code.

+

 

+

External specifications exist on this scope and are published on the Chorus Pro community website. These external specifications will eventually replace the existing B2G specifications.

+

    1. 2.2Context and purpose of electronic invoicing 

 

+

Over the past decade, European Member States and the European Commission have been pursuing the goal of deploying electronic invoicing to facilitate business-to-business relations. France is leading and supporting these initiatives by implementing legal reforms and proposing mechanisms to facilitate this modernisation of exchanges.

+

 

+

A new e-invoicing system covers invoices for transactions between entities subject to VAT issued in electronic form and provides that the data they contain should be transmitted to the tax authority, in particular for the purpose of modernising the collection of value added tax and inspection methods.

+

 

+

The reform has four goals:

+

  1. 1.To simplify business life and enhance competitiveness through the reduced administrative burden, reduced payment times and productivity gains resulting from dematerialisation. The adoption of electronic invoicing will represent a gain for the economy of at least €4.5bn; 

  2. 2.To eventually simplify their VAT reporting obligations by pre-filling the declaration form. This will pave the way for a new offer of services from the tax authority, of particular benefit to smaller companies; 

  3. 3.To improve fraud detection, in the interest of economic operators acting in good faith; 

  4. 4.To improve real-time knowledge of business activity. 

 

    1. 2.3Scope of invoice dematerialisation 

      1. 2.3.1Requirement for e-invoicing  

 

+

The reform follows on from the requirement for e-invoicing for all business relations with the public sector (B2G, “Business to Government”).

+

 

+

The new legal framework for electronic invoicing is defined by Article 26 of Amending Finance Act no. 2022-1157, 2022 adopted on 16 August 2022. The regulatory texts were published in the Official Journal on 9 October 2022:

+

 

+

These texts make electronic exchange of invoices mandatory for domestic transactions between VAT taxable entities established, domiciled or habitually resident in France.

+

 

+

Article 289 bis stipulates a requirement for e-invoicing, namely the issue, transmission and receipt of invoices in accordance with standards defined by ministerial order.

+ +

“Article 289 bis. – I. – For the purposes of Article 289 and by way of derogation from VI thereof, the issue, transmission and receipt of invoices relating to the transactions specified in ‘a’ and ‘d’ in 1° of I of Article 289, and to payments on account relating thereto, shall be carried out in electronic form in accordance with e-invoicing standards defined by order of the Minister for the Budget where the invoice issuer and recipient are taxable entities established, domiciled or habitually resident in France.”

+ +

+

      1. 2.3.2Requirement for e-reporting 

 

+

To fully meet the objectives of the reform, Article 26 of the Amending Finance Act 2022-1157 for 2022, adopted on 16 August 2022, provides additional obligations for the transmission of data.

+

 

+

Article 290 of the French General Tax Code (CGI) supplements the e-invoicing requirement by including the transmission of additional data to the tax authority for non-domestic business-to-business transactions, known as B2B International, and transactions between businesses and end consumers in France, known as B2C (business-to-consumer), along with transmission of transaction payment data. The transmission of this data is called e-reporting.

+ +

Article 290 describes the transactions (deliveries of goods and services) that shall be subject to e-reporting and communication to the tax authority in electronic form in accordance with transmission standards defined by order of the Minister for the Budget.

+ +

These two obligations shall be supplemented by a transmission of the payment data provided for in article 290 A.

+ +

“Art. 290 A. – I. – Data relating to payment for transactions falling within the services category specified in Articles 289 bis and 290, with the exception of those for which the tax is payable by the buyer, shall be communicated in electronic form to the tax authority in accordance with transmission standards defined by order of the Minister for the Budget, using either the public invoicing portal, which communicates the data to the tax authority, or another online platform which transmits the data to the portal responsible for its transmission to the tax authority.”

+ +

+ +

+

      1. 2.3.3Types of stakeholders 

 

+

Four main types of stakeholders are involved in the reform:

+

 

+

Dematerialising operators (OD): operators offering invoice dematerialisation services but not registered by the tax authority. These operators may not send e-invoices directly to their recipients but may act on behalf of the company.

+

 

+

The reform brings benefits for all stakeholders, namely 4 million French companies subject to VAT, of which more than 96% are very small enterprises (TPEs), exchanging nearly 2 billion B2B invoices every year.

+

 

+

+ + +
+ +
 
+

Figure 1: The reform aims to transform the invoicing chain for the benefit of all parties

+

      1. 2.3.4Gradual application of the requirement 

 

+

As of 1 July 2024, the obligation of receipt of invoices in electronic format will be mandatory for all companies regardless of their size, as some companies will issue their invoices in electronic format from that date.

+

 

+
In order to take into account companies’ characteristics and ability to adapt their billing processes, the obligations for issuing electronic invoices (e-invoicing) and transmitting data (e-reporting)1will apply gradually in 3 stages :
+

 

+
Company size is assessed according to the following criteria2:
+

 

+

The size of the company is determined at the level of each legal entity on 30 June 2023 based on the declaration of results of the last completed financial year before that date. Otherwise, it will be assessed based on the declaration of the first completed financial year ended after that date.

+ +

                 

+

    1. 2.4Functional description of the solution 

      1. 2.4.1The “Y” scheme 

+

Article 289 bis of the French General Tax Code (CGI) provides that “the issue, transmission and receipt of electronic invoices shall be carried out, at the choice of the parties, using the public invoicing portal referred to in Article L. 2192-5 of the Public Procurement Code or a registered private platform. 

+ +

(...) Invoicing data issued by taxable entities using the public invoicing portal referred to in the second sub-paragraph of I shall be forwarded by the public invoicing portal to the tax authority. Invoicing data issued by taxable entities using another online platform shall be forwarded by the online platform operator to the public invoicing portal which shall forward it to the tax authority.”

+ +

To exchange their invoices, companies may choose to go through a private platform (PDP) registered by the tax authority and/or the public invoicing portal (PPF). Electronic invoices will be sent via the selected platforms for issuing and receiving. The public invoicing portal will provide minimum services free of charge to enable companies to meet their obligations as part of the reform.

+

 

+

The scheme resulting from this article, and representing the relationship between the ecosystem stakeholders, is the so-called “Y” scheme:

+

 

 

+ +
+ +
 
+

Figure 2: The Y scheme

+

 

 

+

This architecture is designed to integrate seamlessly with existing practices. The implementation of the Y-model is preferred in that it meets the expectations of companies and operators, with the vast majority of them having indicated their preference for this scheme. All companies that already use private operators see this as a way to reduce adaptation costs, and those without invoicing solutions consider that the possibility of going directly through the public invoicing portal reduces the entry costs of this reform. In addition, this model seems more resilient: if one platform were to fail, only part of the invoicing flow would be affected, with the possibility of re-routing to the functional platforms.

+

 

+

The mechanism adopted is based on reconciling:

+

 

+

The “Y” scheme applies to both e-invoicing and e-reporting:

+

 

 

      1. 2.4.2Invoicing circuits 

 

+

Three circuits have been identified to exchange invoices, report invoicing data and forward the associated life cycle:

+

 

 

+

In all three circuits, the public invoicing portal consolidates the data for the tax authority.

+ + +
+ +
+ +
+ +
+ +
 
+
+

 

 

      1. 2.4.3Choice of the public invoicing portal 

 

+

The public invoicing portal will be the default platform for the dematerialised exchange of invoices, set up for the general application of B2B e-invoicing.

+

 

+
In addition to the tasks that the public invoicing portal undertakes as a platform for issuing and receiving, it also provides the following services1:
+

Its features are designed to be easily integrated directly into the company's information systems or the invoicing software used. Finally, the modular and unifying architecture of the public invoicing portal gives companies unified access to the submission, processing and tracking of invoices, both in the public and private spheres.  + + +

+

The guiding principles of the public invoicing portal are:

+

 

      1. 2.4.4The choice of a registered private platform 

 

        1. 2.4.4.1Role of registered private platforms 

 

+

A registered private platform (PDP) is a service provider with two roles:

+

 

 

        1. 2.4.4.2Registration of registered private platforms 

 

+

Article 26 of Amending Finance Act 2022-1157 of 16 August 2022 introduces a registration procedure for registered private platforms in a new article of the CGI (Article 290 B).

+ +

“Art. 290 B. –. Dematerialisation platforms that send e-invoices and forward the data referred to in Articles 289 bis, 290 and 290 A to the public invoicing portal are dematerialising operators identified as partners of the tax authority in the central directory referred to in Article 289 bis (III).

+ +

“To this end, the tax authority shall issue them with a registration number for a renewable period of three years, with reservations if applicable. A decree in the Council of State sets out the terms and conditions for issuing and renewing it.”

+ +

Registration numbers are issued for a period of three years. Renewal is subject to the same conditions as for obtaining the registration number.

+

        1. 2.4.4.3Obligations of registered private platforms 

+

In order to obtain a registration number, a candidate platform must provide information and documentation required by order to demonstrate its ability to perform its functions, while meeting a high level of security requirements. In particular, it must undertake to submit a compliance audit to the tax authority before the end of the first year after the registration number takes effect.

+ +

For the purposes of Articles 289 bis, 290 and 290 A of the General Tax Code, registered private platforms will be required to:

+

 

      1. 2.4.5Directory 

 

+

To determine whether the buyer is using the public invoicing portal (circuit A or B) or a registered private platform (circuit B or C), the Y scheme requires a directory to identify the platform chosen by each invoice recipient:

+

 

 

+ +
+ +
 
+
+

 

      1. 2.4.6Main data exchanged 

 

        1. 2.4.6.1Mandatory data for e-invoicing 

 

+
In the framework of e-invoicing, at the start-up of the solution (first round of deployment), a maximum of 24 mandatory items of data or data 1blocks must be forwarded to the tax authority (not including mentions specific to the single taxable entity), with a further 8 data items added in the target solution (last round of deployment):
+ +

+ + +
+

INFORMATION REQUIRED BY THE CGI OR COMMERCIAL CODE TO BE INCLUDED ON E-INVOICES WITHIN THE MEANING OF ARTICLE 289 BIS OF THE CGI

+		 +

START-UP

+		 +

TARGET

+
+

Identity number specified in the first sub-paragraph of Article R 123-221 of the Commercial Code (SIREN) – taxable entity

+		 +

x

+

 

+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – taxable entity or single taxable entity

+		 +

x

+

 

+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – member of single taxable entity

+		 +

x

+

 

+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – tax representative of the taxable entity

+		 +

x

+

 

+

Country – taxable entity

+		 +

x

+

 

+

Identity number specified in the first sub-paragraph of Article R 123-221 of the Commercial Code (SIREN) – customer

+		 +

x

+

 

+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – customer

+		 +

x

+

 

+

Country – customer

+		 +

x

+

 

+

Category of the transaction: delivery of goods (LB) / supply of services (PS) / dual (LBPS)

+		 +

x

+

 

+

Date of issue of the invoice

+		 +

x

+

 

+

Unique invoice number

+		 +

x

+

 

+

Corrected invoice number if a correcting invoice is issued

+		 +

x

+

 

+

Option to pay VAT on debits (the due date is not the date of receipt)

+		 +

x

+

 

+

Total excluding tax broken down by tax rate

+		 +

x

+

 

+

Corresponding tax amount broken down by tax rate

+		 +

x

+

 

+

Applicable VAT rate (to be broken down if multiple)

+		 +

x

+

 

+

Total amount payable excluding VAT

+		 +

x

+

 

+

Tax amount payable

+		 +

x

+

 

+

In case of exemption, reference to the legal disposition

+		 +

x

+

 

+

Invoice currency code/description

+		 +

x

+

 

+

“Self-billing” indication

+		 +

x

+

 

+

Reference to a special scheme referred to in 15 and 16 of I of Article 242 nonies A of Annex II to the CGI

+		 +

x

+

 

+

“Reverse charge” indication

+		 +

x

+

 

+

Date of delivery of the goods or completion of the service

+		 +

x

+

 

+

Date of advance payment if different from date of issue of the invoice

+		 +

x

+

 

+

Mention “member of a single taxable entity"

+		 +

x

+

 

+

Price reduction (price discounts, discounts, rebates)

+

 

 +

x

+
+

Precise description of the goods delivered or services rendered

+

 

 +

x

+
+

Quantity of goods delivered or services rendered

+

 

 +

x

+
+

Price excluding VAT for each item of goods delivered or services rendered

+

 

 +

x

+
+

Delivery address of goods, if different from customer address

+

 

 +

x

+
+

Date of issue of the corrected invoice in the case of correcting invoice

+

 

 +

x

+
+

Discount information

+

 

 +

x

+
+

Eco-contribution (Art. L.541-10 of the Environmental Code)

+

 

 +

x

+
+ +

 

+

The fields corresponding to the above data are included in Annex 1 (Annex 1 - Semantic format FE e-invoicing).

+

 

        1. 2.4.6.2Submission of PDF invoices 

 

+

During a transitional phase, companies will temporarily have the option to submit invoices in unstructured PDF format on their platform. A conversion must be performed by the platform to send an electronic invoice to the recipient in one of the structured formats provided by regulations.

+ +

To limit the burden of data entry or optical character recognition for these documents, and by way of derogation, the structured data during this transitional phase can be limited to the following:

+

 

+ +
+

Identity number specified in the first sub-paragraph of Article R 123-221 of the Commercial Code (SIREN) – taxable entity or single taxable entity

+
+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – single taxable entity

+
+

Individual identification number provided for in Article 286 ter of the General Tax Code (intra-community VAT number) – tax representative of the taxable entity

+
+

Identity number specified in the first sub-paragraph of Article R. 123-221 of the Commercial Code (SIREN) – customer

+
+

Category of the transaction: delivery of goods (LB) / supply of services (PS) / dual (LBPS)

+
+

Date of issue of the invoice

+
+

Unique invoice number

+
+

Corrected invoice number if a correcting invoice is issued

+
+

Option to pay VAT on debits (the due date is not the date of receipt)

+
+

Total excluding tax broken down by tax rate

+
+

Corresponding tax amount broken down by tax rate

+
+

Applicable VAT rate (to be broken down if multiple)

+
+

Total amount payable excluding VAT

+
+

Total amount of tax payable

+
+

In case of exemption, reference to the legal provision

+
+

Invoice currency code/description

+
+

“Self-billing” indication

+
+

Reference to a special scheme referred to in 15 and 16 of I of Article 242 nonies A of Annex II to the CGI

+
+

Mention “member of a single taxable entity”

+
+

“Reverse charge” indication

+
+

Date of advance payment if different from date of issue of the invoice

+
+ +

 

+

The fields corresponding to the above data are present in Annex 1 (Annex 1 - Semantic format FE e-invoicing).

+

 

+

When a user wishes to submit a PDF invoice on the public invoicing portal, optical character recognition is performed to identify the data in the above table. The invoice issuer must control, correct and validate the automatically recognised data. The output format is generated in Factur-X format (Basic-WL profile or equivalent). Indeed, the tax authority only requires headers, so this profile is the most suitable.

+

 

+

PDF filing will only be permitted for a transitional period, until 31/12/2027.

+

 

+

The tax authority must be able to distinguish between flows from PDF invoices and other flows.

+ +

From 1 January 2026, the tax authority will require the extended list of invoicing data including the 8 additional indications. In particular, this list includes the invoice line data.

+ +

In the case of a PDF submission, flows 1 and 2 will not contain all the data expected by the target. These flows should therefore be distinguished so that they are not rejected by the recipient’s platform.

+ +

The BT-24 (profile type) data item allows this distinction to be made (see "Annexe 1 - Format sémantique FE e-invoicing – Flux 1&2.xlsx").

+

 

 

        1. 2.4.6.3Status data (life cycle) 

 

+

In addition to invoicing data, buyers, suppliers and their respective platforms must forward invoice processing statuses (see 2.8 The nominal life cycle of the invoice).

+ +

Some statuses are mandatory and others recommended.

+

 

        1. 2.4.6.4E-reporting data 

 

+

The expected data for the e-reporting differ for international B2B transactions or B2C transactions.

+

 

+

The e-reporting of international B2B transactions concerns transactions to or from a taxable legal entity not established in France (list defined in Article 290-I of the CGI). It may also concern transactions between taxable entities established outside of France that are subject to VAT in France (see 2.10.1Scope of e-reporting). For international B2B transactions, the data to be forwarded will be identical in semantic and syntactical form to that forwarded for e-invoicing (see 2.4.6.1Mandatory data ), with the exception of the unique identification number (SIREN) of the legal entity subject to VAT and not established in France. The intra-community VAT number or a foreign number will replace the SIREN as applicable.

+ +

+ +

The e-reporting of B2C transactions is for transactions with an individual or a non-taxable legal entity:

+

  • Retail sales,  

  • Deliveries of goods and supplies of services taxable in France, 

  • Distance selling of goods in France and within the EU,  

  • Supplies of goods and services to private individuals outside the EU (e.g. video games, online music). 

 

+

The data expected for e-reporting of B2C transaction is as follows:

+

  • The period to which the transmission refers; 

  • Identity number specified in the first sub-paragraph of Article R. 123-221 of the Commercial Code for the taxable entity (SIREN); 

  • The indication “Option to pay VAT on debits” if the taxable entity has exercised this option; 

  • For each tax rate, the total amount excluding VAT and the corresponding VAT amount; 

  • Total amount of VAT payable, excluding any foreign VAT, expressed in euros for transactions in foreign currency; 

  • Currency; 

  • Transaction category:  

    • o (i) Delivery of goods subject to value added tax;  

    • o(ii) Supply of services subject to value added tax; 

    • o(iii) Deliveries of goods and supplies of service not subject to value added tax in France, including intra-Community distance sales referred to in Article 258 A (1° of I) and Article 259 B of the General Tax Code; 

    • o(iv) Transactions giving rise to application of the schemes provided for in Article 266 (e of 1) and Articles 268 and 297 A of the General Tax Code (VAT margin scheme); 

  • If an invoice has been issued and allows for e-reporting: 

    • oInvoice number 

    • oDate of the invoice;  

  • Number of daily transactions (excluding invoices). In case of checkout software, this is the number of checkout receipts issued in a day.  

  • Date of transactions if there is no invoice.  

 

+

E-reporting of payment data applies only to transactions falling within the category of supplies of services specified in Articles 289 bis and 290 of the General Tax Code, in so far as the company has not opted to pay VAT on debits and excluding transactions giving rise to reverse charge VAT. N.B. In case of VAT on debits option, payment data relating to the supply of service prepayments must be transmitted as soon as the VAT liability is collected .

+ +

The person responsible for the transmission obligation will be the service provider subject to the obligation to issue electronic invoices and/or transmit transaction data provided for in Article 290 of the CGI.

+ +

The data to be transmitted is:

+

  • The period for which the transmission is made or the  invoice date, 

  • Date of receipt of payment, 

  • Amount received broken down by VAT rate, 

  • For transactions that give rise to an invoice, the invoice numbers. 

 

      1. 2.4.7Interoperability 

 

+

The principle of interoperability refers to the capacity of a network, here the electronic invoicing ecosystem (public invoicing portal, registered private platforms), to allow all the systems involved to communicate with each other.

+

 

+

The interoperability of parties in the electronic invoicing circuit is thus based on the undertaking that the registered private platforms comply with the following requirements:

+

  • Compliance with the minimum core of semantic and syntactic formats complying with European standard EN16931 to facilitate exchanges and use of the data by the tax authority, 

  • Connection with the public invoicing portal and at least one registered private platform, 

  • Implementation of the means required by the tax authority to identify users and secure access, 

  • Updating of the central directory for the customers they host, 

  • Use of the central directory to ensure the routing of submitted invoices, 

 

+

Two factors will ensure the interoperability of the ecosystem:

+

  • Establishment of a central directory managed by the PPF containing the information necessary for routing invoices to companies and organisations, 

  • The connection of each PDP registered to the PPF and at least one other registered PDP. These connections must be made in such a way as to comply with all the rules laid down and thus ensure compliance with the system. 

 

    1. 2.5 Identification of stakeholders  

      1. 2.5.1Identification of companies on the public invoicing portal 

 

+

Entities subject to VAT, who wish to use the public invoicing portal to issue and/or receive invoices, must be identified as a structure within the PPF. This identification requires the creation of one or more user accounts on the PPF with an administrator, who will be responsible for creating and updating their structure’s information. 

+ +

The identification of the company issuing the invoice will be based on: 

+

  • the use of an identifier, which must be the SIREN number supplemented by the SIRET, if any, for the transmission of a B2B invoice.  

  • the use of an identifier, which may be (OUT_EU, OUT_EU, SIREN, SIRET) for the transmission of an international B2B or e-reporting invoice  

  • the use of an identifier, which may be (OUT_EU, OUT_EU, RIDET, TAHITI, PRIVATE INDIVIDUAL, SIREN, SIRET) for the transmission of a B2G invoice  

+

The identification of the company receiving the invoice will be based on the use of an identifier, which will be the SIREN number supplemented by the SIRET, if any.

+

 

+

A process will be put in place to secure access to the portal by the administrator of each organisation:

+

  • By verifying their identity and their capacity to act as a representative of their company 

  • By allowing them to delegate this responsibility to other users, natural persons, employees of the organisation or external representatives (authorised representatives, accountants, etc.) 

  • By authentication through a means that meets the expected level of security.  

 

+

Enterprises wishing to exchange invoices using the service mode or EDI mode must follow the connection procedure and meet the security requirements defined by AIFE to connect their application to the PPF.

+

      1. 2.5.2Identification in the directory 

 

+

The directory will be initialised with all the SIRENs of the companies involved in the electronic invoicing reform, as well as their main SIRETs, according to information from INSEE. In addition, information from public entities will be added, as it exists today in Chorus Pro. Invoice recipients will then have the option of adding any SIRETs or routing codes (see 5..Directory) Conversely, it is not necessary for the invoice issuers to be identified in the directory.

+ +

The invoice reception addressing level must be configured in the recipient directory by the entity itself, through the PPF or through its receiving PDP if it has one. It is the company's platform that updates the directory and indicates the platform chosen by the entity.

+

 

 

 

      1. 2.5.3Identification of Intermediary platforms 

 

        1. 2.5.3.1Registered private platform 

 

+

Under invoicing circuit B, registered private platforms (PDPs) may be required to issue invoices to the PPF and/or receive invoices from the PPF.

+ +

 

+ +

They must therefore connect to the PPF using the PPF’s required connection procedure.

+

 

+

They are also identified in the recipients directory as a receive platform for their customer companies.

+

 

+

The list of partner platforms registered by the tax authority will be published on the impots.gouv.fr website.

+

 

        1. 2.5.3.2Non-PDP dematerialising operators 

 

+

Non-PDP dematerialising operators are not identified in the directory. Only PDPs are.

+

 

+

Non-partner dematerialising operators may act as intermediaries:

+

  • When issuing invoices between the supplier and its transmit platform: they are then identified on the transmit platform (PDP or PPF) through a connection initiated by the supplier or by its intermediary on its behalf. 

  • On receipt of invoices between the customer and its receive platform: they are identified on the receive platform (PPF or PDP) through a connection initiated by the buyer or by its intermediary on its behalf. 

 

    1. 2.6Service offer for registered private platforms 

 

+

Once registered, a registered private platform receives a unique identifier. Registration is valid for 3 years and subject to a renewal process under the conditions defined by the tax authority in the statutory instruments dated 7 October 2022.

+

      1. 2.6.1Issuing and receiving invoices 

 

+

The public invoicing portal’s service offer for each of the stakeholders is shown below:

+ + +
+ +
 

      1. 2.6.2Consulting and updating the directory 

 

+

To forward data from e-invoicing flows, registered private platforms can consult the directory to find:

+

  1. 1.Information on identification of the recipient company and its addressing level, to correctly populate the invoice, 

  2. 2.Information on identification of its receive platform, for routing the flows, 

  3. 3.Additional information in the case of invoices to entities in the public sphere (B2G). 

 

+

Each registered private platform can update the directory on behalf of companies that have selected it and appointed it as their receive platform through a flow addressed to the PPF.

+ +

A more complete description of the directory and an overview of its usage and management rules is described in a dedicated chapter of this document (see 5..Directory).

+

 

    1. 2.7Summary of the public invoicing portal service offer 

 

+

In summary, the public invoicing portal allows creation, sending and tracking of invoices through different channels (portal, EDI or service).

+ +

+ + +
+ +
 
+

Figure 5: Public invoicing portal service offer

+

 

 

  1. 1.Directory: Invoice creation requires consultation of the directory to find information on the buyer. This can be done directly on the public invoicing portal (Portal mode), or in a company’s in-house application (EDI mode or Service mode) 

 

  1. 2.Invoice creation: From the invoicing data and routing obtained in the directory, several options are possible (beyond tool): 

 

  1. 3.Sending the invoice: The public invoicing portal allows companies to submit invoices, generated by them in a structured or mixed format, in the form of flows: 

 

+
The public invoicing portal also allows online data entry and optical character recognition of invoice data (from a PDF)2. The data entered or processed by OCR is then transformed after validation in Factur-X format to the Basic profile at the minimum (for input) and in Factur-X format with the Basic-WL profile (for OCR). The corresponding invoice is made available to the recipient without further action by the submitter.
+

 

  1. 4.Invoice tracking: The public invoicing portal allows the progress of invoices to be tracked, from their submission to their final status. This can be done online or in the company's IS using the life-cycle flows made available [see  "Annexe 2 - Format sémantique FE CDV.xlsx" of the external specifications] or using dedicated APIs. 

 

  1. 5.Reception of the invoice: To receive their invoices, companies must choose their receive platform and define the addressing level for their invoices: this information is stored in the directory to enable suppliers to address invoices and to route them through the platforms.  

+

Buyers that have chosen to use the public invoicing portal to receive their invoices (information indicated in the directory) can use online services to be alerted of new invoices and to consult them. Invoices can also be received directly in the company’s IS using file transfer or APIs.

+

 

+

The format for the delivery or receipt of invoices is chosen by the recipient from the structured or mixed core formats, or in a format ensuring backward compatibility for B2G exchanges.

+

 

+

If the invoice is issued in mixed format, only the structured data will be used to produce the data flow to the tax authority (flow 1) and will constitute the output format if the recipient has not chosen reception in mixed format. The readable version will also be sent to the recipient as an attachment to the invoice (see 3.2.7 Managing the readable invoice).

+

 

  1. 6.Invoice processing: The processing of invoices received (acceptance, approval, refusal, etc.) can be performed online on the public invoicing portal. 

+

It can also be done automatically: the public invoicing portal will then need to be informed of the actions performed on the invoice through life-cycle flows or by using APIs dedicated to updating invoice status.

+

 

    1. 2.8The nominal life cycle of the invoice  

 

+

Forwarding and updating the status of the invoice throughout its life cycle is essential to meet the challenges and goals set by the reform. The status documentation enables the buyer and supplier to track the progress of invoice processing (submission, availability, validation, payment, etc.) and to guarantee the transparency of transactions in progress.

+

 

 

+

The life cycle must meet the four following requirements:

+

 

  • Provide a shared view of invoice processing for all stakeholders (issuer, recipient, tax authority), 

  • Define a status list and exchange format to ensure interoperability between stakeholders (companies, registered private platforms, public invoicing portal), 

  • Detail the process for dealing with rejection and cancellation of invoices, 

  • Facilitate pre-filling of the VAT declaration form. 

+

The life cycle is based on two interlinked perimeters:

+

 

  • A core of mandatory statuses required by the tax authority;  

  • A core of statuses common to all stakeholders in the invoicing chain, which may be mandatory or recommended (optional). 

 

      1. 2.8.1Key principles of the life-cycle flow 

 

+

The life cycle is based on four key principles:

+

 

  • Promoting service quality by limiting the number of mandatory statuses  

+

To guarantee a high-quality service and facilitate company access in the reform, there is a need to limit the number of mandatory statuses.

+

 

  • Strict rules on the issuer of the life-cycle flow  

+

Except for a few specific management cases (see External Specifications File - Use Cases), the party performing the action on an invoice is the producer of the status. You can send multiple statuses (especially for PDPs), each attached to a business object.

+

 

  • Respect for the chronology  

+

It is essential to respect the chronology of the statuses. However, it is not necessary to send all possible statuses to the public invoicing portal hub (optional versus mandatory).

+

 

  • Sending invoicing data before the life cycle  

+

In order to facilitate the integration of life-cycle flows into the public invoicing portal and its hub, it is strongly recommended to send the invoice/invoicing data as soon as possible. Under circuit C, the issuing registered private platform must send invoicing data to the public invoicing portal within 24 hours of the date of the "submitted" status.

+

      1. 2.8.2Status management  

 

+

In the framework of the life cycle (excluding credit notes), the platforms can handle a dozen statuses:

+

 

+ +
+ +
 
+

Figure 6: Invoice life cycle and status list

+

 

 

 

 

 

 

      1. 2.8.3Life-cycle status definitions and procedures  

 

+ +
+

Code

+		 +

Status

+		 +

Change of status

+		 +

Trigger

+		 +

Forwarding

+		 +

Producer

+
+

200

+		 +

Submitted

+		 +

Automatic

+		 +

The supplier submits its invoice or credit note to the public invoicing portal or its registered private platform. The status is generated after the controls are performed.

+		 +

Mandatory

+		 +

Supplier’s platform

+
+

201

+		 +

Issued by the platform

+		 +

Automatic

+		 +

The invoice has been processed on the supplier’s platform and issued to the buyer

+		 +

Optional

+		 +

Supplier’s platform

+
+

202

+		 +

Received by the platform

+		 +

Automatic

+		 +

The invoice has been received by the public invoicing portal or the buyer’s registered private platform but has not yet been made available to the buyer

+		 +

Optional

+		 +

Buyer’s platform

+
+

203

+		 +

Made available

+		 +

Automatic

+		 +

The invoice has been made available to the buyer on the public invoicing portal or its registered private platform

+		 +

Should Do

+		 +

Buyer’s platform

+
+

204

+		 +

In hand

+		 +

Manual

+		 +

The invoice is assumed by the buyer for processing.

+		 +

Recommended

+		 +

Buyer

+
+

205

+		 +

Approved

+		 +

Manual

+		 +

The invoice is accepted in its entirety by the buyer

+		 +

Recommended

+		 +

Buyer

+
+

206

+		 +

Partially approved

+		 +

Manual

+		 +

The invoice is partially accepted by the buyer. This partial processing may give rise to a credit note.

+		 +

Recommended

+		 +

Buyer

+
+

207

+		 +

Disputed

+		 +

Manual

+		 +

There is a dispute regarding the invoice. This may ultimately lead to refusal or approval by the buyer.

+		 +

Optional

+		 +

Buyer

+
+

208

+		 +

Suspended

+		 +

Manual

+		 +

Invoice processing may be suspended when one or more supporting documents are missing. The invoice data remains unchanged.

+		 +

Optional

+		 +

Buyer

+
+

209

+		 +

Completed

+		 +

Manual

+		 +

The invoice is completed when the supplier adds an attachment or comment to an invoice with a status of "suspended"

+ +

Hence, it is not necessary to resend flow 1

+		 +

Optional

+		 +

Supplier

+
+

210

+		 +

Refused

+		 +

Manual

+		 +

The invoice has been refused by the recipient for business reasons

+ +

A complete list of reasons for refusal is available in the document "Annex 1 - Semantic Format FE e-invoicing - Flows 1 & 2" on the "Reason for refusal" tab

+		 +

Mandatory

+		 +

Buyer’s platform

+
+

211

+		 +

Payment sent

+		 +

Manual

+		 +

The bank transfer flow has been sent to the supplier

+		 +

Recommended

+		 +

Buyer

+
+

The reimbursement flow has been sent to the buyer

+		 +

Recommended

+		 +

Buyer

+
+

212

+		 +

Payment received

+		 +

Manual

+		 +

The supplier has received payment of the invoice. This status is mandatory for supply of services (except VAT on debits and excluding reverse charge transactions).

+		 +

Mandatory

+		 +

Supplier

+
+

213

+		 +

Rejected

+		 +

Automatic

+		 +

The invoice can be automatically rejected by the platform on technical grounds (e.g. format, non-compliance with the standard, etc.)

+ +

When the transmit platform rejects the invoice, the invoice must be corrected by its issuer and resubmitted to the platform.

+ +

When the receive platform rejects the invoice, the Rejected status is transmitted to the transmit platform (see 2.12.1.3 Invoice management in the event of inadmissibility, rejection or refusal)

+		 +

Mandatory

+		 +

Supplier or buyer platform

+
+

214

+		 +

Approved

+		 +

Manual

+		 +

This status will be used only for B2G subcontracting or co-contracting to approve an invoice:

+

  • -In the case of subcontracting, the holder has 15 days to validate the invoice. In the absence of processing within these time limits, the validation is tacit and the invoice is sent to the recipient. 

  • -In the case of co-contracting, the invoice will be sent to the addressee only on condition that the representative has validated it in advance.   

 +

Mandatory

+		 +

Buyer

+
+

215

+		 +

Not approved

+		 +

Manual

+		 +

This status will be used only for B2G subcontracting or co-contracting to indicate that an invoice is not approved:

+

  • -In the case of subcontracting, if the holder does not validate the invoice, it is nevertheless sent to the recipient who can then decide to process, suspend or reject it.  

  • -In the case of co-contracting, the invoice will not be sent to the addressee if the representative has refused it. The co-contractor must then submit a new invoice. 

 +

Mandatory

+		 +

Buyer

+
+ + +

The frequency of forwarding payment statuses (code 213) is dealt with in §2.10.2Frequencies and deadlines for transmitting e-reporting data

+

 

    1. 2.9Retaining invoices  

+
The public invoicing portal will ensure that invoices received and issued are retained and will make these invoices and their associated attachments available to invoice issuers and recipients with an account on the portal in order to ensure compliance with legal requirements[1]. The scope of retained invoices will be limited:
+

  • For issuers, to invoices submitted directly to the PPF (circuits A or B1); 

  • For recipients, to invoices made available (or sent directly) by the PPF (circuits A or B2). 

 

+

Invoices that have changed their status for less than 3 months before are considered active and will be accessible through the Portal or through API.

+

 

+

Invoices that have not changed their status for more than 3 months can only be downloaded via the Portal or via the dedicated API (asynchronous response within 24 hours).   

+

 

+

 

+

    1. 2.10E-reporting  

    1. 1.1 

    2. 1.2 

    3. 1.3 

    4. 1.4 

    5. 1.5 

    6. 1.6 

    7. 1.7 

    8. 1.8 

    9. 1.9 

    10. 1.10 

      1. 2.10.1Scope of e-reporting 

 

+

E-reporting of international B2B transactions relates to transactions where the buyer or seller is a legal entity subject to VAT and not established in France. It may also apply to taxable entities not established in France who carry out transactions in France with another taxable entity not established in France for the purpose of VAT and who are therefore subject to said tax. For international B2B transactions, the data to be forwarded will be identical in semantic and syntactical form to that forwarded for e-invoicing, with the exception of the identity number, specified in the 1st sub-paragraph of Article R 123-221 of the Commercial Code (SIREN), of the legal entity subject to VAT and not established in France. The intra-community VAT number or a foreign number will replace the SIREN as applicable.

+

 

+

E-reporting of B2C transactions concerns transactions where the buyer is a private individual or a non-taxable legal entity.

+ +

The expected B2C transaction e-reporting data is limited and globalised. It is defined in the chapter titled "Presentation of e-reporting flows" (see 3.2.10 E-reporting flow).

+

 

+

The e-reporting of payment data applies only to transactions falling within the category of supplies of services specified in Articles 289 bis and 290 of the French General Tax Code, for which the company has not opted to pay VAT on debits and excluding transactions giving rise to reverse charge VAT.

+ +

For payment data, the obligation falls on either the issuer of the invoice (with the exception of self-billing by the customer, when it is the supplier who completes the “payment received” status of the invoice) or the entity responsible for e-reporting the transactions.

+ +

Payment data is for international B2B and B2C transactions. In exceptional cases, payment data for domestic B2B transactions may be e-reported first and then corrected and transmitted via an e-invoicing life-cycle flow (see 3.2.10 E-reporting flow).

+

 

      1. 2.10.2Frequencies and deadlines for transmitting e-reporting data 

 

+

The deadlines and frequencies for the transmission of the data were specified in the regulatory texts dated 7 October 2022, published on 9 October 2022 (see 2.3.2 Requirement for e-reporting).

+

 

+

Enterprises must transmit transaction and payment data to their platform within a given period. This period is specific to each VAT tax regime.

+

 

 

+ +

 

 +

Transmission of transaction data (international B2B and B2C)

+		 +

Transmission of supply of service payment data (resulting in invoice or declaration)

+

 

 +

Deposit frequency

+		 +

Deposit deadline

+		 +

Deposit frequency

+		 +

Deposit deadline

+
+

Companies subject to the real normal monthly regime

+		 +

By 10-day period

+ +

Three one-month submissions:

+ +

- period 1: days 1 to 10 of the month

+ +

- period 2: days 11 to 20 of the month

+ +

- period 3: day 21 to the end of the month

+		 +

10 days after the end of the period, i.e.:

+ +

- period 1: day 20 of the month

+ +

- period 2: day 30 of the month

+ +

- period 3: day 10 of the following month

+		 +

Monthly

+		 +

Before day 10 of the following month

+
+

Companies that have opted for the real normal quarterly regime*

+		 +

Monthly

+		 +

Before day 10 of the following month

+
+

Companies subject to the simplified VAT regime

+		 +

Monthly

+		 +

Between days 25 and 30 of the following month at the latest

+		 +

Monthly

+		 +

Between days 25 and 30 of the following month at the latest

+
+

Companies benefiting from the VAT exemption scheme

+		 +

Bimonthly

+ +

(every 2 months)

+		 +

Between days 25 and 30 of the month following the end of the period at the latest

+		 +

Bimonthly

+ +

(every 2 months)

+		 +

Between days 25 and 30 of the month following the end of the period at the latest

+
+ + +

*Companies paying less than €4,000 in VAT per year

+

 

+

Time limits will apply when the public invoicing portal receives the data: PDPs may therefore be required to reduce this time limit based on their service offer. In the same way as the public invoicing portal, they will be responsible for aggregating all transmissions received during the period.

+

 

+

The expected deadline for making the declarations available to the tax authority is 08:00, i.e. the declarations received until 23:59 on the last day of the e-reporting period are available for the tax authority the following day from 08:00.  

Thus, if the tax authority retrieves data from e-reporting to D+1 of the end date of the period as from 08:00, the functional acknowledgement to the transmit platforms (and their users) will be done on D+2 around 07:00.

+

 

+

Since the periods shown in the table above may differ between transactions and payments, registered private platforms are requested to differentiate between payment declarations when they are transmitted to the public invoicing portal.

+

 

    1. 2.11Controls performed 

+

The public invoicing portal will implement a number of controls on flows and invoices, divided into 3 categories:

+

  1. 1-Technical Flow controls: technical flow controls apply to all flows received (EDI/API). The technical controls provide for application of Flow controls (for flows received via the API channel) and envelope controls (flow naming) to direct the processing of the flow and control its unicity.  

  2. 2-Application controls: these controls are applied to invoice flows received (EDI/API) and ensure that the content of the flow can be used, i.e. for verifying that the invoice is in a structured or mixed core format. 

  3. 3-Functional and business controls:  

    • oFunctional controls ensure that business objects are not duplicated, that they comply with business rules, and that correct addressing is possible when applicable. 

    • oData business controls are implemented on the side of the issuer and the recipient, and can be performed by either or automated by their respective platforms.  

+

 

+ + +
+ +
 
+

Figure 7: Checks performed by the Public invoicing portal

+

 

    1. 1.11 

 

      1. 2.11.1Flow technical controls  

 

+

The following controls will be applied to each flow received:

+

  1. 4-Antivirus control of the flow (invoice and attachments); 

  2. 5-Empty file control; 

  3. 6-File extension/type; 

  4. 7-Signature control (if there is one); 

  5. 8-Envelope and flow unicity control; 

  6. 9-Control of the size of the flow and of each file contained in the flow 

 

      1. 2.11.2Application controls 

 

+

These controls analyse the syntactic format of the flows received and their compatibility with the core formats defined in the regulations (UBL, CII, Factur-X).

+

 

      1. 2.11.3Functional controls 

+

Several functional controls are performed, including:

+

  • Semantic format and data structure control (see below),         

  • Unicity control (see focus below), 

  • Data consistency controls, 

  • Invoice number, 

  • Invoice addressing:  

    • oFor invoices issued, the platform controls that the recipient exists in the directory at the time of invoice submission; 

    • oThe receiving platform ensures that the recipient is one of its customers. 

 

+

All the rules governing the controls on invoices / e-invoicing are described in the Excel file "Annexe 1 - Format sémantique FE e-invoicing – Flux 1&2.xlsx".

+

 

  1. 1 

  2. 2 

    1. 2.1 

    2. 2.2 

    3. 2.3 

    4. 2.4 

    5. 2.5 

    6. 2.6 

    7. 2.7 

    8. 2.8 

    9. 2.9 

    10. 2.10 

    11. 2.11 

      1. 2.11.1 

      2. 2.11.2 

      3. 2.11.3 

0.0.0.1Data structure controls

+

 

 

+

For each type of flow, controls relating to syntax, cardinality and data format rules are performed upon entry to the solution.

+

 

+

Depending on the flows, two types of data will be controlled as input for the solution:

+

  • The data for which the cardinality makes them mandatory on the invoice;  

  • The data for which the management rules make them mandatory for transmission to the tax authority1. 

 

+

It should be noted that certain management rules relating to the framework for the exchange of dematerialised invoices in France may make certain data mandatory, even though it is indicated as optional in European standard EN16931.

+

 

          1. 2.11.3.1.1Cardinality control 

 

+

Cardinality is information that specifies whether a data item is mandatory or not, and states how often it can appear on an invoice. Cardinalities are defined by the EN 16931 standard:

+

  1. 1-If the cardinality of a data item is "1..1" or "1..n", the data must be included on the invoice. 

  2. 2-If the cardinality of a data is "0..1" or "0..n", the data is optional (except for data for which certain management rules make them mandatory, as mentioned below). 

+

The 1 after ".." indicates that the data will only be present once on the invoice. The n after ".." indicates that the data can be repeated infinitely.

+ +

In addition, if a header block has a cardinality of 0..1 or 0..n and the data in that block has a cardinality of 1.1, the data will only be mandatory if the header block is filled in.

+

 

+

E.g.

+ +

The BT-141 (Amount of expenses or charges) is only expected if the BG-28 (Charge or charge of an invoice line) is filled in.

+

 

+ +
+ +
 
+

Cardinality control allows the transmission of Flow 2, which is the flow corresponding to the full invoice exchanged between the parties of the commercial transaction. It is transmitted between the supplier and customer platforms. Flow 2 (full invoice) must be transmitted when:

+

  • The issuer and recipient go through two different registered private platforms (circuit C), 

  • Or, in circuit B, between a registered private platform and the public invoicing portal. 

 

+

Flow 2 (full invoice) is never sent to the tax authority.

+

 

 

          1. 2.11.3.1.2Management rule control for data transmission to the tax authority  

 

+

Management rules define the mandatory data expected by the tax authority. These rules cover both the transmission of invoicing data (e-invoicing) and the transmission of transaction and payment data (e-reporting). These management rules do not necessarily overlap with data made mandatory by their cardinality.

+

 

+

There are four main categories of management rules regarding the transmission of mandatory data to the tax authority:

+

  • -Rules stipulating that data is systematically mandatory as of 1 July 2024; 

  • -Rules stipulating that data is systematically mandatory as  of 1 July 2026; 

  • -Rules stipulating that data is mandatory when the data is to be reported in accordance with the regulations (CGI, Ccom, etc.) as of 1 July 2024; 

  • -The rules stipulating that a data is mandatory when the data is to be mentioned in accordance with the regulations (CGI, Ccom, etc.) as of 1 January 2026. 

 

+

In the latter two cases, this means that the data does not always appear in invoices or in transaction/payment data, because the situation where this data is required does not always arise. However, if the situation arises, it must be transmitted to the tax authority.

+

 

+

E.g.

+ +

The BT-147 (Price discount on the price of the item) has a cardinality of "0.1" but is made mandatory from 1/01/2026 by the management rule.

+

 

+ +
+ +
 
+

Control by management rules allows the transmission of Flow 1, comprising data strictly necessary for the administration and used for pre-filling VAT declarations, but also the transmission of e-reporting flows (Flows 8, 9 and 10).

+

 

+

If both the issuing company and the recipient of the invoice have chosen a registered private platform (circuit C), the issuing firm's registered private platform will be responsible for retrieving the full invoice data (flow 2) and transmitting only the invoicing data (flow 1) to the public invoicing portal. In all other cases (Circuits A and B1, B2), the public invoicing portal will extract the invoicing data (Flow 1).

+

 

0.0.0.2Focus on the unicity control

+

 

+

Unicity controls on the invoice number are performed by the public invoicing portal on the following:

+

  • Supplier’s invoice number 

  • Supplier ID: SIREN number (BT-30 of EN16931). If the supplier does not have a SIREN, the number chosen will be the complementary identifier (BT-29b of EN16931), based on the following qualifiers:  

 

    • o"0223" --> EU_OUTSIDE_FRANCE 

    • o"0227" --> OUTSIDE_EU 

    • o"0228" --> RIDET 

    • o"0229" --> TAHITI 

    • o"0226" --> INDIVIDUAL (this type of supplier can only perform B2G billing) 

 

  • Invoice year (year of the invoice date). 

 

+

Unique invoice identification aims to avoid invoicing errors (in particular double invoicing). For an invoice where all three of these data items are similar to those of a previously sent invoice, the invoice will be rejected by the platforms on technical grounds (PDP and PPF).

+

 

+
Failure to pass the unicity control will lead to systematic rejection of an invoice unless the previous invoice was subject to rejection on technical or functional grounds (addressing control only) resulting from the controls performed by the platform or a refusal due to a routing error.1
+

      1. 2.11.4Summary of controls  

 

+

These controls are summarised in the table below and detailed in the following chapters:

+

 

 

+ +
+

Type of control

+		 +

Control

+		 +

Result if the control fails

+
+

Technical controls

+		 +

Antivirus control

+		 +

The flow is declared inadmissible.

+
+

Empty file control

+
+

File type and extension control

+
+

Signature control and verification

+
+

Data flow uniqueness control (envelope / file name)

+
+

Size control

+
+

Application controls

+		 +

Syntactic format analysis (CII, UBL, Factur-X)

+		 +

The flow is declared inadmissible if any of the files it contains do not match the syntactic format.

+
+

Functional controls

+		 +

Semantic format analysis (the standard and specific rules)

+		 +

The invoice is rejected.

+
+

Uniqueness control

+		 +

The invoice is rejected.

+
+

Data consistency controls (codes and repositories)

+		 +

The invoice is rejected.

+
+

Addressing control (directory)

+		 +

The invoice is refused by the recipient (incorrect routing)

+
+

The invoice is rejected by the PDP on transmit (unknown recipient).

+
+

Invoice is denied by recipient (recipient error)

+
+

Business controls

+		 +

Data validity controls by the recipient

+		 +

The invoice is refused.

+
+ +

 

 

    1. 2.12Grounds for rejection and inadmissibility 

 

      1. 2.12.1Management of invoice inadmissibility/rejection/refusal 

 

+

The controls and their consequences are detailed in Chapter 2.12.2 Reasons for rejection/refusal and inadmissibility.

+

 

+

Terminology:

+

  • Inadmissibility: The platform (PPF or PDP) cannot receive or process the flow or its content, in case of a virus, an empty or unusable file (incorrect compression, unexpected format, etc.) or an unverifiable signature.  

    • oThis can be linked to the transfer monitor (EDI flow) or the invoicing software (empty file, for example), or any other component of the supplier’s information system or its PDP. Inadmissibility can be reported by the supplier’s or recipient’s platform and relates only to the flow. 

  • Rejection: Anomaly detected following functional controls by the platform (semantic format, data consistency, unicity, etc.). Rejection can be initiated by the supplier’s or recipient’s platform and relates to an invoice.  

    • oIn case of rejection by the recipient, a life-cycle flow is transmitted to the issuer’s platform to inform it of the rejection. 

  • Refusal: the recipient of the invoice refuses it, for example when the recipient is incorrect. 

    • oIn the event of a refusal by the recipient, a life-cycle flow is transmitted from the receive platform to the issuer’s platform to inform it of the refusal and indicate the grounds for refusal. A full list of reasons for refusal is available in the document "Annex 1 - Semantic Format FE e-invoicing - Flow 1 & 2" in the "Reason for Refusal" tab. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

0.1 + +

+ +

 
 
+ +

 
 
  + +

 

+

      1. 2.12.1 

0.1.0.1Life-cycle process for a flow and an invoice issued on the public invoicing portal (PPF)

+

0.1.0.2Life-cycle process for a flow and an invoice received within the PPF

+

 

+ +
+ +
 
+

Figure 9: Life-cycle process for a flow and an invoice received on the PPF

+

 

 

0.1.0.3Invoice management in the event of inadmissibility, rejection or refusal

+

 

+

The processing of rejections by platforms and rejections by recipients of invoices are harmonised to simplify their management. With the exception of refusal for routing error, rejection and refusal of an invoice results in the cancellation of Flow 1 when it has been sent to the tax authority.

+

  • Therefore, the status "Partially Approved" is recommended when only certain items of the invoice are contested in order to allow the seller to issue a partial credit note. 

  • In general, error corrections result in a credit note and a new invoice. Issuing a correcting invoice is possible but must be used to complement the original invoice.  

 

+

Management of refusals and rejections in B1 and C circuits:

+

 

 

+ +
+ +
 
+

Figure 10: Management of refusals and rejections in B1 and C circuits

+

 

+

Management of refusals and rejections under Circuit A:

+

 

+ +
+ +
 
+

Figure 11: Management of rejections and refusals in circuit A

+

 

+

Management of refusals and rejections in the B2 circuit:

+

 

 

+ +
+ +
 
+

Figure 12: Management of rejections and refusals in circuit B2

+ +

The table below presents the procedures for processing an invoice according to the type of non‑compliance at the technical/functional or business level:

+

 

+ +
+

Status

+		 +

Control

+		 +

IMPACT ON THE INVOICE

+		 +

FLOW 1

+
+

REJECTION ON TECHNICAL GROUNDS by the transmitting platform

+		 +

Application controls of the syntactic format

+		 +

Rejection on technical grounds: Flow 2 can be returned to the transmitting platform after correction with the same invoice numbers

+		 +

For all circuits (A, B and C), the data of the rejected Flow 2 will not have been extracted by the transmitting platform. The associated Flow 1 will not have been addressed to the tax authority.

+ +

After correction by the issuer, the transmitting platform will extract the data and generate a flow 1 (which incorporates the corrections made).

+		 +

For all circuits (A, B and C), only Flow 1 (which incorporates the corrections made) will be sent to the tax authority.

+
+

REJECTION ON TECHNICAL GROUNDS by the receiving platform)

+		 +

Application controls of the syntactic format

+		 +

Rejection on technical grounds: Flow 2 can be reissued by the transmitting platform after correction with the same invoice numbers

+

  • -Circuits A and B2 (PPF recipient): Flow 1 will not have been addressed; 

 

  • -Circuits B1 and C (recipient PDP): if rejection on technical grounds by the receiving platform, flow 1 will have been addressed by the transmitting platform 

  • -Circuits A and B2: In these circuits, the PPF is responsible for generating Flow 1 and referring it to the tax authority. If the PPF as a receiving platform technically rejects a Flow 2, then the associated Flow 1 will not be sent to the tax authority. Only Flow 1 (which includes corrections) is sent to the tax authority. 

 

  • -Circuits B1 and C: following the rejection on technical grounds of a Flow 2 by the receiving platform, the transmitting platform must reissue this Flow 2 once the changes have been made (resuming the flow and/or its data). This action does not affect the original Flow 1 transmitted (which does not include corrections) by the transmitting platform to the tax authority, and does not require any intervention by the issuer of the invoice. 

+

REJECTION ON FUNCTIONAL GROUNDS by the transmitting platform

+		 +

Functional controls i.e. semantic format - consistency - unicity

+		 +

Rejection on functional grounds:

+

  • -Rejection of original invoice before issue  

  • -If the original rejected invoice has already been accounted for by the company, then it may be subject to an internal credit note (voucher) to cancel it.  

  • -Issue of a second invoice (new number)  

+

'

+		 +

For all circuits (A, B and C), the rejected invoice data will not have been retrieved by the transmit platform. The associated Flow 1 will not have been addressed to the tax authority.

+ +

Following the issue of the second invoice, the transmit platform will extract the data and generate a flow 1. This Flow 1 will be addressed to the tax authority.

+		 +

All circuits:

+

  • -No Flow 1 for the original rejected invoice.  

  • -If the transaction has been recorded in the company's accounts, it will have to justify the cancellation of the invoice ("internal credit"), but this document will not have to be sent to the transmit platform.  

  • -The second invoice follows the classic route and will give rise to a Flow 1.  

+

REJECTION ON FUNCTIONAL GROUNDS by the receiving platform

+		 +

Functional controls i.e. semantic format - consistency - unicity

+		 +

Rejection on functional grounds:

+

  • -Issue of original invoice 

  • -Rejection of original invoice following receipt 

  • -Since the original invoice has already been accounted for by the issuing company, it must be subject to an internal credit note (voucher) to cancel it.  

+

Issue of a second invoice (new number).

+

  • -Circuits A and B2 (PPF recipient): Flow 1 will not have been addressed; 

 

  • -Circuits B1 and C (PDP recipient): if rejection on functional grounds by the receive platform, flow 1 will have been addressed by the transmit platform 

  • -Circuits A and B2: In these circuits, the PPF is responsible for generating Flow 1 and referring it to the tax authority. If the PPF as a receive platform rejects an invoice on functional grounds, the associated Flow 1 will not be addressed to the tax authority. Only Flow 1 associated with the second invoice is addressed to the tax authority. 

 

  • -Circuits B1 and C: following the rejection of an invoice by the receive platform on functional grounds, the transmit platform must issue a second invoice. Flow 1 associated with the original invoice is cancelled. Only Flow 1 associated with the second invoice is addressed to the tax authority. 

 

  • -Since the original invoice has already been accounted for by the company, it must be the subject of an internal credit note (voucher) to cancel it, but this document will not have to be sent.  

+

REFUSAL
by the recipient

+

 

 +

Routing error that does not change the invoice (e.g. after updating the directory, the information taken into account for routing the invoice has become obsolete)

+		 +

The flow can be returned after the new data in the directory has been considered, with the same invoice numbers.

+		 +

The original Flow 1 is not cancelled. Refusal of an invoice with a "routing error" as the reason is the only case of refusal that does not cause the original Flow 1 to be cancelled.

+		 +

For all circuits (A, B and C): the initial Flow 1 is not cancelled. However, in order to inform the tax authority of the new transmission of Flow 2 (following the inclusion of the directory updates), the transmitting platform will again have to transmit to the tax authority the status of "submitted" for the invoices of Flow 2.

+
+

REFUSAL
by the recipient

+

 

 +

Error on the invoice requiring modification of the data

+		 +

Refusal of the invoice:

+

  • -Issue of original invoice 

  • -Refusal of original invoice following receipt 

  • -Option 1: Issue of a correcting invoice  

  • -Option 2: Transmission of a credit note and a second invoice 

 

+

In both cases, a reference to the original invoice must be included in the correcting invoice or credit note.

+		 +

Refusal of the original invoice will result in the total cancellation of the associated flow 1, regardless of the reason for refusal.

+

 

 +

Option 1: Correcting invoice "cancels and replaces"

+ +

The correcting invoice follows the classic route and gives rise to a flow 1. This new flow 1 replaces the flow 1 of the original invoice.

+ +

Therefore, Option 1 is only appropriate if the correcting invoice replaces the entire original invoice.

+ +

If the correcting invoice only partially replaces the original invoice, then it is advisable not to refuse the original invoice, but to use the statuses of "suspended", "partially approved" or "in dispute".

+

 

+

Option 2: Issue of a credit note and a second invoice  

+ +

Generates 2 new Flow 1: the Flow 1 will be cancelled for the tax authority if it refers to the original invoice that was rejected.

+ +

Only the new Flow 1 (new invoice) will be considered.

+
+

REFUSAL
by the recipient

+		 +

Recipient error

+

 

 +

Refusal of the invoice:

+

  • -Issue of original invoice 

  • -Rejection of original invoice following receipt 

  • -Since the original invoice has already been accounted for by the issuing company, it must be subject to an internal credit note (voucher) to cancel it.  

  • -Issue of a new invoice (new number) to the right recipient.  

 

 +

Refusal of the original invoice will result in the total cancellation of the associated Flow 1, regardless of the reason for refusal.

+

 

 +

For all circuits (A, B and C): Cancellation of initial Flow 1

+

 

+

N.B.: If the original invoice has been accounted for by the recipient (despite the recipient's refusal), the issuing company must send the recipient a credit note or a correcting invoice to cancel the original invoice.

+

 

 

+ +

 

      1. 2.12.2Reasons for different types of controls 

 

+

To allow users to have a better understanding and make corrections, reasons shall be given for the various cases of inadmissibility rejection and refusal.

+ +

In the event of rejection or inadmissibility, the identifiers of the document or data flow in question shall be specified and, as far as possible, the reasons shall be explained in detail to facilitate correction by the issuer of the data flow or document.

+

 

+

These reasons shall apply to all modes of transmission of a data flow/document (EDI, API).

+ +

These reasons shall allow the issuer to:

+

  • understand reasons for the rejection and/or refusal of an object  

  • set up corrective actions to reissue the object 

 

+

Thus, a platform can generate either:

+

  • -a rejection in the event of irregularities detected after functional controls  

  • -a refusal initiated by the recipient  

 

 

 

 

+

The grounds are in alignment with the four control categories.

+

 

+ +
+

Type of control

+		 +

Control

+		 +

Description of the grounds

+

 

 

 

 

 

+

Technical controls

+

 

+

Antivirus control

+		 +

The data flow cannot be processed because it is considered dangerous under the antivirus rules.

+
+

Empty file control

+		 +

The flow is empty.

+
+

File type and extension control

+		 +

The name of the data flow does not follow the naming rules.

+
+

Signature control and verification

+		 +

The signature of the data flow is invalid.

+
+

Data flow unicity control (envelope / file name)

+		 +

The issued flow has already been sent and received.

+

 

+

Application controls

+		 +

Syntactic format analysis (CII, UBL, Factur-X)

+		 +

The document issued does not comply with the expected format.

+

 

+

The name of the data (the tag and its value) in error will be mentioned, where applicable.

+

 

 

+

Functional controls

+

 

 

 

 

 

 

 

 

 

 

 

 

+

Functional controls

+

 

+

Semantic format analysis (the standard and specific rules)

+

 

 

 

+

Semantic format analysis (the standard and specific rules)

+		 +

The document issued does not comply with the standard or the specific rules.

+

 

+

The data item or data group that contravenes the rule shall be specified, as well as the rule that has been violated.

+

 

 

+

Unicity control

+		 +

The document has already been received.

+

 

+

The identifier of the document shall be specified.

+

 

+

Data consistency controls (codes and repositories)

+		 +

The value of the data in a document is not compliant or is not on the list of authorised codes or repositories.

+

 

 

+

Address control

+		 +

The recipient shall control that it is the intended recipient of the document.

+

 

+

The document issuer shall ensure that the recipient’s data is properly qualified (routing data present in the directory).  

+

 

 

 

+

Business controls

+

 

 

 

+

Data validity controls by the recipient

+		 +

Reasons for refusal related to controls by the recipient shall be forwarded unaltered to the invoice issuer. They should be as explicit and precise as possible to facilitate correction by the invoice issuer.

+
+ +

 

+

+ +

FOR INFORMATION, USE CASES ARE TRANSFERRED IN A SEPARATE DOCUMENT

+

  1. 3Introduction to flows  

    1. 3.1Mapping of flows described in the external specifications 

+

There are four types of flow in the public invoicing portal ecosystem:

+

  • E-invoicing flows, 

  • Life-cycle flows, 

  • E-reporting flows, 

  • Directory flows. 

 

+

Three modes (Portal, EDI, Service) are possible for transmission,        making available and recovering these flows on the public invoicing portal and, depending on the services offered by registered private platforms, for the flows of their customers and partners.

+ +

The e-invoicing and life-cycle flows are used in the three invoicing circuits (A, B1, B2, and C) described in the section on the “Y scheme”.

+ + +
+ +
+ +
+ +
 
 
+ + +
+ +

Note: In this scheme and in the descriptions and schemes that follow, “supplier” also designates a third party or a subcontractor.

+

 

 

 

+

Description of the different flows:

+

 

+ +
+

Flow type

+		 +

Flow number

+		 +

Stakeholder(s)

+		 +

Description

+
+

E-invoicing

+		 + +
+ +
 
 +

Supplier’s PDP (PDPE)

+ +

Public invoicing portal (PPF)

+ +

Tax authority

+		 +

Flow of transmission of mandatory invoice data between the supplier’s transmit platform (PDPE) and the PPF, in circuit C.

+ +

For circuits A, B1 and B2, this flow will be generated by the PPF on receipt of the invoices (flow 2).

+ +

After control or generation by the PPF, this flow is forwarded to the tax authority’s IS.

+
+

E-invoicing

+		 + +
+ +
 
 +

Supplier

+ +

Supplier’s PDP (PDPE)

+ +

Public invoicing portal

+ +

Buyer’s PDP (PDPR)

+ +

Buyer

+		 +

The invoice flow (e-invoicing), in one of the 3 core syntactic formats, according to the semantic format described in these specifications (see chapter on “E-invoicing flow” below).

+
+

In circuit A, the flow passes from the supplier to the PPF, then from the PPF to the buyer.

+
+

In circuit B1, the flow passes from the supplier to the PPF, then from the PPF to the buyer’s receive platform (PDPR) before being handed over or made available to the buyer by the PDPR.

+ +

In circuit B2, the flow passes from the supplier to its transmit platform (PDPE), then from the PDPE to the PPF before being handed over or made available to the buyer by the PPF.

+
+

In circuit C, the flow passes from the supplier to its transmit platform (PDPE), then from the PDPE to the buyer’s receive platform (PDPR) before being handed over or made available to the buyer by the PDPR.

+
+

E-invoicing

+		 + +
+ +
 
 +

Supplier

+		 +

These invoice flows, in syntactic formats not provided for in the core, can be accepted by the emission and reception PDPs, as inputs and outputs, according to the service contract that these platforms have with their customers and partners.

+ +

They can thus replace flow 2 in circuit C and are not described in these specifications.

+
+

E-invoicing / B2G

+		 + +
+ +
 
 +

Supplier

+ +

Public invoicing portal

+		 +

These invoice flows are reserved for B2G in the framework of backward compatibility.

+
+

E-invoicing / B2G

+		 + +
+ +
 
 +

Public invoicing portal

+ +

Buyer

+		 +

These invoice flows are reserved for B2G in the framework of backward compatibility.

+
+

Life cycle

+		 + +
+ +
 
 +

Supplier

+ +

Supplier’s PDP (PDPE)

+ +

Public invoicing portal

+ +

Buyer’s PDP (PDPR)

+ +

Buyer

+ +

Tax authority

+		 +

The life-cycle flow can be used in the context of e-invoicing and e-reporting.

+ +

In e-invoicing, it notifies the issuer of the flow (the supplier) of progress with invoice processing and its recipient (the buyer) of additions made by the issuer.

+ +

In e-reporting, it notifies the issuer of the flow (supplier or buyer) of the processing status of the issued e-reporting flow, as well as the transmission of payment data relating to electronic invoices by the supplier or buyer.

+ +

It is generated in the core syntactic format, according to the semantic format described in these specifications (see chapter on “Life-cycle flow” below).

+
+

In circuit A, it is issued by the PPF to the supplier (sending the flow or making it available), at the buyer’s initiative (updating the status of the invoice after making it available) or not (rejection before making the invoice available). It can also be issued by the PPF to the buyer (sending the flow or making it available) if the supplier makes additions to it.

+
+

In circuit B1, it is issued by the buyer’s receive platform (PDPR) to the PPF, at the buyer’s initiative (updating the status of the invoice after making it available) or not (rejection before making it available). The PPF will deliver this life cycle to the supplier (sending the flow or making it available). The PPF may also transmit additions made by the supplier as a life-cycle flow to the buyer’s receive platform (PDPR).

+ +

In circuit B2, it is issued by the PPF to the supplier’s transmit platform (PDPE), at the buyer’s initiative (updating the status of the invoice after making it available) or not (rejection before making it available). The PDPE will return this life cycle to the supplier (sending the flow or making it available).

+
+

In circuit C, the PDPE is also responsible for sending the PPF the life cycle corresponding to the submission of the invoice by the supplier.

+ +

The life-cycle flow can also be issued by the buyer’s receive platform (PDPR) to the supplier’s transmit platform (PDPE), at the buyer’s initiative (updating the status of the invoice after making it available) or not (rejection before making it available). This life cycle must be transmitted to the PPF in parallel, to inform the tax authority. The PDPE will return the life cycle to the supplier (sending the flow or making it available).

+
+

The life-cycle flow also allows sending of the invoice payment data return (domestic B2B, international B2B and B2C). This flow must be issued for invoices forwarded to the tax authority (flow 1, flow 2 or flow 3 for domestic B2B invoices, flow 8 for international B2B invoices and flow 9 for B2C invoices).

+ +

In this case, it is issued by the supplier to its transmit platform (PDPE or PPF).

+
+

All life-cycle flows corresponding to mandatory statuses, received or generated by the PPF, are passed on to the tax authority’s IS.

+
+

Life cycle

+		 + +
+ +
 
 +

Supplier

+ +

Supplier’s PDP (PDPE)

+ +

Buyer’s PDP (PDPR)

+ +

Buyer

+		 +

These life-cycle flows, in syntactic formats not provided for in the core, can be accepted by the emission and reception PDPs, as inputs and outputs, according to the service contract that these platforms have with their customers and partners.

+ +

They can thus replace flow 6 in circuit C and are not described in these specifications.

+ +

Note that: Since these flows are not part of the core function, they will not be accepted by the PPF and will have to be converted into a 6 flow by the platforms.

+
+

E-reporting

+		 + +
+ +
 
 +

Supplier

+ +

Buyer

+ +

Supplier’s PDP (PDPE)

+ +

Buyer’s PDP (PDPR)

+ +

Public invoicing portal

+

 

 +

International B2B invoice flow in one of the 3 core syntactic formats, according to the semantic format described in these specifications (see chapter on “E-reporting flow” below).

+ +

It is issued by the supplier (reporting invoices issued) to its transmit platform (registered private platform or public invoicing portal), or by the buyer (reporting invoices received) to its receive platform (registered private platform or public invoicing portal), for consolidation and forwarding of data to the tax authority.

+ +

Note: These flows cannot be exchanged between PDPs and PPF. Data from these flows should be included in flow 10 messages transmitted by PDPs to the PPF.

+
+

E-reporting

+		 + +
+ +
 
 +

Supplier

+ +

Supplier’s PDP (PDPE)

+ +

Public invoicing portal

+

 

 +

B2C invoice flow in one of the 3 core syntactic formats, according to the semantic format described in these specifications (see chapter on “E-reporting flow” below).

+ +

It is issued by the supplier (reporting invoices issued) to its transmit platform (Registered private platform or public invoicing portal), for consolidation and forwarding of data to the tax authority.

+ +

Note: These flows cannot be exchanged between PDPs and PPF. Data from these flows should be included in flow 10 messages transmitted by PDPs to the PPF.

+
+

E-reporting

+		 + +
+ +
 
 +

Supplier

+ +

Buyer

+ +

Supplier’s PDP (PDPE)

+ +

Buyer’s PDP (PDPR)

+ +

Public invoicing portal

+

 

 +

Reporting flow in e-reporting format.

+ +

This flow is planned for all the following:

+

  • 10.1: Transmission of international B2B or B2C invoice data, if it cannot be transmitted in the expected structured invoice format (flows 8 and 9).   

  • 10.2: Transmission of invoice payment data (domestic B2B, international B2B and B2C) for reporting payments received for invoices transmitted (flow 8 or 9) or not (reported by flow 10.1) to the tax authority(1). 

  • 10.3: Transmission of B2C transaction data. 

  • 10.4: Transmission of payment data for B2C transactions. 

+

It is issued by the supplier (reporting invoices issued [international B2B or B2C] or B2C transactions) to its transmit platform (Registered private platform or public invoicing portal), or by the buyer (reporting invoices received [international B2B]) to its receive platform (Registered private platform or public invoicing portal), for reporting to the tax authority.

+ +

The data can be transmitted in the same flow or separated according to the needs and capacity of the issuer. The platform receiving the flow will be responsible for aggregating the data for each reporting party [at the required frequency].

+

 

+

(1) The life-cycle flow should be preferred to flow 10.2 as far as possible.

+
+

Directory

+		 + +
+ +
 
 +

Issuer

+ +

Public invoicing portal

+		 +

This flow is a request to consult the directory of invoice addressing information.

+ +

The scope of the data and the associated syntactic format will be added in a later version of these specifications (see chapter on “Directory Flow” below).

+
+

Directory

+		 + +
+ +
 
 +

Recipient

+ +

Public invoicing portal

+		 +

This flow is a request from an invoice recipient (Buyer) to update its information in the directory. The scope of the data and the associated syntactic format will be added in a later version of these specifications (see chapter on “Directory Flow” below).

+
+

Directory

+		 + +
+ +
 
 +

Buyer’s PDP (PDPR)

+ +

Public invoicing portal

+		 +

This flow is a request to update the directory by a buyer’s receive platform (PDPR) at the buyer’s request (flow 12).

+ +

The scope of the data and the associated syntactic format will be added in a later version of these specifications (see chapter on “Directory Flow” below).

+
+

Directory

+		 + +
+ +
 
 +

Supplier’s PDP (PDPE)

+ +

Public invoicing portal

+		 +

This flow is a request to consult the directory by a transmit platform (PDPE) for the routing of invoices entrusted to it by the supplier.

+ +

The scope of the data and the associated syntactic format will be added in a later version of these specifications (see chapter on “Directory Flow” below).

+
+ +

 

    1. 3.2Overview of flows around the public invoicing portal 

 

+

The data exchanged with the public invoicing portal takes the form of invoices, statuses, invoicing data, and transaction data.

+

 

+

Exchanges between users and their platform(s) as well as between the public invoicing portal and registered private platforms are normalised. They are available in a number of technical formats to ensure the proper use of the data by the tax authority.

+

 

+

The public invoicing portal complies with European standard EN16931.

+

 

      1. 3.2.1Naming of the flows 

 

+

The name of the flow envelope is formalised as follows:

+

 

+

TTTIIIIV_CCCCCC_NNNNNNNNNNNNNNNNNNNNNNNNN

+

 

  • -TTTIIIIV: Interface code  

  • -CCCCCC: Partner application code  

  • -NNNNNNNNNNNNNNNNNNNNNNNNN: Flow identifier made up of: 

 

    • oPartner application code on first 6 characters  

    • oA sequence number of between 5 and 19 characters maximum. 

 

+

Based on the flow and its format, here is the list of expected interface codes:

+

 

 

+ +
+

Description of the flow

+		 +

Object

+		 +

Format (syntax) of the flow

+		 +

Interface code

+
+

B2B invoice flow - F2

+		 +

e-invoicing

+		 +

UBL

+		 +

FFE0211A

+
+

CII

+		 +

FFE0212A

+
+

Factur-X

+		 +

FFE0213A

+
+

   B2G invoice flow

+		 +

UBL

+		 +

FFE0411A

+
+

CII

+		 +

FFE0412A

+
+

Factur-X

+		 +

FFE0413A

+
+

Life cycle business object - F6

+		 +

e-invoicing

+		 +

CDAR

+		 +

FFE0614A

+
+

e-reporting

+		 +

CDAR

+		 +

FFE0624A

+
+

Directory

+		 +

CDAR

+		 +

FFE0634A

+
+

life cycle; life-cycle

+		 +

CDAR

+		 +

FFE0654A

+
+

Life-cycle flow - F6

+		 +

e-invoicing

+		 +

CDAR

+		 +

CFE + initial interface code + NNNNNNNNNNNNNNNNNNNNNNNNN

+
+

e-reporting

+		 +

CDAR

+		 +

CFE + initial interface code + NNNNNNNNNNNNNNNNNNNNNNNNN

+
+

Directory flow

+		 +

CDAR

+		 +

CFE + initial interface code + NNNNNNNNNNNNNNNNNNNNNNNNN

+
+

Life-cycle flow

+		 +

CDAR

+		 +

CFE + initial interface code + NNNNNNNNNNNNNNNNNNNNNNNNN

+
+

Mandatory data transmission flow - F1

+		 +

e-invoicing

+		 +

UBL

+		 +

FFE0111A

+
+

CII

+		 +

FFE0112A

+
+

Factur-X

+		 +

FFE0113A

+
+

B2Bi invoice flow - F8

+		 +

e-reporting

+		 +

UBL

+		 +

FFE0821A

+
+

CII

+		 +

FFE0822A

+
+

Factur-X

+		 +

FFE0823A

+
+

B2C invoice flow - F9

+		 +

e-reporting

+		 +

UBL

+		 +

FFE0921A

+
+

CII

+		 +

FFE0922A

+
+

Factur-X

+		 +

FFE0923A

+
+

Declarations - F10

+		 +

e-reporting

+		 +

Specific format

+		 +

FFE1025A

+
+

Directory flow - F11

+		 +

Directory

+		 +

Specific format

+		 +

FFE1135A

+
+ +

 

+

For the Life-cycle flow - F6 interface codes, the prefix of the interface code of the flow on which the life cycle is based must be changed to "CFE".

+

 

 

+

The public invoicing portal receives an invoice from an issuer:

+

  1. 1-A Supplier (partner application code FFF251) issues a UBL invoicing flow  

+

FFE0211A_FFF251_FFF2514001202300000010023

+

  1. 2-PPF Action: life-cycle flow issuance 

+

CFE0211A_FFF251_FFF2514001202300000010023

+

 

 

+

The public invoicing portal issues an invoice to a recipient:

+ + +

  1. 1-The public invoicing portal issues a UBL invoice for a buying entity AAA324 

+

FFE0211A_AAA324_PPF0014001202300000010023

+

 

  1. 2-Buyer action AAA324: life-cycle flow issuance to the public invoicing portal 

+

CFE0211A_AAA324_PPF0014001202300000010023

+
+ +

 

 

 

      1. 3.2.2E-invoicing flow 

 

+

The semantic formats for flows 1 and 2 are defined in "Annexe 1 – Format sémantique FE e-invoicing.xlsx", including the following tabs:

+

    • Version: identification of changes in the various versions of the Annex 

    • N.B.: explanations about how the file works 

    • FE - Flow 2 - UBL: semantic format for UBL for flow 2 

    • FE - Flow 1 - UBL: semantic format for UBL for flow 1 

    • FE - Flow 2 - CII: semantic format for CII for flow 2 

    • FE - Flow 1 - CII: semantic format for CII for flow 1 

    • Factur-X FR CII D16B - Flow 2: semantic format for Factur-X for Flow 2 

    • Factur-X FR CII D16B - Flow 1: semantic format for Factur-X for Flow 1 

 

 

+

The semantic format of flow 6 is defined in "Annexe 2 – Format sémantique FE CDV – Flux 6.xlsx", including the following tabs:

+

    • Version: identification of changes in the various versions of the Annex 

    • N.B.: explains how the file works 

    • Life cycle FE - CI ARM: semantic format of the life cycle message 

    • Statuses: summary of possible statuses by business object 

 

 

+

Management rules are defined in "Annexe 7 – Règles de gestion.xlsx", including the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • Public invoicing portal management rules: specific management rules 

  • Standard EN16931 rules: management rules of the standard 

  • EN16931 Code lists: Repositories available for each data item (BT) resulting in a repository 

  • Table of reasons for refusal: detailed description of the reasons for refusal of an invoice 

 

 

 

+

The invoice formats are as follows:

+

  • UBL 

  • CII 

  • Factur-X (mixed format) 

 

+

The semantic format of standard EN16931 is modelled as follows:

+

 

+ +
+ +
 
+

Figure 14: Semantic format of EN16931 standard

+

 

      1. 3.2.3UBL format  

 

+

The exchange standard for this format is that promoted by OASIS (the Organisation for the Advancement of Structured Information Standards) in the form of the Universal Business Language standard version 2.1 for all elements related to the Invoice element defined by the XML scheme. The tags in the semantic format file are located under the Invoice root tag of an XML document that complies with these standards.

+

 

+

Each tag complies with OASIS UBL 2.1 specifications in terms of name, cardinality and format (data type). Tags that are optional or absent in flows 1 & 2 but required in UBL format must be entered, if necessary using constants compliant with the semantic format described in the UBL specifications (e.g. “null” or “xxx”).

+

 

      1. 3.2.4CII format 

 

+

The exchange standard adopted for this format is that promoted by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) in the form of the Core Component Technical Specification (CCTS) version 3.0. The tags in the semantic format file are located under the CrossIndustryInvoice root tag of an XML document that complies with these standards.

+

 

+

Each tag complies with CII specifications in terms of name, cardinality and format (data type). Tags that are optional or absent in flows 1 & 2 but required in CII format must be entered, if necessary using constants compliant with the semantic format described in the CII specifications (e.g. “null” or “xxx”).

+

 

      1. 3.2.5Factur-X format 

 

+

The Factur-X type is part of the European semantic data model for the electronic invoice (EN 16931-1).

+

 

+

A mixed Factur-X type invoice is a file in PDF/A-3 format corresponding to a single invoice. The PDF/A-3 file is both the directly readable representation of the invoice and the envelope for the structured data file and any additional attachments. The invoice is the PDF/A-3 file as a whole, including the embedded files, i.e. the structured data file (XML file) and the additional attachments.

+

 

+

For this format, only the following profiles are allowed:

+

  • BASIC 

  • BASIC WL 

  • EN 16931 

  • EXTENDED 

  • EXTENDED FR B2B 

 

+

This document is organised into several tabs: the instructions tab, tabs dedicated to the various semantic formats, and a tab grouping the enumeration lists. The “Rules of standard EN16931” tab contains all the management rules of the standard which are in addition to the specific CPRO management rules which can be found in each of the tabs for each semantic format (columns Q and R).

+

 

 

+

All invoice data must feature in the readable PDF while the structured data file contains only the information needed to automate invoice processing by the recipient. Hence the structured data file can only contain information that is in the readable PDF, but it may not contain all this information, especially if it is not automatically usable.

+

 

+

All invoice data is included in the readable PDF, so it is not mandatory to include an attachment in the structured data of the invoice. All attachments are thus additional attachments (type “02”). They can be located in the PDF/A-3 (XMP) metadata or in the structured data file (XML file).

+

 

 

 

  • Semantic format of flows 1 and 2 

 

+

The semantic format of flows 1 and 2 is defined in the attached Excel file "Annexe 1 - Format sémantique FE e-invoicing - Flux 1&2.xlsx".  

+

 

+

The PDPs send either flow 1 or flow 2 to the PPF, depending on the invoicing circuit used. Two cases are possible:

+

  1. 1.Circuit C: The invoice issuer’s PDP must generate and transmit flow 1 to the PPF hub when the invoice recipient is also behind a PDP. The transmission of this flow is then mandatory so that the PPF can forward the invoicing data to the tax authority.  

  2. 2.Circuits A and B: When the issuer and/or recipient of the invoice is connected to the public invoicing portal, the PPF is responsible for generating and sending Flow 1 to the tax authority. In this case, even if the issuer is behind a PDP, the PDP does not need to send flow 1 to the PPF.  

 

+

The following tabs are to be found in this file:

+

  • Instructions: explains how the file works 

  • Version: tracks changes between document deliveries 

  • B2B - Flow 2 - UBL: semantic format for the invoice UBL in its entirety 

  • B2B - Flow 1 - UBL: semantic format for the UBL of the invoicing data to be transmitted to the tax authority 

  • B2B - Flow 2 - CII: semantic format for the invoice CII in its entirety 

  • B2B - Flow 1 - CII: semantic format for the CII of the invoicing data to be forwarded to the tax authority 

  • Factur-X FR CII D16B - Flow 2: semantic format for invoice Factur-X in its entirety 

  • Factur-X FR CII D16B - Flow 1: semantic format for the Factur-X of the invoicing data to be sent to the tax authority1 

 

      1. 3.2.6Changes to standard EN16931 

 

+

For some formats, extensions to the standard are necessary to handle certain management cases. Below are the modifications to EN16931 that are under investigation.

+

 

+

Since these requests for changes to the standard are not guaranteed at the start of the reform, the annexes to the external specifications incorporate the following changes in the form of extensions.

+

 

  1. 3 

    1. 3.1 

    2. 3.2 

      1. 3.2.1 

      2. 3.2.2 

      3. 3.2.3 

      4. 3.2.4 

      5. 3.2.5 

      6. 3.2.6 

0.1.0.4Managing multi-order / multi-delivery invoices

+ +

For multi-order invoices, where each order may have a different delivery address, this information should be added to the invoice line (Block BG-25).

+

 

+

In addition, each order may have different delivery dates, so a modification of the standard has been requested so that delivery information can be included at the order level (Block BG-13).

+

 

+

The data to be added at UBL/CII level (already present in Factur-X) is referenced in blocks EXT-FR-FE-BG-10 and EXT-FR-FE-BG-11 and in tags EXT-FR-FE-FE-149 to EXT-FR-FE-157 of Annex 1.

+

 

0.1.0.5Managing a payer in an invoice (PAYER)

+ +

In the context of an already paid invoice or invoice payable by a third party known at the time of invoicing, it should be possible to identify a third-party “PAYER’ in the invoice to facilitate reconciliation for the buyer, and/or allow the Payer to send payment.

+ +

A modification of the standard is requested in order to add a new "PAY" block to be able to indicate for each invoice who the "PAYER" is, if different from the BUYER, with the data associated with the EXT-FR-FE- BG-02 block in annex 1.

+ +

In addition, in case of multiple Payees/Payers, the addition of a “Payee” and a “Payer” under block BG-16 has also been requested to identify who is the Payer and who is the Payee for each part payment. This is necessary, for example, in the case of part payment of an invoice by a third party, e.g. an insurer, excluding the excess, or a grant collected directly by the supplier.

+

 

0.1.0.6Adding a qualifier for the beneficiary (PAYEE)

+ +

When an invoice is to be paid to a party other than the supplier, it is not possible to qualify that third party.

+ +

Example:

+ +

 - Cash pooling within a group

+ +

 - “Conventional” factoring in which the invoice is assigned to a bank or factor by the issuing supplier

+

 

+

A modification of the standard has been requested to allow addition of a qualifier to the invoice beneficiary to identify its role, extracted from a list of UNCL 3035 codes.

+ +

The extensions in block BG-10 in annex 1 are used to qualify the beneficiary. As a reminder, the BENEFICIARY block can be used to indicate the name of the factor.

+

 

0.1.0.7Adding the INVOICEE role within an invoice

+ +

When an invoice must be sent to a third party other than the buyer, it is not currently possible to identify the company being invoiced.

+ +

Example: a central department (head office) places an order on behalf of a shop (identified as the BUYER), which receives the goods. The invoice is sent to Headquarters (ADDRESS A (INVOICEE)) for processing and payment of the invoice.

+

 

+

The addition of a block ADDRESS A (INVOICEE) with the data present at the level of block EXT-FR-FE-BG-04 of Annex 1 has therefore been added as an extension in Annex 1 (this can be used in the presence of a transparent intermediary).

+

 

0.1.0.8Consider other parties to be added to EN16931

+ +

Depending on the different management cases identified in the context of the reform of B2B electronic invoicing in France, certain additional parties may be required, with the same information regarding the address and contact for the supplier blocks (BG-5 and BG-6) and Buyer blocks (BG-8 and BG-9). A change in the standard to incorporate the following blocks has thus been requested:

+ +

- An "INVOICER", the party that creates the invoice on behalf of the seller, e.g. when it is a third party such as a market platform, or a P2P / O2C platform. The management of this party in the invoice is specified in Annex 1 at the level of the EXT-FR-FE-BG-05 block.

+ +

- A "SALES AGENT", who validates an invoice (representative). The management of this party in the invoice is specified in Annex 1 at the level of the EXT-FR-FE-BG-03 block.

+ +

- A "BUYER AGENT", a party that buys goods or services on behalf of the buyer and can play a role in the matching and approval processes, and may also act as a biller (invoice processing) or payer (invoice payment). The management of this party in the invoice is specified in Annex 1 at the level of the EXT-FR-FE-BG-01 block.

+ +

- A “BUYER TAX REPRESENTATIVE”, the party representing the buyer with regard to its VAT obligations, in particular the collection of VAT in case of reverse charge or intra-community delivery. This party has not been added to the extensions because there is no UBL at the moment.

+

 

0.1.0.9Data alignment for the beneficiary role (BG-10)

+ +

In the context of invoicing to the public sphere, it is useful to have other information concerning the invoice beneficiary.

+ +

For the sake of consistency, a modification to the standard has been requested to align the blocks concerning the parties within an invoice (the seller [BG-4], buyer [BG-7], beneficiary [EXT-FR-FE-27 to l’EXT-FR-FE-42]).

+

 

0.1.0.10Request to allow attachments to be categorised

+ +

Attachments may be added in accordance with the rules currently laid down in Annexes 1, 2 and 7, relating to Flow 2, Flow 6 and Management Rules, respectively. Special attention will be paid to:

+

  • -When typing the attachment according to the repository provided, by tag: 

    • oFlow 2: BT-125-2,  

    • oFlow 6: MDT-96-3   

  • –The primary or complementary character of the attachment (by accounting with B2G):  

    • oFlow 2: BT-122 

    • oFlow 6: MDT-96-1 

 

0.1.0.11Extension to handle certain management cases

+ +

In the context of invoicing to the public sphere, several notes are currently provided for in the invoice line. In addition, as part of the reform and as stipulated in Decree No. 2014-928 of 19 August 2014 on DEEE (electrical and electronic equipment waste), it is planned to enter the DEEE eco-tax in this data item.

+ +

If the supplier wishes to provide further information on the invoice line, it may use the BT-127-00 block by adding the EXT-FR-FE-183 extension and changing its cardinality from 0.1 to 0.N.

+

 

      1. 3.2.7Managing the readable invoice 

 

+

The platforms (PDP or PPF) will be required to maintain a readable version of the invoice submitted for the issuer and the invoice received for the recipient. This readable version can be part of the invoice submitted in the case of the mixed format or it can accompany the invoice (attachment) in the case of structured formats (UBL or CII).

+

 

      1. 3.2.7 

0.1.0.12Readable version of the invoice submitted for the issuer

+

 

+
The taxable entity must be able to provide a readable version of the invoice1 when so requested by the tax authority. It is therefore always responsible for it.  However, the platform2 must contribute to ensuring the authenticity, integrity and legibility of the invoice.
+ +

+ +

Thus, in the event of a billing mandate between the platform and the taxable entity, in order to allow the latter to fulfil its obligation, the platform must make a readable version available to it. When it has a billing mandate, the public invoicing portal will provide its users with the option to generate readable invoices from a generic stylesheet, responsible for creating a representation of these invoices from structured data. As a reminder, the readable version, and therefore the stylesheet, must contain all the data on the invoice.

+

 

0.1.0.13Readable version of the invoice issued or received for the recipient

+

 

+

The recipient of the invoice must be able to produce a readable version of the electronic invoice when so requested by the tax authority.

+ +

A readable invoice will be provided with the issued invoice as an integral part of the invoice if it is issued in mixed format (Factur-X) or as an attachment if it is in a structured format (UBL or CII).

+ +

This readable version will be either the one received with the invoice (full invoice in the case of mixed or readable format attached to the invoice in the case of a structured format) or the one generated from generic stylesheets by the public invoicing portal under a billing mandate. As a reminder, the readable version, and therefore the stylesheet, must contain all the data on the invoice.

+

 

0.1.0.14Correspondence between certain mandatory information3 to be found on the readable part of the invoice and the structured data on the invoice

+ +

 

+ +

The readable version must be able to reproduce all the data in flow 2, in particular the mandatory information in its literal form provided for in Article 242 nonies A of the French General Tax Code (CGI) in the version in effect from 1 July 2024, together with the information provided for in the French Commercial Code, such as the flat-rate recovery fee or information on penalties.

+ +

The correspondence indicated below is not intended to be used for all mandatory data, some of which are easy to complete in a structured invoice file (such as the customer's SIREN number and address, or the VAT identification number) and then to be transcribed in readable format, but only for data which must be accompanied by a literal statement and which could give rise to queries.

+ +

 

+ +

The correspondence between certain mandatory remarks and the structured data of an invoice is given below:

+ +

 

+

  • Remark concerning discounts: this remark corresponds to the payment terms. This is a handwritten remark that tells a customer that they can apply a discount if they pay before the due date of the payment. This does not correspond to the discount amount. The remark is codified AAB: this codification is located in field BT-21 of a structured file. The remark itself is written as a "Remark concerning discounts" and is in an invoice note in field BT-22. 

 

  • Remark concerning the flat-rate recovery fee: this remark corresponds to the payment terms for the flat-rate recovery fee, which are specific to each company. The remark is coded PMT and is located in the BT-21 field. The remark itself is written "Remark €40" and is in an invoice note in field BT-22. 

 

  • Remark concerning penalties: this refers to the payment terms specific to each company. The remark is codified PMD and is located in field BT-21. The remark itself is written as the "Remark concerning penalties" and is in an invoice note in field BT-22. 

 

  • Remark concerning the member of a single taxable entity: this concerns transactions external to the single taxable entity, i.e. transactions between a member of a single taxable entity and a third party to that single taxable entity. It is codified TXD and is located in field BT-21. The remark itself is written "Member of a single taxable entity" and is in an invoice note in field BT-22. 

 

  • Option to pay tax based on debits: the information must be provided when the provider has opted to pay the fee according to the debits. Code 29 (in CII format) or 35 (in UBL format) must be completed in field BT-8 of a structured file. 

 

  • Reverse charge: the information must be provided when a buyer directly remits the VAT to the tax authority. The AE code must then be specified in the following fields: BT-95 (Document-level discount VAT type code), BT-102 (Expense VAT type code), BT-118 (VAT type code), and BT-151 (Invoice item VAT type code). 

 

  • Self-billing: the information must be provided when a customer issues the invoice in the name and on behalf of the supplier. This information is then conveyed by codes 389 (Self-billed invoice), 501 (Factored self-billed invoice), 500 (Self-billed prepayment invoice), 261 (Self-billed credit note) 502 (Factored self-billed credit note), or 503 (prepayment invoice credit note), which must be completed in field BT-8. In addition, codes for the self-billed Correcting invoice and self-billed Factored Correcting invoice types are being created and will be available in a later version of the external specifications. 

 

  • Transaction category: this is the information according to which the transactions giving rise to an invoice consist exclusively of the supply of goods or exclusively of the supply of services, or consist of both these transaction categories. It is carried by a 2-character code (type B1) in field BT-23 in an invoice structured file. 

 

  • VAT exemption or special VAT arrangements: if the taxable entity is exempt from VAT or applies special VAT arrangements, the information must be included on the invoice. Specifically:  

    • oIf the taxable entity is exempt from VAT, the codes E, K or G must be entered in the following fields: BT-95 (Document-level discount VAT type code), BT-102 (Expense VAT type code), BT-118 (VAT type code), and BT-151 (Invoice item VAT type code). The information must then be indicated on the invoice: reference must be given to the relevant provision of the French General Tax Code (CGI) or the corresponding provision of Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax or to any other remark indicating that the transaction is granted an exemption measure.  

    • o In the case of the special travel agency regime, the remark "Individual travel agency regime" must appear on the invoice if "VATEX-FR-XX (Individual travel agency regime)" (the VATEX code specific to the particular travel agency regime is being created) is entered in the BT-120 field.  

    • oIn the case of special regimes provided for in Article 297a of the French General Tax Code (CGI), the remark "Special regime-Used goods" or "Special regime-Works of art" or "Special regime-Antiques and collector's objects" must appear on the invoice if VATEX-FR-F (second-hand purchase)"/"VATEX-FR -D (second-hand means of transport)" or "VATEX-FR-I (objects of art)" or "VATEX-FR-J (antiques)" (codes are being created by the standard and have not yet been officially validated)  is entered in the field BT-120 . 

    • oIn the case of VAT exemption, the remark "VAT not applicable pursuant to Article 293B of the CGI" must appear on the invoice if the value "VATEX_FR_EXEMPTION" appears in field BT-120. In this case, the invoice VAT amounts (BT-110 and BT-111) must be 0, and the VAT code field (BT-118) must be empty. 

 

 

      1. 3.2.8Document management 

+

Management of documents received by flow (API - see 4.3. E-invoicing APIs) or submitted on the Portal will be subject to a quota at the level of each structure.

+ +

The metrics of this quota may change over time. As a guide, it could be 20 documents with an overall maximum size of 200 MB. This quota applies to linked documents (or documents awaiting linking), i.e. once the quota has been reached or exceeded, it will not be possible to submit invoices by flow or API, or new attachments.

+

 

+

Linked documents (attachments only) will be retained until deleted by their owner or the structure’s administrator or on reaching their expiry date. The lifetime of these documents can be extended by the owner or the structure’s administrator and linked as needed to invoices on the Portal or through an API.

+

 

+

The lifetime of unlinked documents (attachments only) will be limited (only a few days) to avoid using up the allocated quota unnecessarily. This lifetime may be extended by the submitter of the document (or structure administrator) to a maximum of 30 days.

+

      1. 3.2.9B2G flow (compatible with standard 16931) 

 

+

Prior to implementation of the B2B electronic invoicing reform, Chorus PRO accepted several formats for sending invoices to the public sector.

+

 

+

The implementation of the reform imposing flows compatible with European standard 16931 renders the B2G flows used until now obsolete.

+

 

+

Companies wishing to send an invoice to the public sphere will be able to send their invoice according to flow 2 (core format), either through the PPF or through a PDP (invoices for the public sphere will be systematically addressed to the PPF, regardless of the transmit platform chosen).

+

 

 

 

      1. 3.2.10E-reporting flow 

 

+

The e-reporting flow allows transmission of:

+

  • The data concerning transactions in international B2B and B2C (final consumer), whether or not they have been invoiced.  

  • Payment data (receipt of payment) for international B2B and B2C invoices and transactions, as well as domestic B2B invoices supported by e-invoicing flows. Payment data must be submitted only for supplies of service that are subject to an electronic invoice (flow 2 e-invoicing or e-reporting 8 or 9) or not (flow 10 e-reporting), excluding reverse-charge transactions and not optional for the payment of VAT on debits (except prepayments for supply of service). 

 

+ +
+ +
 
+

Figure 15: Representation of the transmission of transaction and payment data

+

 

+

For taxable entities connected to the PPF, several possibilities are offered for transmission of transaction data:

+

  • International B2B:  

    1. 1)If an invoice has been issued in electronic form (in one of the core formats), it can be transmitted in structured format (flow 8 for B2B invoices). 

    2. 2)If an invoice has been issued but it is not in one of the core formats or cannot be transmitted directly in that format, the invoice data must be transmitted in the dedicated e-reporting flow, in the "transaction/invoice declaration" block (flow 10.1). 

 

 

  • B2C: 

 

+

In e-reporting, the expected data are sent over an e-reporting period defined in chapter 2.10.2 Frequencies and deadlines for transmitting e-reporting data.

+

 

+

Similarly, several possibilities are offered for payment data if it can be transmitted (receipts of payment):

+

  • International B2B:  

    1. 1)If an invoice has been issued and transmitted to the reporting party's platform, the payment data may be transmitted in a life-cycle flow (flow 6) with "payment received" status or in an e-reporting flow, in the "payment/invoice reporting" block (flow 10.2); 

    2. 2)If an invoice has been issued but not transmitted to the PPF (i.e. the corresponding data has been transmitted in an e-reporting flow 10.1), the associated payment data will be transmitted in an e-reporting flow, in the “payment/invoice reporting” block (flow 10.2). 

  • B2C: 

    1. 1)the aggregated payment data must be transmitted in an e-reporting flow in the “payment/transaction reporting” block (flow 10.4); 

    2. 2)If all transaction data were not aggregated by the company: if an invoice has been issued on the public invoicing portal in one of the core formats and submitted on the declarant's platform, the payment data can be transmitted in a life-cycle flow (flow 6) with the status of "payment received" or in an e-reporting flow, in the "invoice/payments declaration" block (flow 10.2). 

 

 

+

 Note that the PDPs will be required to submit the reporting data to the PPF in an e-reporting flow (flow 10 grouping the sub-groups provided by the reporting parties or extracted from flow 8, flow 9 or the life cycle) aggregated by SIREN and by transmission period.

+

 

 

      1. 3.2.8 

      2. 3.2.9 

      3. 3.2.10 

0.1.0.15E-reporting of B2B international / B2C transaction data resulting in electronic invoice

+

 

0.1.0.15.1Invoice flows
+

 

+

These flows allow the tax authority to receive invoicing data of the international B2B and B2C transactions that have given rise to electronic invoices in one of the core formats (on the public invoicing portal, excluding services offered by the registered private platform).

+

 

+

International B2B invoices:

+

 

+

For international B2B transactions, the data to be transmitted will be identical to that transmitted for e-invoicing (see 2.4.6.1Mandatory data ), excluding the unique identification number (SIREN) of the foreign taxable client, which will not be present. The SIREN will be replaced by the intra-community VAT number or a foreign number (see Annex 7 - Management rules.xlsx).

+

 

+

Management rules are defined in "Annexe 7 – Règles de gestion.xlsx", including the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • Public invoicing portal management Rules: specific management rules 

  • Standard EN16931 rules: management rules of the standard 

  • EN16931 Code lists: repositories available for each data item (BT) resulting in a repository 

  • Table of reasons for refusal: detailed description of the reasons for refusal of an invoice 

 

 

+

Invoices should be submitted in the same formats (UBL, CII, Factur-X) as those provided for in the case of e-invoicing (see “E-invoicing flow” above).

+

 

+

The semantic format of Flow 8 is defined in "Annexe 4 - Format sémantique FE e-reporting - Flux 8.xlsx" with the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • B2B - Flow 8 – UBL: semantic format for UBL 

  • B2B - Flow 8 – CII: semantic format for CII 

  • Factur-X FR CII D16B – Flow 8: semantic format for factur-X 

 

 

 

 

+

B2C invoices:

+

 

 

+

For B2C transactions, only the data in the following list is mandatory (data transmitted in the e-reporting flow may therefore be restricted to this list):

+

  • the unique identification number (SIREN) of the taxable entity referred to in Article 242 nonies A (1° of I); 

  • the invoice number; 

  • the date of the invoice;  

  • the indication “Option to pay VAT on debits” if the taxable entity has exercised this option; 

  • For each tax rate, the total amount excluding VAT and the corresponding VAT amount; 

  • Total amount of VAT payable, excluding any foreign VAT, expressed in euros for transactions in foreign currency; 

  • Currency. 

 

+

Use of the e-reporting flow aggregating invoice data and transaction data excluding invoices (see 3.2.10.2 B2C Transaction Data E-reporting: transmission of aggregated data data) should be preferred.

+

 

+

If the company does not use data aggregation, invoices should be submitted in the same formats (UBL, CII, Factur-X) as those provided for in the case of e-invoicing (see “E-invoicing flow” above).

+

 

+

The semantic format of Flow 9 is defined in "Annexe 5 - Format sémantique FE e-reporting - Flux 9.xlsx" with the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • B2B - Flow 9 – UBL: semantic format for UBL 

  • B2B - Flow 9 – CII: semantic format for CII 

  • Factur-X FR CII D16B – Flow 9: semantic format for Factur-X 

 

 

0.1.0.15.2Transaction and payment data e-reporting flows (invoices off format / flow 10)
+

 

+ +
+ +
 
+

Figure 16: Representation of the semantic format of the e-reporting flow

+

 

+

This flow allows transmission to the tax authority of transaction data for international B2B and B2C transactions for which invoices have been issued, when the transmission of the invoices themselves is not possible or not appropriate (flow 10.1).

+

 

+

For international B2B transactions, the data to be transmitted will be identical to that transmitted for e-invoicing (see 2.4.6.1Mandatory data ), excluding the unique identification number (SIREN) for the foreign taxable entity, which will not be present. The SIREN will be replaced by the intra-community VAT number or a foreign number (see Annex 7 - Management rules.xlsx).

+ +

+ +

For B2C transactions (which have not been the subject of an electronic invoice in one of the core formats), only the data in the following list is mandatory (data transmitted in the e-reporting flow may therefore be restricted to this list):

+

  • the unique identification number (SIREN) of the taxable entity referred to in Article 242 nonies A (1° of I); 

  • the invoice number; 

  • the date of the invoice;  

  • the indication “Option to pay VAT on debits” if the taxable entity has exercised this option; 

  • For each tax rate, the total amount excluding VAT and the corresponding VAT amount; 

  • Total amount of VAT payable, excluding any foreign VAT, expressed in euros for transactions in foreign currency; 

  • Currency; 

  • Transaction category:  

    • o(i) Delivery of goods subject to value added tax;  

    • o(ii) Supply of services subject to value added tax; 

    • o(iii) Deliveries of goods and supplies of service not subject to value added tax in France, including intra-Community distance sales referred to in Article 258 A (1° of I) and Article 259 B of the General Tax Code; 

    • o(iv) Transactions giving rise to application of the schemes provided for in Article 266 (e of 1) and Articles 268 and 297 A of the General Tax Code (VAT margin scheme). 

 

 

+

The data will be transmitted in the “transaction/invoice reporting” block (in the case of data sent on the basis of an invoice, so one instance per invoice) and accompanied by a “return document” block containing the data necessary to identify the report, the reporting party and the issuer of the flow.

+

 

+

The semantic and syntactic format of the e-reporting flow (flow 10) is defined in "Annexe 6 - Format sémantique FE e-reporting – Flux 10.xlsx", comprising the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • E-REPORTING - Flow 10 

+

 

+

 

0.1.0.16B2C Transaction Data E-reporting: transmission of aggregated data

+

 

+

This flow allows transmission to the tax authority of transaction data for B2C transactions, regardless of whether an invoice was issued or not (flow 10.3).

+

 

+

The data in the following list is therefore mandatory:

+

  • The period to which the transmission refers; 

  • the unique identification number (SIREN) of the taxable entity referred to in Article 242 nonies A (1° of I); 

  • The indication “Option to pay VAT on debits” if the taxable entity has exercised this option; 

  • For each tax rate, the total amount excluding VAT and the corresponding VAT amount; 

  • Total amount of VAT payable, excluding any foreign VAT, expressed in euros for transactions in foreign currency; 

  • Currency; 

  • Transaction category:  

    • o(i) Delivery of goods subject to value added tax;  

    • o(ii) Supply of services subject to value added tax; 

    • o(iii) Deliveries of goods and supplies of service not subject to value added tax in France, including intra-Community distance sales referred to in Article 258 A (1° of I) and Article 259 B of the General Tax Code; 

    • o(iv) Transactions giving rise to application of the schemes provided for in Article 266 (e of 1) and Articles 268 and 297 A of the General Tax Code (VAT margin scheme). 

  •  The number of daily transactions; 

  • The date of the transactions. 

 

+

The data will be transmitted in the “transaction/transaction reporting” block and accompanied by a “Reporting document” block containing the data necessary to identify the report, the reporting party and the issuer of the flow.

+

 

+

The semantic and syntactic format of the e-reporting flow (flow 10) is defined in "Annexe 6 - Format sémantique FE e-reporting – Flux 10.xlsx", comprising the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • E-REPORTING - Flow 10 

 

+

The “Z report” or “closing report” daily recap constituted from the cash register systems totalizes all daily receipts, sales and VAT, and can therefore provide the information necessary to create the corresponding (XML) e-reporting flow.

+

 

0.1.0.17E-reporting of invoiced transaction payment data

+

 

+

The e-reporting of payment data to be transmitted to the tax authority concerns the receipt of payment for domestic B2B invoices (e-invoicing), international B2B and B2C invoices for transactions falling within the category of supplies of service mentioned in Articles 289 bis and 290 of the General Tax Code, for which the company has not opted for payment of VAT on debits and excluding operations giving rise to reverse charge VAT.

+

 

0.1.0.17.1Life-cycle flow
+

 

+

If the invoices have been transmitted to the tax authority (flow 2, 3, 8 or 9), this payment data will be transmitted in a life-cycle flow (Flow 6, see “life-cycle flow” above) with “payment received” status (212) by entering the invoice date and the amount broken down by the VAT rate.

+

 

0.1.0.17.2E-reporting flow 
+

 

+

If the invoices have been issued but could not be transmitted to the tax authority in an electronic format in one of the core formats (i.e. the corresponding data was transmitted in an e-reporting flow 10.1), this payment data will be transmitted in an e-reporting flow (flow 10.2).

+

 

+

The data to be transmitted is:

+

  • The period of the corresponding transmission; 

  • Invoice number; 

  • Date of receipt of payment; 

  • Currency; 

  • Amount received broken down by VAT rate. 

 

+

The data will be transmitted in the “payment/invoice reporting” block and accompanied by a “Reporting document” block containing the data necessary to identify the report, the reporting party and the issuer of the flow.

+

 

+

The semantic and syntactic format of the e-reporting flow (flow 10) is defined in "Annexe 6 - Format sémantique FE e-reporting – Flux 10.xlsx", comprising the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • E-REPORTING - Flow 10 

 

+

In B2C, if the invoicing data could not be transmitted through a flow 10.1 and was transmitted in a flow 10.3, the corresponding payment data will be transmitted in a flow 10.4 (see 3.2.10.4 Globalised Transaction Payment Data E-reporting B2C only).

+

 

0.1.0.18Globalised Transaction Payment Data E-reporting B2C only

+

 

+

This flow allows transmission of payment data to the tax authority for B2C transactions considered to be supplies of services as specified in Articles 289 bis and 290 of the French General Tax Code (CGI), for which the company has not opted to pay VAT on debits and excluding transactions giving rise to reverse charge VAT.

+

 

+

The data to be transmitted is:

+

  • The period of the corresponding transmission; 

  • Date of receipt of payment; 

  • Currency; 

  • Total amount of payments received, broken down by VAT rate. 

 

+

The data will be transmitted in the “payment/transaction reporting” block and accompanied by a “Reporting document” block containing the data necessary to identify the report, the reporting party and the issuer of the flow.

+

 

+

The semantic and syntactic format of the e-reporting flow (flow 10) is defined in "Annexe 6 - Format sémantique FE e-reporting – Flux 10.xlsx", comprising the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • E-REPORTING - Flow 10 

 

+

This flow can also be used to transmit information in case of receipts of payment not yet matched to invoices but giving rise to VAT liability. For the following period, the data transmitted must be cancelled to avoid double accounting with the status of "payment received" for the invoice which will be completed later.

+

 

  1. 4 

    1. 4.1 

    2. 4.2 

      1. 4.2.1 

      2. 4.2.2 

      3. 4.2.3 

      4. 4.2.4 

      5. 4.2.5 

      6. 4.2.6 

      7. 4.2.7 

      8. 4.2.8 

      9. 4.2.9 

      10. 4.2.10 

        1. 4.2.10.1 

        2. 4.2.10.2 

        3. 4.2.10.3 

        4. 4.2.10.4 

0.1.0.18.1Procedures for sending transmissions
+

 

+

The event giving rise to the transmission (e-reporting) of data relating to a transaction which did or did not result in an invoice is the date of performance of the transaction (the date on which the service is provided or the goods delivered).

+

 

+

Payment data is transmitted on the date of receipt of payment for the transaction, regardless of the payment methods chosen, except in the cases provided for under administrative doctrine, in particular in the case of receipt of a bank cheque (due when the cheque is deposited BOI TVA BASE 20 20).

+

 

+

These dates and the VAT regime of the company concerned by the e-reporting will determine the period in which the transmission is made, and the frequencies and time limits for the transmission of the corresponding data (see 2.10.2 Frequencies and deadlines for transmitting e-reporting data).

+

 

+

Transmission (e-reporting) must take place within the deadlines assigned to the transmission periods, as specified in the regulations (see §2.9.2 Frequency of transmissions).

+ +

Transmission intervals are at the discretion of the reporting party, either when falling due or spread over the period, taking into account the following:

+

  • A transmission may be (“transmission type code” field): 

    • oInitial (“IN”): this type is not mandatory and may only be used for the first transmission of the period. 

    • oAdditional (“CO”): for a given period, this type of transmission allows all data to be sent which would not have been the subject of a previous transmission. In the absence of an “initial” transmission, the first additional transmission received will be considered by default as the “initial” transmission for the period. 

    • oCorrection (“MO”): this type of transmission allows you to delete and replace all data from a previous transmission. A corrective message must refer to the transmission it corrects. 

    • oCorrigendum (“RE”): this type of transmission allows all aggregated transmissions for a period to be deleted and replaced. It should therefore refer to this period (and not to each transmission previously sent during the period). 

  • The data in blocks 10.3 (transmission of non-invoiced transactions) and 10.4 (transmission of payments for non-invoiced transactions) is cumulative. 

  • Submissions made before the period (date of transmission < start date of the transmission period) will be rejected. 

 

+

The platforms (PPF or PDP) will be responsible for aggregating the data received over the transmission period for each reporting party (SIREN) for transmission to the tax authority at the end of that period. The data transmission circuit depends on the choice of platform of the issuer (the supplier or the buyer):

+

  • The declarant has chosen the public invoicing portal as the platform for e-reporting data. 

 

+ +
+ +
 
+

Figure 17: Representation of data transmission with the public invoicing portal as an e-reporting data transmit platform

+

 

 

+

1. The public invoicing portal will allow data to be entered, submitted and consulted until the deadline for transmission has expired.

+ +

2. The public invoicing portal will be responsible for aggregating the data transmitted by the sender into the SIREN and PERIOD levels.

+ +

3. The data thus aggregated will be transmitted by the public invoicing portal to the tax authority.

+

 

  • The declarant has chosen a registered private platform as the e-reporting data platform 

 

+ +
+ +
 
+

Figure 18: Representation of data transmission with a registered private platform as the e-reporting data transmission platform

+

 

+

1. The registered private platform will allow data to be entered, flows to be submitted and consulted until the transmission deadline expires.

+ +

2. The registered private platform will be responsible for aggregating the data transmitted by the sender in the SIREN and PERIOD levels.

+ +

3. The data thus aggregated will be transmitted by the registered private platform to the public invoicing portal, which will then transmit it to the tax authority.

+

 

+

Transmissions received by the PPF in the form of e-reporting flows will result in the production of life-cycle flows to monitor the correct processing of these transmissions. The life cycle of e-reporting business objects is described in Chapter 3.2.12.2.2 E-reporting transmission life cycle.

+

 

0.1.0.18.2Correction of transmissions
+

 

+

A transmission will be corrected as follows:

+ + +
+ +
 
+

Figure 19: Representation of the correction of a transmission

+

 

 

+

It will be possible to correct a prior transmission by indicating the corresponding “Transmission type code” (MO):

+

  • For correction of an e-reporting transmission (flow 10), field TT-5 “Previous transmission reference” must contain the identifier (field TT-1 “Transmission ID” of the Document block) of the transmission concerned, with the corresponding code for the transmission type reference (field TT-6 “Previous transmission type”). 0001).  

 

 

  • To correct an invoice transmission (Flow 8 or 9): 

+

-        The correction to be made may be sent via a flow 10.1: field TT-5 “Previous transmission reference” must contain the invoice identifier (field BT-1 “Invoice number”), with the corresponding code for the transmission type reference (field TT-6 “Previous transmission type”). 0002). All data in this invoice will then be cancelled and replaced with the data in the new transmission.

+ +

For the correction of an invoice payment transmission (flow 6), the correction is sent in flow 10.2: the field TT-5 “Previous transmission reference” must contain the life cycle identifier (field MDT-4 “Document identifier”) with the corresponding code as the reference type (field TT-6 “Previous transmission type”:  0003).

+

 

 

+ +
+ +
 
+

Figure 20: Representation of the correction of a transmission made directly in the invoice

+

 

 

 

+

-        The correction to be made can be sent via a correcting invoice (Flows 8 and 9), with field BT-3 “Invoice type code” given a value of 384. A new 10.1 flow will then be generated under this correcting invoice.

+

 

+ +
+ +
 
+

Figure 21: Representation of the transmission of a correcting invoice

+

 

 

+

A corrective transmission may contain more data than the transmission it is intended to correct.

+

 

+

The correcting transmission will be addressed to the same declaration platform. The correcting transmission will cancel the transmission to which it refers (see 3.2.12.2.2 E-reporting transmission life cycle).

+
0.1.0.18.3Rectification of transmissions
+

 

+

The rectification of aggregated transmissions over a period of time will take place as follows:

+ + +
+ +
 
+

Figure 22: Representation of the correction of transmissions

+ +

One or more aggregated transmissions may be corrected by indicating the corresponding “Transmission type code”: RE and the period concerned. To correct a set of aggregated transmissions (invoicing data, non-invoice transactions or payments) for a given period, the correction transmission must include values for fields TT-17 “Period start date” and TT-18 “Period end date”.

+

 

+

The correcting transmission will be addressed to the same declaration platform. All data aggregated for the period mentioned will then be ignored for the benefit of the data contained in the correcting transmission (3.2.12.2.2 E-reporting transmission life cycle).  

+

 

0.1.0.19Summary of the various cases of e-reporting and the associated flows

+

 

+

The following schemes present the different cases covered by e-reporting:

+

 

  • -For suppliers and buyers who have chosen the public invoicing portal for their transmissions: 

+ +
+ +
 
+

Figure 23: e-reporting, circuits A, B1 and B2

+ +

 

+

  • -For suppliers and buyers who have chosen a registered private platform for their transmissions: 

 

+ +
+ +
 
+

Figure 24: e-reporting, circuits B1 and B2

+ +

 

+ + +
+ +
 
+

Figure 25: e-reporting, circuit C

+ +

 

+

 

 

+

+

0.1.1Directory flow

+

 

+

The directory is the unique, centralised, reference database, accessible by the public invoicing portal (PPF) and registered private platforms (PDPs).

+

 

+

Hence, the “directory” flows are four in number, depending on the desired action and the party requesting it:

+

  • Flow 11: request by an issuer to consult the directory to obtain information for addressing invoices to their recipient. 

  • Flow 12: a buyer's request to update its information in the directory. 

  • Flow 13: request by a recipient's registered private platform (PDPR) to update the directory, at the recipient's request. 

  • Flow 14: request by a registered private dematerialisation platform on transmit (PDPE) to consult the directory for the routing of invoices entrusted to it by the invoice issuer. 

 

+

Suppliers, buyers and their PDPs can access the directory via the various exchange modes available on the public invoicing portal: “portal mode”, “EDI” or “Service”.

+

 

+

The semantic format of the invoice recipient directory takes into account B2B needs, as well as B2G for backward compatibility.

+

 

+

List of data in flow 11 (consultation of the directory by a supplier) and flow 12 (buyer request to update the directory):

+

 

+ +
+ +
 
+

List of data in flow 13 (update of the directory by a PDPR) and flow 14 (consultation of the directory by a PDPE):

+

 

+ +
+ +
 
+

Figure 26: Semantic format of the directory

+ +

Details of the semantic format of the directory are available in "Annexe 3 - Format sémantique FE annuaire.xlsx", including the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • N.B.: explains how the file works 

  • FE Directory Flow  

 

+

Updates to the directory may include multiple structures (including updates made by a registered private platform). In addition, each of these structures may be subject to several modifications. Each change made on an address line will be of one of the following types: "add", "modify" or "delete".

+ +

+

 

      1. 3.2.12Life-cycle flow 

 

+

The life-cycle flow allows each of the parties involved (suppliers, buyers, registered private platform, public invoicing portal and tax authority) to track the receipt status of the flows (admissibility / inadmissibility), the status of business objects (invoices, invoice data, transaction and payment data or directory). This flow allows you to track the progress of invoices in the invoicing circuit, from the initial submission of the invoice to receipt of payment (see above §2.8 The nominal life cycle of the invoice).

+

 

 

+

The semantic format of the life-cycle flow makes it possible to receive and transmit all information about the status of a flow or business object, the data that accompanies it, and its origins and destinations. It takes the following form:

+

 

 

+ +
+ +
 
+

Figure 27: Representation of the semantic format of the life-cycle flow

+

 

+

A given life-cycle flow is for one object type only (flow or business object): model codes identify the nature of each object. Life-cycle flows should be allocated according to the Sender, Issuer and Recipient trio.

+

 

 

+

The life-cycle flow is used for:

+

  • Flow acknowledgements: positive or negative (admissibility / inadmissibility); 

  • Transmitting the statuses of different business objects:  

    • oMandatory and optional invoice statuses (transmitted through flow 2) 

    • oStatuses associated with the e-reporting (transmitted by flows 8, 9 and 10); 

    • oThe statuses associated with the mandatory e-invoicing data transmitted to the tax authority (transmitted through flow 1); 

    • oStatuses associated with directory data (transmitted by flows 11, 12 and 13); 

    • oThe statuses associated with life cycle data (transmitted by flow 6). 

 

+

In case of a rejected, refused or suspended status, it is necessary to provide a comment to justify this status. The data (name of the tags) that caused the error, the name of the default management rule and possibly an action code can also be transmitted with the life cycle message with one of these statuses.

+

 

+

The semantic format of Flow 6 is defined in "Annexe 2 – Format sémantique FE CDV – Flux 6.xlsx", including the following tabs:

+

    • Version: identification of changes in the various versions of the Annex 

    • N.B.: explains how the file works 

    • Life cycle FE - CI ARM: semantic format of the life cycle message 

    • Statuses: summary of possible statuses by business object 

 

+

It contains the data mapping to the syntactic format chosen for the life cycle: UN/CEFACT SCRDM CI Cross Domain Application Response message.

+

 

 

+

Management rules are defined in "Annexe 7 – Règles de gestion.xlsx", including the following tabs:

+

  • Version: identification of changes in the various versions of the Annex 

  • Public invoicing portal management Rules: specific management rules 

  • Standard EN16931 rules: management rules of the standard 

  • EN16931 Code lists: repositories available for each data item (BT) resulting in a repository 

  • Table of reasons for refusal: detailed description of the reasons for refusal of an invoice 

 

      1. 3.2.12 

 

0.1.1.1 "Flow" life cycle

+

 

+ +
+ +
 
+

Figure 28: Diagram of the transmission of a life cycle message following the control of a flow by the public invoicing portal

+

 

+

When a flow is sent to the public invoicing portal by an issuer, the flow and its component files are controlled by the public invoicing portal. At the end of the controls (see RG G7.18), a life-cycle message indicating the status of the flow is sent by the public invoicing portal to the issuer:

+

 

+

1 life-cycle message "Admissible flow"

+ +

The flow is declared admissible when the tar.gz file and all files have passed the public invoicing portal controls (see RG G7.18).

+

  • OK file list (MDT-124)  

 

+

2 life-cycle message "Inadmissible flow"

+ +

The inadmissibility of the flow is due to the flow itself (e.g. positive anti-virus control on the tar.gz file) or to a file in the flow (e.g. bad extension on the PJ of a file).

+

  • OK file list (MDT-124) 

  • List of KO files in (MDT-123) 

 

 

0.1.1.2"Business object" life cycle

+

 

+ +
+ +
 
+

Figure 29: Diagram of the send of life cycle messages after processing business objects

+ +

When the flow has been controlled by the public invoicing portal, the business objects it contains are processed according to type (e.g. directory flow functional controls of directory data and followed by modification of the directory database; e-invoicing flow functional controls of invoices followed by their transmission to their recipients, etc.).

+

 

+

Life-cycle messages are sent to inform the various parties (creator, issuer, recipient, third party, platforms, etc.) about the status of the business object according to its processing status. The various business processes for business objects will result in specific life cycles by document type. Each type of document thus has its own mandatory statuses to be transmitted (e.g. 200 - Filed, 210 - Refused, 212 - Payment received, 213 - Rejected, etc.).

+
0.1.1.2.1E-invoicing invoice life cycle
+

 

+

See Chapter 2.8 The nominal life cycle of the invoice 

+

 

0.1.1.2.2E-reporting transmission life cycle
+

 

+

The declarant can issue a flow 6, 8, 9 or 10. For flows 6, 8 and 9, the declaration platform will have the role of processing these objects and generating a flow 10 associated with each one, the only flow transmitted to the public invoicing portal. The declaration platform will attach one of the first statuses ("transmission submitted" or "transmission rejected") to the generated 10 flows.

+

 

+ +
+ +
 
+

Figure 30: "IN", "CO", and "MO" transmission life cycle

+

 

 

+

The various possible statuses of initial, complementary and correcting transmissions are described below:

+

 

+ +
+

Code

+		 +

Status

+		 +

Trigger event

+
+

300

+		 +

Transmission submitted

+		 +

The transmission, invoice or status of an invoice is issued by the declarant to its declaration platform. The "transmission submitted" status will be applied by the declaration platform once it has completed all technical, application and functional controls (and generated the transmission, where applicable).  

+
+

301

+		 +

Transmission rejected

+		 +

The transmission will be rejected by the declaration platform if any of the controls it carries out are not passed. This status is final and will provide the necessary information (reasons) to direct the issuer to make the necessary corrections and issue a new transmission.

+
+

302

+		 +

Transmission issued by the platform

+		 +

At the end of the reporting period, the declaration platform aggregates all the data of the declarant. The declaration platform will transmit the aggregated data to the tax authority. It will then apply the status of "Transmission issued by the platform" to the aggregated transmission and to all transmissions of the declarant over that period.

+
+

303

+		 +

Transmission rejected by the tax authority

+		 +

The aggregated transmission will be rejected by the tax authority when any of the controls it carries out are not passed. The status of "Transmission rejected" is final and will be applied by the declaration platform to all transmissions of the declarant over that period.

+
+

304

+		 +

Transmission accepted by the tax authority

+		 +

The aggregated transmission is accepted by the tax authority when all technical controls, applications and functions have been carried out by the tax authority and have passed. This status is transmitted to the declaration platform.

+
+

305

+		 +

Transmission made available to the tax authority

+		 +

Once the declaration platform has received the "Transmission accepted by the authorities" status for the aggregated transmission, it assigns the "Transmission made available to the tax authority" status to all the declarant's transmissions over this period.

+
+

306

+		 +

Transmission taken into account by the tax authority

+		 +

The aggregated transmission is "taken into account by the tax authority" once it has processed the data. This status will be transmitted to the declaration platform, which will attach it to all the declarant's transmissions over that period.

+
+

307

+		 +

Transmission cancelled

+		 +

This status is the status of a transmission that has been corrected. It is attached by the declaration platform to the corrected transmission once the correcting transmission has been processed.

+
+ +

 

 

+

Once the period has ended, declarants have the possibility to correct their data (see 3.2.10.4.3 Rectification of transmissions). To do this, the declarant must transmit a rectifying transmission. As a reminder, this type of transmission allows the data of all aggregated transmissions to be cancelled and replaced for a period whose status is "taken into account by the tax authority".

+

 

+ +
+ +
+ +
 
+

Figure 31: Life cycle of an "RE" transmission

+

 

+

The possible statuses of a rectifying transmission are described below:

+

 

+ +
+

Code

+		 +

Status

+		 +

Trigger

+
+

300

+		 +

Transmission submitted

+		 +

The rectifiying transmission is issued by the declarant to his declaration platform. The "filed transmission" status is applied by the declaration platform once it has completed all technical, application and functional controls.  

+
+

301

+		 +

Transmission rejected

+		 +

The rectifiying transmission will be rejected by the declaration platform if any of the controls it carries out are not passed. This status is final and will bear the necessary information (reasons) to direct the issuer to make the necessaryrectifications and issue a new rectifiying transmission.

+
+

302

+		 +

Transmission issued by the platform

+		 +

The declaration platform transmits the rectifiying transmission to the tax authority and then assigns it the "Platform-issued transmission" status.

+
+

303

+		 +

Transmission rejected by the tax authority

+		 +

The tax authority will reject the forwarding of rectifiying if any of the controls it carries out are not passed. This status is final.

+
+

304

+		 +

Transmission accepted by the tax authority

+		 +

The transmission of a rectification is accepted by the tax authority when all technical, application and functional controls have been carried out by the tax authority and have been passed. This status is transmitted to the declaration platform.

+
+

306

+		 +

Transmission taken into account by the tax authority

+		 +

The tax authority will take account of the transmission of the rectification when it has processed its data. This status is transmitted to the declaration platform.

+
+ +

 

 

 

0.1.1.2.3Regulatory data life cycle (Flow 1)
+

 

+

The regulatory data life cycle (flow 1) will be described in a later version of the external specifications.

+

 

0.1.1.2.4Directory life cycle
+

 

+

The directory data life cycle will be described in a later version of the external specifications.

+

 

0.1.1.2.5Status life cycle (flow 6)
+

 

+

The status life cycle (flow 6) will be described in a later version of the external specifications.

+

 

0.1.1.3"Subrogation" life cycle

+

 

+

Subrogation is the replacement of one creditor by another. The factor thus becomes the new creditor. Under the public invoicing portal, the life cycle message is used to signify subrogation at any time in the life of an invoice. To do this, a life cycle must be sent with the current status of the invoice to the recipient (see Annex 7 - Management Rules).

+

 

+

Then, the following is required:

+

 

  1. 1.Indicate the change of beneficiary (Payee) via the role code "DL" and fill in the necessary information in the MDG-41 block of the life cycle message.  

 

  1. 2.Transmit the new recipient's IBAN: 

    1. a.Specify the "IBAN" identifier in the MDT-206 tag; 

    2. b.Specify the Xpath of the IBAN data in the MDT-213 tag; 

    3. c.Specify the value of the new IBAN in the MDT-214 tag. 

 

  1. 3.Attach the subrogation invoice via the MDT-96 block as an attachment to the life cycle message.  

 

  1. 4.Specify the action code "SUB" in MDT-121.  

+

+

1Introduction to service mode

+

    1. 4.1.Overview of the APIs 

      1. 4.1.1.Introduction to the service offer 

 

+

The API mode allows users to access all features available to them from the IT tools already deployed within the partner structures. There are two integration methods:

+

 

  • Integration into Information Systems (IS): 

+

APIs are integrated directly into information systems or management software for parties issuing and receiving invoices or their dematerialising operators (ODs). Users can thus directly access the solution’s features and their upgrades from their usual IT tools, internal or offered by their OD.

+ +

APIs can also be integrated into the IS of the PDPs to give them more flexibility (compared with EDI mode), with some APIs dedicated to their use.

+

 

  • Integration into third-party software:  

+

Editors will be able to offer software based on the APIs. Depending on the mode chosen by the editor, connection can then be effected by the editor, or by the customer itself during installation or deployment in its IS. This third-party software will complement the customer’s information system by adding a communication layer to the PPF.

+

 

 

+ +
+ +
 
+

Figure 32: Integration methods

+

 

 

+

The APIs, as part of the services offered by the PPF, will be based on REST-type architecture. Data queries will be sent by the http protocol. Upon receiving the request, the APIs will send messages in JSON or XML format or an http return code (See Chapter 4.2.3. Return code for API queries).

+

 

+

A language input parameter will be set at the API call parameters to receive API return messages (technical or functional) in the desired language. The choice of language will be English (EN) or French (FR).

+

 

+

The APIs offered will be synchronous (i.e. the connection is maintained after each call pending a response) and are described later in the document.

+ +

However, in order to offer new services and limit the increasing number of calls, asynchronous APIs (i.e. the connection is closed after the call and a new connection is made by the server to deliver the response when it is ready) will be offered later, with subscription management (in notification mode) as far as possible.

+

 

+

These asynchronous APIs could be used to give notification of the arrival of new invoices to be processed, for example.

+ +

This type of operation will be described in a future version of the external specifications.

+

 

 

 

      1. 4.1.2.API exchange formats 

 

+

The preferred formats for API exchanges are XML and JSON. The documentation for each API will specify the call format to be provided and the response format provided.

+ +

The content of the query must thus match the format expected by the queried API.

+ +

The API format is described below.

+

 

      1. 4.1.3.API versioning 

 

+

To minimise the impact on the code of the API call, versioning will be achieved using a version number in the URI path.

+ +

In the event of upgrades, at least two versions of each API will be maintained to facilitate customer adaptation.

+

 

      1. 4.1.4.Introduction to VERBS 

 

+

The following verbs (methods) will be used in the services offered by the PPF:

+

 

+ +
+ + + +
+ +
+ +
+

Action

+		 +

Verb (method)

+		 +

Example

+
+

Reading

+		 +

GET

+		 +

/monapi /ressources/id requested object

+
+

Creation

+		 +

POST

+		 +

/monapi /ressources

+
+

Update

+		 +

PUT

+		 +

/monapi /ressources/id requested object

+
+

Deletion

+		 +

DELETE

+		 +

/monapi /ressources/id requested object

+
+ +
 

    1. 4.2.Prerequisites for using API mode 

      1. 4.2.1.PISTE and authentication in Oauth2 mode 

 

+

The AIFE has set up the PISTE platform: Plateforme d’Intermédiation des Services pour la Transformation de l’Etat (Service Intermediation Platform for Transformation of the State).

+

 

+

This platform offers State and public-sphere API services, including Chorus PRO electronic invoicing in particular.

+

 

+

An introduction to the PISTE platform is available at the following address:

+ +

https://communaute.chorus-pro.gouv.fr/documentation/presentation-de-piste/

+

 

+

You can also find more information about the Chorus Pro APIs in OAuth2 mode in the PISTE technical documentation (Swagger) available at:

+ +

https://developer.aife.economie.gouv.fr/

+

 

      1. 4.2.2.Connection in API mode 

 

+

All issuing or receiving parties wishing to choose the API channel must first create a connection to the PPF.

+ +

There are several cases:

+

  • Direct connection 

  • Connection of a hub 

  • Connection of a third-party software editor 

 

+

Direct connection concerns parties wishing to connect directly to the PPF and make their calls from their own solution.

+ +

They will have to create an application under PISTE, a connection to the PPF, as well as a technical account to be able to make calls. These actions will be described in the PISTE user documentation of the solution.

+

 

+ +
+ +
 
+

Figure 33: The creation of a connection

+

 

+

Connection of a hub:

+ +

The hub provides its customers with a web or application solution to enable them to make the various API calls. It is thus the hub that makes API calls on behalf of all its customers. In this case, each partner must have a technical account, but only the hub needs an application under PISTE and a connection to the PPF.

+

 

+ +
+ +
 
+

Figure 34: Connection of a hub:

+

 

+

Connection of a third-party software editor:

+ +

The case of a third-party software editor concerns an editor that installs solutions at its customers’ premises, allowing customers to make their calls from their own servers. In this case, each customer must have its own application under PISTE as well as its own connection. The editor will have to gather the various technical accounts in order to configure its solution at the customer’s premises and thus allow the customer to make the various API calls.

+

 

+ +
+ +
 
+

Figure 35: Connection of a third-party software publisher:

+

 

      1. 4.2.3.Return code for API queries 

 

+

Following an API call by the customer, the server will return data or an HTTP return code.

+ +

In the case of an error return code, the body of the return message will give as much detail as possible about the error encountered.

+

 

+

+

 

+

Technical errors can be of two types:

+

 

  • A client error is associated with error code 40x 

  • A server error is associated with error code 50x 

 

 

+

List of the main HTTPS codes

+

 

+ +
+

Return code

+		 +

Description - Comment

+
+

200

+		 +

OK

+
+

201 

+		 +

OK

+ +

A new resource was created

+
+

204 

+		 +

OK

+ +

Confirmation of resource deletion

+
+

400 

+		 +

Bad query

+ +

The query was invalid or cannot be completed

+
+

401

+		 +

Not allowed.

+ +

The query requires user authentication

+
+

403

+		 +

Not allowed.

+ +

The server understood the query but refuses it or access is not allowed

+
+

404

+		 +

Not found

+ +

There is no resource at the given URI

+
+

406

+		 +

Query format not accepted

+
+

429

+		 +

The client has issued too many calls within a given time

+
+

500

+		 +

Internal server error

+
+

503

+		 +

Service unavailable

+
+ +

 

 

      1. 4.2.4.Description of the APIs 

 

+

The description of the APIs in this chapter is by functional area.

+ +

API services in the PPF cover three functional areas:

+

  • E-invoicing 

  • E-reporting 

  • Directory 

+

Each area is made up of resources. Each resource is made up of identifying attributes or data that characterises it.

+ +

A resource can be a main resource or an additional resource. An additional resource will be dependent on the main resource.

+

 

+

E.g. the e-invoicing domain includes fixed resources such as Invoice, Buyer and the additional resource Note.

+ +

A resource itself is made up of static data (fixed) and dynamic data (variable) resources.

+

 

+

A dynamic data resource must follow the life cycle of the resource to which it is attached and must therefore be updated. It therefore has its own I/O table.

+ +

E.g. The invoice resource has fixed attributes/data such as its number or its issuer. This data is frozen regardless of the status of the invoice. This invoice resource is also made up of attributes/data in the additional resource Note, which can vary throughout the invoice life cycle.

+ +

+

    1. 4.3.E-invoicing APIs 

 

+

Services in the "E-INVOICING" domain provide access to the functionality of the invoice space (e-invoicing), covering flows 1 and 2 (see chapter 3.2.2 E-invoicing flow) and life-cycle flows (see chapter 3.2.12).

+

 

+

This E-invoicing area is made up of four resources corresponding to the different possibilities for creating invoices (flow 2) and invoicing data (flow 1) by the API.

+

  • Invoice 

  • Flow 

  • Document 

  • Invoicing data  

 

+

The first three resources (Invoice, Flow, Document) are component resources of flow 2.

+

 

+

The invoicing APIs allow:

+

  • creation of an invoice or invoicing data through the regulatory data; 

  • creation of an invoice or invoicing data through a flow; 

  • modification of an invoice (status, attachment); 

  • consultation, search, download of an invoice, invoicing data, or document; 

  • submission of a document (a document specific to a party, an invoice attachment, an invoice flow, or invoicing data) (1); 

  • creation of a flow from a document. 

+

Details of the e-invoicing resource APIs are available in the e-invoicing technical documentation (Swagger).

+

 

 

    1. 4.4.E-reporting APIs 

 

+

The services in the "E-reporting domain" provide access to the functionality of the reporting space covering flows 8, 9 and 10 (see chapter 3.2.10 E-reporting flow) and life-cycle flows (see chapter 3.2.12).

+ +

This E-reporting area is made up of four resources corresponding to the different possibilities for reporting by API.

+

  • Invoice 

  • Flow 

  • Document 

  • Reporting data  

+

The E-reporting APIs allow:

+

  • creation of a report through the essential data; 

  • creation of a report through a flow; 

  • consultation, search, download of a report or document; 

  • submission of a document; 

  • creation of a flow from a document 

+

Details of the e-reporting resource APIs are available in the e-reporting technical documentation (Swagger).

+

 

    1. 4.5.Directory APIs 

+

The Directory area is made up of three resources:

+

 

  • Recipient 

  • Platform 

  • Additional data. 

+

The scope of the directory APIs will be as follows:

+

 

  • Creation of a directory line 

  • Editing a directory line 

  • Deleting a directory line 

  • Searching a directory line 

+

Details of the directory resource APIs are available in the directory technical documentation (Swagger).

+

    1. 4.6.Exchange System domain APIs 

 

+

Details of the Exchange System resource APIs are available in the Exchange System Technical Documentation (Swagger).

+

 

    1. 4.7.API usage cases 

 

      1. 4.7.1.Making an invoice available with an attachment 

 

+

Making an invoice available with an attachment will require 2 successive API calls.

+ +

1st call: Using the document API. This API will return the ID of the submitted document.

+ +

2nd call: Using the invoice API with completion of invoice data and using the document ID that was previously sent by the document API.

+ +

This API will return the invoice data with its latest status.

+

 

+ +
+ +
+ +
 

      1. 4.7.2.Quota management for submission of an attachment 

+ +
+ +
 
+
+ +

Users wishing to attach a document to an invoice will first need to go through the Document API. This submission will ascribe the quota of the structure until this document is processed as an invoice attachment.

+ +

To do this, the user will have to use the invoice API to run his processing. Once processed, the structural quota returns to the initial value.

+

 

  1. 5.Directory 

    1. 5.1.Definition of the directory and its guiding principles 

 

+

The “Y” scheme for invoicing chosen as part of the reform requires the establishment of a directory enabling the various registered private platforms to address invoices to recipients and secure B2B exchanges.

+ +

Hence, the directory is:

+

  • A key public invoicing portal resource made available to companies to address invoices, statuses and invoicing data to the right recipient, whether in portal, EDI or service mode. 

  • A service provided by the public invoicing portal (PPF) to registered private platforms (PDPs) to ensure the routing of invoices. It is a reliable database that can populate PDP directories to ensure the reliability of exchanges. 

+

The centralised directory is based on several guiding principles to secure the dematerialised exchanges provided for under mandatory electronic invoicing:

+

  • Centralisation: it brings together all stakeholders in the reform (taxable entities) in a single repository 

  • Interoperability: it is accessible to authorised users via all partner platforms (PPF, PDP)  

  • Accuracy: it provides a sufficient level of up-to-date information to allow invoices, statuses and invoicing data to be properly addressed 

  • Security: it ensures the security and traceability of updates to the data in the directory, in particular through credential management 

  • Unique identifier: each line in the directory has a unique addressing line code that allows issuing companies to know the addressing level at which invoices are received by their customers and to identify the information to be included in the invoice. 

 

+

The directory is an asset shared by all parties and essential to smooth and secure e-invoicing exchanges. It thus contains all the taxable entities subject to the B2B reform and incorporates the features of the Chorus Pro directory necessary for B2G exchanges.

+

 

+

The directory is accessible via all channels, allowing the integration of the service into companies’ management tools and those of their intermediaries (PDPs, ODs).

+

 

+

The directory access modes are:

+

  • Portal: real-time consultation of directory data 

  • Service: real-time consultation of directory data 

  • EDI: deferred reception of a directory flow every 24 hours 

 

+

For the EDI access mode, it will be possible to obtain the full directory at the time of initialisation and on request. There is no provision in the PPF for a subscription service allowing periodic reception of the full directory.       

+

 

    1. 5.2.Directory structure and addressing invoices 

 

+

The directory is modelled to contain all the strictly necessary data:

+

  • For correct identification of the business partner by the supplier and the correct addressing of invoices 

  • For correct reception of dematerialised invoices and life-cycle statuses 

+

The directory only addresses partner platforms (PDP and PPF). Dematerialising operators (non-PDP ODs) are outside the scope of the directory.

+

 

+

ODs must be connected to a partner platform (PPF or PDP) to allow invoice routing and extraction of data for the tax authority.

+

      1. 5.2.1.Typical directory structure 

+

 

+ +

The directory is structured around three categories of data:

+

 

+ +
+ +
 
+

Figure 38: Directory data category

+

 

+

The central directory allows each company to choose the addressing level for invoice reception.

+ +

Three reception addressing levels are available:

+

  • Legal entity level: SIREN 

  • Establishment level: SIRET 

  • Routing code level: internal code of the type “department code”, “GLN code”, etc. 

 

+

Hence, in terms of data:

+

  • The “Company identification” block is necessarily more detailed for companies that have chosen the most specific addressing level (e.g. routing to an internal department, etc.). 

  • The “Platform identification” block contains the same number of data items regardless of the addressing level chosen by the company. 

  • The “Additional management data” block contains the additional data used in the current directory and required by B2G. This block does not concern B2B. 

 

+

Initially, the directory will be initialised with the INSEE data of private entities subject to VAT. Only the two generic SIREN-only and SIREN/SIRET primary addressing lines will be available.

+ +

Subsequently, once the public invoicing portal is in production, it will be up to the recipients of the invoices to upgrade these lines (see 5.2.3. Directory structure for addressing at SIRET level grid) In the case of public entities, the Chorus Pro directory will be replicated in the public invoicing portal directory.

+

 

      1. 5.2.2.Directory structure for addressing at SIREN level 

 

+

Companies wishing to receive invoices at SIREN level must declare the SIREN number in the directory; the SIRET number and internal routing code (department code, GLN, ODETTE codes) are not required.

+

 

+

Directory of a company managing invoicing at SIREN level and having declared the PPF as receive platform:

+ + +
+ +
 
+

Company managing invoicing at SIREN level and having declared a PDP as receive platform:

+ + +
+ +
 

      1. 5.2.3.Directory structure for addressing at SIRET level 

+

Companies wishing to receive invoices at SIRET level must declare the SIREN number and the SIRET number(s) in the directory; the routing code (department code, GLN, ODETTE codes) is not required.

+

 

+

Company managing invoicing at main establishment SIRET level with the SIREN as the generic line:

+ + +
+ +
 
+

Company managing invoicing at multi-establishment SIRET level with the main SIRET as the generic line:

+ + +
+ +
 
+

Companies choosing the “MAIN SIRET” addressing level may also declare a platform at the SIREN level (generic line) to allow reception of invoices without a SIRET or with a SIRET other than that of the main establishment.

+

 

+

Companies choosing to declare multiple “INVOICEABLE SIRETs” will also be able to declare a platform at the SIREN or MAIN SIRET level (generic line) to allow the reception of invoices without a SIRET or with a SIRET other than those declared in the directory.

+ +

Billable SIRETs are those enabled by the enterprises or their PDP in the directory to receive invoices on the declared platform.

+

 

+

The directory will be initialised with this generic line, which companies can disable if they wish. Companies can disable generic lines if they have created other active lines in the directory to receive an invoice. A taxable company will have at least one active line in the directory (no maximum limit). One of the two lines SIREN alone or the SIREN/SIRET Primary must remain active.

+

 

+

The PPF acts as the default receive platform if the receive platform of the “SIREN” or “MAIN SIRET” generic line has not been declared and the company has not disabled it.

+

 

      1. 5.2.4.Directory structure for addressing by routing code 

+

Companies wishing to receive invoices at ROUTING CODE level must declare the SIREN number, the SIRET number(s) and the routing code(s) associated with each SIRET.

+ +

+ +

Company managing invoicing at routing code level with the SIREN as the generic line:

+ + +
+ +
 
+
Company managing invoicing at routing code level with the Main SIRET as the generic line:
+ + +
+ +
 
+
+ +

Companies choosing the “ROUTING CODE” addressing level will also be able to declare a platform at “SIREN” or “MAIN SIRET” level (generic line) to allow the reception of invoices without a SIRET and/or routing code and those with a SIRET and/or routing code other than those declared in the directory.

+

 

+

The directory will be initialised with this generic line. Enterprises can disable it if they wish. Invoices that do not match an addressing line in the directory will therefore be rejected.

+

 

+

The PPF acts as the default receive platform if the receive platform of the “SIREN” or “MAIN SIRET” generic line has not been declared and the company has not disabled it.

+

 

    1. 5.3.Directory data and addressing invoices 

+

The data in the directory identifying the recipient company, the receive platform and the additional management data for B2G is described in "Annexe 3 - Format sémantique FE annuaire.xlsx".

+

 

+

This list of optional management data is required for addressing B2G invoices. It is included in the B2B directory to provide issuers with addressing data for private entities and public entities in the same directory.

+

 

+

The PPF does not include B2B management data in the central directory. PDPs may offer their customers management and availability of the additional management rules.

+

    1. 5.4.Roles and responsibilities of ecosystem stakeholders 

+

The future directory will be managed by the public invoicing portal and updated by:

+

 

  • The public invoicing portal (PPF): creation of structures, configuration and updating of structures by invoice recipient administrators 

  • Registered private platform (PDP): addition of data to the recipient directory and updating it for their customer companies 

 

+

The future directory is managed by the public invoicing portal and can be consulted by various parties:

+

 

  • PDPs can view the information needed for routing invoices (entity and receive platform identifiers). 

  • Through their platform, companies can view the information needed to identify the addressing level so that invoices are correctly populated. They cannot view information relating to the PDPs chosen by the invoice recipient. 

  • Through their customers’ platforms, dematerialising operators can connect via exchange flows to access the information needed to identify the addressing level so that invoices are correctly populated. They cannot view information relating to the PDPs chosen by the invoice recipient. 

 

      1. 5.4.1.Initial population of the directory 

 

+

The entry into force of the electronic invoicing reform on 1 July 2024 makes it mandatory for large companies to issue invoices and mandatory for all companies to receive them, regardless of their size. The directory must therefore be populated and complete as from the opening of the PPF service for both taxable companies and public entities.

+

 

+

Population of the directory takes place in two steps:

+

  • The directory is initialised at the start of the test-run phase, by the AIFE, based on information available to the tax authority on the legal existence of enterprises and their liability to VAT. Only 2 generic lines will be active (SIREN line and the primary SIRET line), the secondary SIRETs will be integrated into the directory but not active. 

  • The initialised directory is then modified and expanded throughout the test-run phase:  

+

o        By the AIFE from the INSEE databases listing legal entities and active establishments;

+ +

o        By the AIFE using DGFiP repositories to limit the scope of the directory to the populations affected by the electronic invoicing reform (entities subject to VAT);

+ +

o        By the AIFE using information from the current B2G directory;

+ +

o        By PDPs to verify directory data concerning their users, and:

+

  • As a new PDP, to change the choice of platform for its user (block 2, see directory annex)  

  • To complete the addressing level by adding lines, allowing the invoice to be sent to a secondary institution, or by adding routing codes related or not to institutions. 

  • To change addressing data by disabling lines that are no longer relevant to the enterprises, and replacing them with new lines. 

+

o        By the main administrators of private structures that will use the PPF as receive platform, to verify the directory data and specify the chosen addressing level;

+ +

o        By the main administrators of public entities to verify and supplement the information concerning the entities they represent;

+ +

o        By the AIFE support team for public structures based on information provided by the public entities concerned;

+

 

  • The generic addressing line (SIREN or Main SIRET) allows for reception of invoices for which no addressing is found in the directory (SIRET or SIRET/routing code level) and thus avoids their rejection. This generic line is also to be completed by PDPs and companies to specify the receive platform and keep it active in the directory. If they fail to do so, invoices with addressing information that does not match the directory data will be rejected. 

      1. 5.4.2.Keeping the directory up to date over time 

 

+

Keeping the directory up-to-date over time is a necessary condition to smooth exchanges and avoid invoice refusals due to "routing error".

+

 

+

Updating relies on the same parties as initialisation, namely:

+

  • The AIFE for updating directory lines based on information about creation, change and cessation of activity (INSEE database and DGFiP repositories). 

  • The AIFE for the application of decisions to withdraw the registration of PDPs. 

  • registered private platforms for updating the directory lines of their client companies, especially new clients. 

  • The PPF, after the enterprises’ managers update the data of the structure they represent. 

  • The PPF, after the public entities’ managers update the data of the structure they represent. 

 

 

+

Failure by platforms to update the directory may result in the withdrawal of their registration number.

+

 

 

    1. 5.5.How the new directory works 

      1. 5.5.1.The directory and invoicing circuits 

 

+

The table below summarises the role of the different parties in relation to the directory according to the invoicing circuit chosen by companies

+

 

+ +
+ +
 
+

Figure 39: Role of parties in relation to the directory

+ +

Remark: when the company has chosen to use a PDP (circuits B2 or C), the company must use the directory to send invoices to the recipient’s platform. Addressing an invoice to a platform other than that chosen by the recipient (registered private platform or public invoicing portal) will automatically result in refusal of the invoice (see 2.11 Controls performed and 2.12 2.12        Grounds for rejection and inadmissibility).  

+

 

      1. 5.5.2.The directory and invoicing flows 

 

+

In order to send an invoice to the right recipient, it will be necessary to include the address data in the invoice, i.e. the recipient information and any additional data relating to public structures. 

+ +

This data will make it possible to reconstruct a routing key or "addressing line code" specific to the recipient of the invoice. The addressing line code is the identifier of each addressing line in the directory. It must correspond to a unique key for each line in the directory.

+ +

 

+ +

This identifier must allow the parties that need to view and/or update the directory to precisely identify the relevant lines, especially for automatic updates by PDPs.

+ +

 

+ +

This data item can be formed according to these two rules:

+

  • An identifier chosen by the company and in the following format:  

    • oSIREN_<Company address value>  (email, internal code, GLN code, etc.) (BT-47 and BT-49) 

 

  • An identifier made up of the data specifying the addressing level in the following format:  

    • oSIREN_SIRET_ROUTING CODE (BT-47, BT-46b and BT-46c) 

    • oSIREN_SIRET (BT-47 and BT-46b) 

    • oSIREN (BT-47) 

 

+

If the "INVOICE A" block is filled in, the data in this block will be queried first for the addressing of invoices. 

+

 

+ +
+ +
 
+

Figure 40: Invoice and directory data blocks

+

 

+

The “routing code” data in the “Entity identification” data block reflects the most specific addressing level within a customer organisation. This routing code corresponds to an internal address (GLN, ACHATPROD, ACHATGENERAUX, public entity department code, etc.) and must be specified in the invoice for it to be routed to the right recipient:

+

  • For B2B exchanges, suppliers will use BT-46 to indicate the routing code of their private customers. 

  • For B2G exchanges, suppliers will continue to use BT-10 as they do today to indicate the routing code of their public customers. 

 

+

The information making up the “Addressing code” directory data will be coded according to standard ISO 6523, with some examples shown below:

+

  • Code 0002 for the SIREN number; 

  • Code 0009 for the SIRET number; 

  • Code 0224 for internal routing code. 

 

      1. 5.5.3.The directory and the self-billing use case 

 

+

Self-billing is an invoicing procedure whereby the customer, an entity subject to VAT, is permitted to issue an invoice in the name and on behalf of the supplier.

+

 

+

In this case, the supplier is the recipient of the invoice. The supplier must therefore be declared in the directory to receive the invoice issued by the buyer.

+

 

+

The invoicing data, used as the addressing line code, in invoices and the directory structure allows the self-billing invoice to be routed in the same way as conventional invoicing between a supplier and a buyer.

+

      1. 5.5.4.The directory and the third-party invoicing use case 

 

+

Third-party invoicing consists in setting up a billing mandate in which the principal (supplier) grants the power to a third party (representative) to issue its invoices to its customers.

+

 

+

The representative issues the invoice in place of the supplier and addresses the invoice to the buyer (see use case 15).

+

 

+

Use of the directory by a representative to find the information needed for routing the invoice to the buyer is the same as for conventional invoicing between a supplier and a buyer without an intermediary.

+

 

    1. 5.6.Methods for declaring and changing platform 

 

+ +
+

Ref.

+		 +

Use cases

+		 +

Change process

+
+

Case 1

+		 +

The company does not have an account on the public invoicing portal and wishes to declare a registered private platform

+

  • •The company selects and signs a contract with a new registered private platform to receive invoices 

  • •The new registered private platform updates the directory by adding the new addressing lines and specifying the effective start date from which the company will be able to receive invoices via the new registered private platform 

  • •The business using a registered private platform has no obligation to have a user account on the public invoicing portal 

+

Case 2

+		 +

The company wants to declare a new registered private platform, in addition to the current platforms, on new lines in the directory

+

  • •The company selects and signs a contract with a new registered private platform to receive invoices 

  • •The new registered private platform updates the directory by adding the new addressing lines and specifying the effective start date from which the company will be able to receive invoices via the new registered private platform 

  • •Each platform is responsible for updating the directory addressing lines relating to the contracts signed with its customers 

+

Case 3

+		 +

The company wants to replace the public invoicing portal with a new registered private platform

+

  • •The company selects and signs a contract with a new registered private platform to receive invoices 

  • •The new registered private platform updates the directory by adding the new addressing lines and specifying the effective start date from which the company will be able to receive invoices via the new registered private platform 

  • •The company may continue to use the public invoicing portal for the life cycle of invoices already received and will receive new invoices via the registered private platform. User accounts already created on the public invoicing portal can remain active (accounts created on the public invoicing portal will only be disabled upon user request). 

+

Case 4

+		 +

The company wishes to replace the current registered private platform with another registered private platform

+

  • •The company selects and signs a contract with a new registered private platform to receive invoices 

  • •The new registered private platform updates the directory with the effective date from which the company can receive invoices 

  • •The "addressing line code" must not change when replacing one platform with another on the same addressing lines 

+ + +

Figure 41: Methods for changing the platforms declared in the directory

+

 

 

 

 

 

 

    1. 5.7.Special cases and directory management rules 

      1. 5.7.1.Addressing line status 

 

+

An addressing line can have two statuses, as described in the following table:

+ +

+

 

 

+ +
+

Ref.

+		 +

Addressing line status

+		 +

Management rules concerning invoice transmission

+
+

Case 1

+		 +

Active

+		 +

Invoices can be sent to the recipient via the addressing line

+
+

Case 2

+		 +

Inactive

+		 +

The invoice is sent to the recipient via an addressing line of a higher level (see 5.2.4. Directory structure for addressing by routing code)

+
+ +

 

+

Figure 42: Management of directory addressing line statuses

+

 

      1. 5.7.2.Companies with non-visible SIRET numbers  

 

+

Some taxable companies may object to their data being made available to the public. They are then declared in the directory of INSEE companies as SIREN or SIRET "partially distributable".

+

 

+

In accordance with the General Data Protection Regulation, data relating to legal units and institutions which have exercised their right of opposition will be made available in such a way as to conceal:

+

  • for natural persons, identification elements (name, first name, pseudonym, etc.);  

  • for natural persons and legal entities, the location elements (any address and location elements, except the municipality). 

 

+

According to Article A123-96 of the Commercial Code: “Any natural person may request directly at the time of the creation or modification formalities or by sending a letter to the Director General of INSEE (National Institute of Statistics and Economic Studies) that the information in the register concerning him/her not be made available for use by third parties other than the bodies authorised under Article R. 123-224 or the public authorities, for prospecting purposes, commercial in particular.”

+

 

+

In the future central directory of B2B and B2G recipients, the address data of the legal units and partially distributable establishments will not be displayed apart from the country code, which is a mandatory part of the invoice.

+ +

 

+ +

Thus, taxable entities whose SIREN and/or SIRET are partially distributable will be present in the recipient's directory and will be able to receive the invoices in the same way as the other recipient entities.

+ +

+

      1. 5.7.3.Newly created companies 

 

+

New companies can issue and receive invoices as soon as they are created.

+

 

+

The current incorporation process requires verification of the supporting documents provided by the company’s creator before INSEE grants a SIREN number for the legal entity and a SIRET number for its establishment, thus making incorporation effective.

+

 

+

Once these identification numbers have been assigned, the company can register with a platform (registered private platform or public invoicing portal) to issue electronic invoices, according to the established schedule (see 2.3.4 Gradual application of the requirement).

+

 

+

However, a newly created company will not appear in the directory of recipients of invoices until it has been verified by the authorities as being liable for VAT in France. Therefore, the enterprises concerned are not subject to the obligation to accept electronic invoices until this verification has taken place.

+

 

 

  1. 6.Connection protocols  

    1. 6.1.Exchange protocols for connection of EDI partners 

+

To enable the exchange of data flows, the public invoicing portal provides EDI partners (private or public issuers and recipients, dematerialising operators, registered private platforms) with four exchange protocols:

+

  • PeSIT HS E,  

  • SFTP,  

  • AS/2,  

  • AS/4. 

+

A partner can only use one of these protocols at any given time. 

+ +

These protocols allow direct connection of an EDI partner’s information system to the public invoicing portal in EDI mode. EDI connections with the public invoicing portal are intended to allow the exchange of large flows of invoices for batch processing. An EDI connection may be used to transmit flows from different partners if they have provided billing delegation to the connected issuer.

+

 

+

Therefore, the maximum size of a flow is 1GB, and each business object in the flow must not exceed a maximum size of 120MB.

+

 

+

The information systems of local public sector entities and national public institutions do not connect directly to the public invoicing portal in EDI mode; they connect with their remote transmission third party connected to the DGFiP exchange system (SE). These third parties may offer other connection protocols than those presented below.

+

    1. 6.2.PeSIT HS E  

 

+

From 1st January 2024, new connections (new partners or renewals) of private external partners will not be authorised in PeSIT (File transfer protocol for the banking industry).

+ +

For public partners, PeSIT connections could be extended beyond July 1 2024 as well as for CPro OS connection management. Thus, it will be possible to manage the connections of the CPro OS in the connection hub as well as the PeSIT protocols.

+

 

 

    1. 6.3.SFTP 

      1. 6.3.1.General principles 

  • Definition 

+

The Secure File Transfer Protocol (or SSH File Transfer Protocol) is a client/server-based file transfer protocol that encrypts the entire connection, including passwords and content. It is a variant of the FTP protocol that secures the session through a Secure Shell Protocol (SSH) connection.

+

 

  • Prerequisites for connection to the public invoicing portal exchange system 

+

To request connection to the public invoicing portal exchange system through the SFTP protocol, users must:

+

  • oHave an SFTP client, 

  • oHave a sequential number assignment utility, 

  • oDefine an emission and reception procedure. 

  • Security prerequisites  

+

Protocol security must be provided by:

+

  • oThe public key of the AIFE server made available to partners that wish to exchange via this protocol (via URLs, on TLS exchange principles);  

  • oThe following encryption algorithms must be supported by the partners: AES128_CBC and AES256_CBC  

  • oDouble RSA key encryption used for client authentication.  

 

      1. 6.3.2.Exchange terms and conditions 

+

The SFTP protocol allows file transfer in both directions between a server and a client. The public invoicing portal is always the server, and partners remain clients, regardless of the direction of transfer.

+

  • Authentication  

+

Authentication uses a double RSA key encryption. The partner’s public key must be communicated to the AIFE during the connection phase in accordance with the current procedures for TLS flows.

+ +

The partner’s public key can be provided as an X509v3 certificate.

+

  • Naming rules  

+

Four key parameters characterise a file, regardless of the partner and the type of flow:

+

  • oAn interface identifier (depending on the flow format),  

  • oThe interface code,  

  • oThe code of the application issuing or receiving the flow,  

  • oA sequential number incremented by the issuer of the flow. 

  • How a transfer is carried out with the SFTP protocol  

+

When using the SFTP protocol to submit files to the public invoicing portal, partners must first upload them to the AIFE SFTP server. Similarly, they must use the AIFE server to pick up files made available by the public invoicing portal. In this context, files must be picked up within one week (7 days). After this time, files are automatically purged and thus no longer available.

+ +

Each partner has its own Input directory for file submission and retrieval.

+ +

Partners using this protocol may use automated scripts or utilities to submit and retrieve files. A file made available can only be retrieved once.

+

 

+

Any manipulation of the file made available (other than retrieval) or the retrieval directory (other than listing) is prohibited.

+

 

 

  • SFTP transfer workflow 

+

Outbound circuit of an SFTP protocol transfer:

+

 

+ +
+ +
 
+

Figure 43: Diagram of the outbound circuit of an SFTP protocol transfer

+ +

Return circuit of an SFTP protocol transfer:

+ + +
+ +
+ +

    1. 6.4.AS/2 

      1. 6.4.1.General principles 

  • Definition  

+

The AS/2 (Applicability Statement 2) protocol is a file transfer protocol that works in “push” mode, allowing a partner to send a file directly to the recipient on its own initiative. AS/2 specifies the mode for connection, delivery, validation and acknowledgement of the data. This protocol is distinctive in that it incorporates an acknowledgement system called the Message Disposition Notification (MDN).

+

  • Prerequisites for connection to the public invoicing portal exchange system 

+

To request connection to the public invoicing portal exchange system through the AS/2 protocol, users must:

+

  • oHave an AS/2 server to receive messages,  

  • oHave an AS/2 client to issue messages, 

  • oHave servers capable of managing synchronous and signed MDNs,  

  • oHave a sequential number assignment utility,  

  • oDefine an emission and reception procedure. 

  • Security prerequisites  

+

The protocol is secured. The transport layer does not therefore require TLS. However, partners must have certificates to perform:

+

  • oSignature (SHA-2),  

  • oEncryption (AES 256),  

  • oPublic key authentication.  

 

+

+

      1. 6.4.2.Exchange procedures 

  • Authentication  

+

Partner authentication uses the electronic signature mechanism provided under the AS/2 protocol. Partners must first provide their certificate to the AIFE.

+

  • Transfer and naming rules  

+

Files created must follow these rules:

+

  • oFiles are sent as attachments in S/MIME form;  

  • oThe file name for the protocol parameters is the name of the attachment.  

+

Four key parameters characterise a file, regardless of the partner and the type of flow:

+

  • oAn interface identifier (depending on the flow format),  

  • oThe interface code, 

  • oThe code of the application issuing or receiving the flow,  

  • oA sequential number incremented by the issuer of the flow. 

 

  • How a transfer is carried out with the AS/2 protocol  

+

The file to be transmitted is encapsulated in the AS/2 query as an attachment, which is named using the nomenclature defined for the PeSIT HS E protocol. This data envelope is then sent over the Internet using standard protocols. The data is transmitted using the http protocol, in a POST request, to a static IP address.

+

 

+

The AS/2 protocol allows for the implementation of security levels: messages are signed using an SHA-2 algorithm and exchanges encrypted using an AES 256 algorithm.

+ +

Acknowledgements (MDNs) are generated in synchronous mode and signed to indicate success (OK) or failure (NOK) of the transfer to the client.

+

 

+

In event of an NOK, the transfer must be repeated. As AS/2 is based on the HTTP protocol, it does not include an automatic failover mechanism. Hence, if transfer acknowledgement is not received, files should not be re-sent: Instead, users should contact their Public invoicing portal technical support contact for verification of the status of their transfers.

+

 

  • AS/2 transfer workflow 

+

Outbound circuit of an AS/2 protocol transfer:

+ + +
+ +
 
+

Figure 45: Diagram of the outbound circuit of an AS/2 protocol transfer

+ +

Return circuit of an AS/2 protocol transfer:

+ + +
+ +
 
+

Figure 46: Diagram of the return circuit of an AS/2 protocol transfer

+ +

+

    1. 6.5.AS/4 

      1. 6.5.1.General principles 

  • Definition  

+

The AS/4 (Applicability Statement 4) protocol is a file transfer protocol that operates in “push” or “pull” mode, allowing partners to exchange files in both directions. AS/4 specifies the mode for connection, delivery, validation and acknowledgement of the data. This protocol is distinctive in that it incorporates an acknowledgement system called the Message Disposition Notification (MDN).

+

  • Prerequisites for connection to the public invoicing portal exchange system 

+

To request connection to the public invoicing portal exchange system through the AS/4 protocol, users must:

+

  • oHave an AS/4 server to receive messages,  

  • oHave an AS/4 client to issue messages, 

  • oHave servers that can handle signed acknowledgement signal (SOAP) messages,  

  • oHave a sequential number assignment utility,  

  • oDefine an emission and reception procedure. 

  • Security prerequisites  

+

The protocol is secured. The transport layer does not therefore require TLS. However, partners must have certificates to perform:

+

  • oSignature (SHA-2),  

  • oEncryption (AES 256),  

  • oPublic key authentication.  

 

      1. 6.5.2.Exchange terms and conditions 

  • Authentication  

+

Partner authentication uses the electronic signature mechanism provided under the AS/4 protocol. Partners must first provide their certificate to the AIFE.

+

 

  • Transfer and naming rules  

+

Files created must follow these rules:

+

  • oFiles are sent as SOAP attachments;  

  • oThe file name for the protocol parameters is the name of the attachment.  

 

+

Four key parameters characterise a file, regardless of the partner and the type of flow:

+

  • oAn interface identifier (depending on the flow format)  

  • oThe interface code  

  • oThe code of the application issuing or receiving the flow  

  • oA sequential number incremented by the issuer of the flow  

  • How a transfer is carried out with the AS/4 protocol  

+

The file to be transmitted is encapsulated in the AS/4 query as an attachment, which is named using the nomenclature defined for the PeSIT HS E protocol. This data envelope is then sent over the Internet using standard protocols. The data is transmitted using the http protocol, in a POST request, to a static IP address.

+

 

+

The AS/4 protocol allows for the implementation of security levels: messages are signed using an SHA-2 algorithm and exchanges encrypted using an AES 256 algorithm.

+ +

SOAP non-repudiation messages (acknowledgements) are generated in synchronous mode and signed to notify the client of the success (OK) or failure (NOK) of the transfer.

+

 

+

In event of an NOK, the transfer must be repeated. As AS/4 is based on the HTTP protocol, it does not include an automatic failover mechanism. Hence, if transfer acknowledgement is not received, files should not be re-sent: Instead, users should contact their Public invoicing portal technical support contact for verification of the status of their transfers.

+

 

 

  • AS/4 transfer workflow 

+

Outbound circuit of an AS/4 protocol transfer:

+

 

+ +
+ +
 
+

Figure 47: Diagram of the outbound circuit of an AS/4 protocol transfer

+

 

+

Return circuit of an AS/4 protocol transfer:

+

 

+ +
+ +
 
+

Figure 48: Diagram of the return circuit of an AS/4 protocol transfer

+

 

+

+

  1. 7.Glossary 

+ +
+

Abbreviation

+		 +

Meaning

+		 +

Details

+
+

AIFE

+		 +

Agence pour l'informatique financière de l’État (French Agency for State Financial Information Technology)

+		 +

A national public agency responsible for creating the public invoicing platform.

+
+

DGFiP

+		 +

Direction Générale des Finances Publiques (General Directorate of Public Finance)

+		 +

A public service tasked with contributing to the financial soundness of public institutions and fostering an environment of trust in society, the economy and the regions.

+
+

B2B

+		 +

Business to Business

+		 +

Refers to business relations between companies (in particular, relations between a company and its supplier).

+
+

B2C

+		 +

Business to Consumer

+		 +

Refers to business relations between a company and consumers.

+
+

B2G

+		 +

Business to Government

+		 +

Refers to business relations between a company and the public authorities (the government).

+
+

API

+		 +

Application Programming Interface

+		 +

A standardised set of functions that serves as a type of software interface, offering a service to other pieces of software. An IT solution that allows applications to connect and communicate using a common language.

+
+

EDI

+		 +

Electronic Data Interchange

+		 +

Computerised exchange in a standardised format (the data is structured according to international technical standards), to replace the exchange of physical documents.

+
+

E-invoicing

+		 +

Electronic invoicing

+		 +

Requirement for companies to issue invoices in electronic format. Feature for submission, transmission and tracking of B2B and B2G invoices.

+
+

E-reporting

+		 +

Transmission of transaction data in a structured format

+		 +

Requirement for companies to transmit transaction data (international B2B and B2C transactions) to the tax authority in electronic format.

+
+

OD

+		 +

Non-partner dematerialising operator

+		 +

An unregistered provider of invoice dematerialisation services that may act as an intermediary when issuing or receiving invoices, without the possibility of transmitting invoices between the issuer and the recipient.

+
+

PDP

+		 +

Registered private platform

+		 +

A registered provider of invoice dematerialisation services that can send electronic invoices directly to their recipients and transmit data to the public platform.

+
+

PPF

+		 +

Public invoicing portal

+		 +

A public portal operated by the AIFE offering a minimum base of services for the exchange of invoices and consolidation of invoice data and e-reporting for the tax authority.

+
+

GDPR

+		 +

General Data Protection Regulation

+		 +

European regulation that came into force on 25 May 2018 to provide a framework for the equal treatment of data throughout the European Union.

+
+

SIREN

+		 +

French company register identification system

+		 +

A 9-digit registration number used to identify a company.

+
+

SIRET

+		 +

French establishment register identification system

+		 +

A 14-digit registration number (the first 9 digits are the SIREN number) identifying each establishment of a company. The second part, usually referred to as the Internal Classification Number (NIC), consists of a four-digit serial number assigned to the establishment and a control digit, which allows validation of the whole SIRET number.

+
+

VAT

+

 

 +

Value added tax

+
+

CII

+		 +

Cross Industry Invoice

+		 +

Standard for invoice data structure

+
+

UBL Invoice

+		 +

Universal Business Language Invoice

+		 +

Standard for invoice data structure

+

 

+

UN/CEFACT

+		 +

United Nations Centre for Trade Facilitation and Electronic Business

+		 +

A United Nations agency that promotes close collaboration between governments and companies to ensure the interoperability of information exchange between the public and private sectors.

+
+

Factur-X

+

 

 +

An electronic invoice standard known as Hybrid Invoice that contains both a PDF representation of the invoice and its data in a structured format.

+
+

PDF

+		 +

Portable Document Format

+		 +

An unstructured file format developed by Adobe for presenting computerised documents.

+
+

XML

+		 +

Extensible Markup Language

+		 +

A customisable computer language for transmitting data using tags (i.e. using labels to qualify the data).

+
+

PeSIT HS E

+		 +

Protocole d’Echanges pour un Système Interbancaire de Télécompensation (file transfer protocol for the banking industry)

+		 +

A proprietary file exchange protocol for sending files between two connected information systems, a client and a server.

+
+

SFTP

+		 +

Secure File Transfer Protocol (or SSH File Transfer Protocol)

+		 +

A client/server-based file transfer protocol that encrypts the entire connection, including passwords and content.

+
+

AS/2

+		 +

Applicability Statement 2

+		 +

A file transfer protocol that works in “push” mode, allowing a partner to send a file directly to the recipient on its own initiative.

+
+

AS/4

+		 +

Applicability Statement 4

+		 +

Applicability Statement (AS) 4 is an evolution of AS/2 incorporating web services.

+
+

TPE

+		 +

Très petite entreprise (very small enterprise)

+		 +

Refers to micro-enterprises whose annual turnover does not exceed €176,200 if the main activity is the sale of goods, or €72,600 in case of supply of services.

+
+

PME

+		 +

Petite et moyenne entreprise (small and medium-sized enterprise)

+		 +

A company employing fewer than 250 people and with an annual turnover not exceeding €50m or a balance sheet total not exceeding €43m.

+
+

ETI

+		 +

Entreprise de taille intermédiaire (intermediate-sized enterprise)

+		 +

A company employing fewer than 5,000 people and with an annual turnover not exceeding €1,500m or a balance sheet total not exceeding €2,000m

+
+

GE

+		 +

Grande entreprise (large enterprise)

+		 +

A company that meets at least one of the following conditions: at least 5,000 employees; turnover exceeding €1.5bn or a balance sheet total exceeding €2bn.

+
+

CGI

+		 +

French General Tax Code

+		 +

All laws and regulations relating to the basis of assessment and collection of taxes in France.

+
+

EDM

+		 +

Electronic Document Management

+		 +

A computerised process that uses electronic means to facilitate document management. EDM encompasses many transactions and actions that combine the processing and use of information.

+
+

ESN

+		 +

Entreprise de Services du Numérique (digital services company)

+		 +

Since 2013, the acronym ESN has been used to define a company specialising in new technologies and information technology. Prior to this date, the term Société de Services et d'Ingénierie en Informatique (SSII - IT services and engineering company) was used.

+
+

EN 16931

+		 +

European Standard 16931

+		 +

A standard defining a semantic data model for the essential components of an electronic invoice.

+
+

Z report

+		 +

Z report or closing report

+		 +

Supporting document summarising turnover over a given period. Generally, this document is printed at the end of each day from the cash register to show the day’s takings and details of the sales recorded during the day.

+

 

 

 

+

GLN code

+		 +

Global Location Number

+		 +

A 13-digit identifier unique to each company. The information associated with the GLN is the name of the company, SIREN, location, address, phone, email, contact people, invoicing data, etc.

+
+

ODETTE

+		 +

Organisation for data exchange by teletransmission in Europe

+		 +

Organisation for data exchange by teletransmission in Europe. A European automotive industry organisation and a subset of the EDIFACT EDI standard for this industry.

+
+

EPN

+		 +

Etablissement Public National (national public institution)

+		 +

A legal entity under public law with administrative and financial autonomy carrying out a precisely defined public interest mission under the control of the public authority to which it belongs.

+
+

INSEE

+		 +

Institut National de la Statistique et des Etudes Economiques (French National Institute of Statistics and Economic Studies)

+		 +

A directorate-general of the Ministry of Economy, Finance, and Industrial and Digital Sovereignty tasked with collecting, analysing and distributing information on the economy and society throughout French territory.

+
+

Contracting authority

+		 +

Contracting authority

+		 +

An entity with a need, defining the purpose of a project, its schedule and the budget allocated to that project. The expected result of the project is the creation of a product, called a “work”.

+
+

BOI

+		 +

Bulletin officiel des impôts (French official tax gazette)

+		 +

The official public finance and tax gazette (BOFiP-Impôts), formerly the official tax gazette (BOI), consolidating all fiscal doctrine applicable to taxpayers.

+
+

PEPPOL

+		 +

Pan-European Public Procurement OnLine

+		 +

European project launched in 2007 to standardise and simplify electronic exchanges between the public and private sectors.

+
+ + +

+

 

 

  1. 8.Reference texts 

 

+ +
+

Legislative or regulatory text

+		 +

Wording of the reference text

+		 +

Link

+
+

Order

+		 +

Order of 7 October 2022

+		 +

 Link to the order of 7 October 2022

+
+

Bulletin officiel des impôts (BOI, French official tax gazette) / bulletin officiel des finances publiques (French official public finance bulletin)

+		 +

BOI-TVA-CHAMP-10-10-40-40

+		 +

 Link to the BOI

+
+

BOI BIC FIELD 80 30

+		 +

 Link to the BOI

+
+

BOI-TVA-LIQ-30-20-90-20

+		 +

 Link to the BOI

+
+

BOI-VAT - BASE-20-40

+		 +

 Link to the BOI

+
+

BOI VAT BASE 20 20

+		 +

 Link to the BOI

+
+

Civil Code

+		 +

Article 1590

+		 +

 Link to Article 1590

+
+

Public Procurement Code

+		 +

Article L. 2192-5

+		 +

 Link to Article L. 2192-5

+
+

Article L.2193-10

+		 +

 Link to Article L.2193-10

+
+

Commercial code

+		 +

Article R. 123-224

+		 +

 Link to Article R. 123-224

+
+

Article A123-96

+		 +

 Link to Article A123-96

+
+

Article L.123-22

+		 +

 Link to Article L.123-22

+
+

Article R 123-221

+		 +

 Link to Article R 123-221

+
+

Environmental Code

+		 +

Article L.541-10

+		 +

 Link to Article L.541-10

+
+

General Tax Code (CGI)

+		 +

Article 289 bis

+		 +

 Link to Article 289 bis

+
+

Article 289

+		 +

 Link to Article 289

+
+

Article 290

+		 +

 Link to Article 290

+
+

Article 290 A

+		 +

 Link to Article 290A.

+
+

Article 290 B

+		 +

 Link to Article 290 B.

+
+

Article 286 ter

+		 +

 Link to Article 286 ter

+
+

Article 258 A

+		 +

 Link to Article 258 A

+
+

Article 259 B

+		 +

 Link to Article 259 B

+
+

Article 266

+		 +

 Link to Article 266

+
+

Article 268

+		 +

 Link to Article 268

+
+

Article 297 A

+		 +

 Link to Article 297 A

+
+

Article 256 C

+		 +

 Link to Article 256 C

+
+

Article 293 B

+		 +

 Link to Article 293 B

+
+

Article 269

+		 +

 Link to Article 269

+
+

Article 256 C

+		 +

 Link to Article 256 C

+
+

Article 257 ter

+		 +

 Link to Article 257 ter

+
+

Article 242 nonies A

+		 +

 Link to Article 242 nonies A

+
+

Monetary and Financial Code

+		 +

Article L.313-1

+		 +

 Link to Article L.313-1

+
+

Executive Order

+		 +

Executive Order 2022-1299 of 7 October 2022

+		 +

 Link to Executive Order 2022-1299

+
+

Executive Order 2014-928 of 19 August 2014

+		 +

 Link to Executive Order 2014-928

+
+

Book of Tax Procedures

+		 +

Article L.102B

+		 +

 Link to Article L.102B

+
+

Act 75-1334 of 31 December 1975

+		 +

Article 14

+		 +

 Link to Article 14

+
+

Act 2008-776 of 4 August 2008

+		 +

Article 51

+		 +

 Link to Article 51

+
+

Act 2022-1157 of 16 August 2022

+		 +

Article 26

+		 +

 Link to Article 26

+
+

Order (repealed, see Public Procurement Code above)

+		 +

Order 2014-697 of 26 June 2014 (transposition of European Directive 2014/55/EU)

+		 +

-

+
+ +

 

 

 

  1. 9.Contacts 

 

+

Please direct your questions/comments to the project teams:

+

 

 

+

1 The timetable provided under Article 26 of Amending Finance Act 2022-1157 for 2022, adopted on 16 August 2022

+ +

2 Article 51 of Act No. 2008-776 of 4 August 2008 on modernisation of the economy

+ +

1 Article L. 2192-5 of the Public Procurement Code and Articles 289 bis, 290 and 290 A of the General Tax Code

+ +

2 III of Article 289 bis

+ +

3 Minister for the Budget

+ +

1 Some data must be transmitted in certain cases only: for example, the VAT option on debits, the "reverse charge" remark, (etc.).

+ +

1 Only in reform input and during a transitional phase (see 2.4.6.2 Submission of PDF invoices)

+ +

2 Only in reform input and during a transitional phase (see 2.4.6.2 Submission of PDF invoices)

+ +

[1][1] Article L.102B of the Manual of Tax Procedures and Article L.123-22 of the Commercial Code

+ +

1 Article 41 septies D of Annex IV to the CGI

+ +

1 This refers to refusal of an invoice that cannot be addressed to a customer or customer's department on the receive platform (e.g. if the recipient is not a customer or if there is no such department) for which the same invoice will be re-sent. This allows taking account of a fault in the directory data for a given recipient (due to incorrect data, or the time taken to update the directory).

+ +

1 The use of the factor-X for the transmission of flow 1 is not recommended for performance reasons (size of flows, unexploited images, etc.)

+ +

1 Article 289-V of the CGI

+ +

2Article 242 nonies E

+ +

3 As defined in the General Tax Code and the Commercial Code

+ +

1 Non-invoiced transaction data must in all cases be aggregated by day and transmitted in a 10.3 flow.

+ +

1() PDF submission for invoice creation will not be allowed in service mode.

+ + +