.webp)
Read
By clicking on”Accept all cookies“, you agree that cookies may be stored on your device in order to improve site navigation, analyze site usage, and help us with our marketing efforts. See our privacy policy for more information.
.webp)
The General Directorate of Public Finance published a practical guide in July 2026 for launching the electronic invoicing reform, highlighted by the Ministry of Economy just days before the deadline. This 34-page document, organized into 29 Q&As, has a dual purpose: to confirm that the legal timeline is neither postponed nor suspended, and to organize the management of startup incidents without paralyzing economic activity.
Its practical scope is significant and goes beyond the mere question of penalties. The guide resolves issues that the reform had left unclear: the deductibility of VAT on invoices received outside the electronic system, the non-systematic nature of regularization, the distinction between technical rejection and commercial refusal, and the handling of failures attributable to a service provider or a state tool. We have analyzed the full text and provide the key takeaways below.
The guide is presented as an operational document specifying the "course of action" during the electronic invoicing rollout phase. It has four explicit objectives: to ensure business continuity, guarantee the normal processing of invoices, protect the rights of all parties, and organize the regularization of situations that did not immediately follow the electronic circuit required by the reform.
Its structure follows the operational flow of the transition: invoice receipt and payment continuity (questions 1 to 6), issuance of mandatory invoices (questions 7 to 16), voluntary early adoption (questions 17 to 20), e-reporting data transmission (questions 21 to 24), startup incidents (questions 25 and 26), and finally, the compliance trajectory and dialogue with the administration (questions 27 to 29). Each answer is accompanied, where applicable, by references to the relevant legal texts.
Important note. The legal status of this document should be clarified from the outset. It is a practical guide published by the DGFiP, not an administrative commentary integrated into the BOFiP. Its enforceability under Article L. 80 A of the Tax Procedures Code appears uncertain at this stage: it is not published in the database of enforceable comments and is not formally presented as an interpretation of tax law. Businesses should therefore treat it as a reliable guide to the administration's expected behavior (and thus extremely useful) rather than as a legal guarantee that can be invoked in court. This caveat does not diminish its practical value; it simply defines its scope.
Taxpayers may still attempt to rely on the principle of legitimate expectations during discussions with the authorities.
The guide opens with three principles that the administration presents as inseparable, and whose interplay governs the entire reading of the document.
As of September 1, 2026, companies subject to the reform must be able to receive electronic invoices, and those subject to the issuance obligation must issue their invoices through an approved platform. The legal basis is Article 289 bis of the General Tax Code (CGI), which stipulates that the issuance, transmission, and receipt of electronic invoices must be carried out using an approved platform.
This reaffirmation, repeated in every section of the guide, should be taken seriously: it closes the door to interpretations that might view the announced tolerance as a disguised postponement.
The second principle, and arguably the most operational one, is that while the reform changes the methods for transmitting invoices between companies, it does not change the substantive rules regarding the existence of the transaction, commercial debt, payment, invoice accounting, or the right to VAT deduction.
Consequently, an invoice received or transmitted via another customary channel (email, PDF, paper) should not be rejected for that reason alone, provided it corresponds to a real transaction and contains the information necessary for its processing.
The third principle, which tempers the second, is that continuity should not be confused with an exemption from applying the reform. For transactions falling within the scope of the electronic issuance obligation, using a customary channel is not compliant with the target model. The guide therefore encourages companies to proceed with the electronic transmission of the same invoice or to arrange for its regularization as soon as possible, particularly to allow for the transmission of the expected data to the administration (as data from invoices issued under Article 289 bis is transmitted to the administration by the approved platform chosen by the taxable person (CGI, art. 289 E)).
It is from the interplay of these three principles that the document's central formula is derived: during the startup phase, penalties will not be applied to companies encountering difficulties in implementing the reform, provided they are committed to a serious compliance trajectory. The administration will distinguish these situations from those involving inertia, avoidance, or a persistent refusal to adopt the system.
Companies that have not yet designated a receiving platform must initiate the process without delay, either directly through an accredited platform or via their usual solution: management software, accounting software, an accountant, a bank, or another service provider. The guide is explicit: this situation should not lead to interrupting operations, refusing to process received invoices, or blocking payments. However, it must be corrected quickly, and the company must be able to demonstrate that it has taken the necessary steps.
When an electronic invoice is received but the software or internal organization is not yet ready to process it, the company must identify the difficulty (inability to integrate automatically, configuration errors, unfinished internal processes), contact its service provider, and may implement temporary internal processing methods—provided that sufficient traceability is maintained. The guide expressly condemns "artificial" payment delays based on IT difficulties.
This is the most anticipated answer, and it is affirmative. An invoice received via email, PDF, or paper after September 1, 2026, can be processed, recorded, and paid, and the corresponding VAT can be deducted, provided it corresponds to a real transaction and contains the necessary elements for processing. The recipient assesses it based on standard rules: reality of the transaction, identification of the parties, required information, amount, VAT if applicable, and contractual payment terms.
The guide states in express terms that the mere fact that an invoice is not transmitted via the expected electronic channel does not automatically deprive the company of its right to deduction, which remains assessed based on the applicable substantive and formal conditions (CGI, art. 271; mandatory information: CGI, ann. II, art. 242 nonies A).
Note. This clarification resolves an uncertainty that was legitimately worrying financial departments. It makes a clear distinction between two types of obligations: on one hand, the conditions for the right to deduction, which fall under the substantive and formal rules of VAT; on the other hand, the specific obligation of electronic transmission, the failure of which is subject to specific penalties. Non-compliance with the latter does not, in itself, result in the forfeiture of the former. This position is consistent with the case law of the Court of Justice regarding the primacy of substantive conditions, but it was useful for the administration to state it publicly.
When a supplier is subject to the issuance obligation, the recipient may ask them to transmit or regularize the same invoice via the electronic channel. This request is not mandatory and does not constitute a condition for the validity, processing, or payment of an invoice received through another channel. Above all, the guide specifies that it should not be used to block commercial relations or artificially defer a due payment.
Receiving the same invoice through multiple channels should not lead to blocking its processing, but rather to reconciliation: comparing the invoice number, supplier, client, date, amounts excluding tax, VAT, and including all taxes, as well as the status of the electronic flow where applicable. In case of a match, the company designates a reference invoice, continues the validation process on that basis alone, and marks the other copies as duplicates. Any serious doubt should be limited to the specific invoice in question and handled without delay, without blocking the entire process.
For large companies and mid-sized enterprises subject to the issuance obligation starting September 1, 2026, the obligation is not suspended by startup difficulties (whether they stem from the company, its service provider, or its information system).
The guide condemns the "all or nothing" mindset: companies should not wait for their entire system to be perfectly stabilized before they start issuing. They should transition the flows that are ready, prioritize the most significant or sensitive volumes, and organize the handling of residual situations according to an identified plan. This approach, the document specifies, also helps demonstrate that the company is not in a "wait-and-see" or avoidance mode.
When the electronic circuit cannot be used immediately for a specific invoice or flow, transmission via an alternative channel (email, PDF, client portal, existing EDI) can help ensure continuity of processing and avoid blocking operations or cash flow. This transmission should not be analyzed as a new invoice when it relates to an invoice already issued or intended to be issued via the electronic circuit.
However, the guide sets a clear limit: sending via an alternative channel must not become habitual when the electronic flow is operational, and a company subject to the issuance obligation cannot organize its target operating model outside of the system on a long-term basis.
Perspective. A nuance worth noting, as it has escaped most commentary, is that for companies already subject to the issuance obligation, the guide indicates that regularization via electronic transmission of the same invoice "is preferable, but not systematically required." What is required, however, is the ability to demonstrate that an active compliance trajectory is underway and being pursued, particularly when the invoice is not regularized. In other words, the administration does not make invoice-by-invoice regularization a condition for tolerance: it reasons at the level of the overall trajectory. This is considerable flexibility for high-volume companies, for whom the individual regularization of several thousand invoices would be materially impractical. It shifts the focus from the flow to the audit trail.
If a company is unable to identify its client's receiving platform, it must first verify the information used (SIREN, SIRET, recipient establishment, name, contractual data), then contact its own platform to determine if the difficulty stems from incorrect data, a lack of updates, or a routing error. If the difficulty persists, it should contact its client directly, while keeping a record of the steps taken. A standard channel may be used to bring the invoice to the client's attention if urgency justifies it, as a continuity measure.
The guide warns against the systematic multiplication of submissions via multiple channels: when the electronic flow can be tracked via available statuses, these statuses should be used to assess whether a supplementary submission is truly necessary.
The guide clearly separates two situations that internal procedures must handle differently.
A rejection originates from a platform and reflects a transmission or validation issue: format error, missing or inconsistent mandatory data, incorrect party identification, routing difficulty, or a blocking anomaly. The company identifies the cause, corrects the invoice, and retransmits it via the electronic circuit. When the rejection prevents the recipient from accessing the invoice and a blockage is imminent, a copy may be transmitted via an alternative channel, clearly linked to the invoice in question.
A refusal originates from the buyer. This is a lifecycle status that must be justified and is reserved for reasons provided for by the standard: regulatory non-compliance not detected by the receiving platform, misdirected invoice, or failure to comply with contractual conditions preventing invoice processing. The guide expressly states that it should not be used for a simple commercial dispute.
When the refusal is justified, the seller corrects the invoice and, if necessary, issues a new one (this new invoice must include a new number, to avoid any confusion with the refused invoice and any rejection related to the reuse of the same number). When the seller contests the refusal, they should not automatically create a new invoice or a credit note simply because a "refused" status has been applied: they must investigate the disagreement, retain the elements justifying their position, and document the subsequent actions taken.
Point of attention. The guide notes that when parties ultimately agree to maintain an initially refused invoice, they must be able to justify this decision, particularly in the event of discrepancies between data from the lifecycle, the pre-filling of the VAT return, and the returns actually filed. This is the first explicit signal of upcoming cross-audits: lifecycle statuses will feed into the pre-filling process, and any discrepancy between this pre-filling and the filed return will be a red flag. Governance of these statuses is therefore becoming a full-fledged VAT issue, rather than a purely technical one.
Regularization must never create duplicates: the same transaction must not result in two payments, two accounting entries, or two declarations. Managing supplementary submissions should rely on available statuses: when they confirm that the invoice has been successfully transmitted and made available, sending a duplicate via another channel should be avoided, unless specifically required.
When a duplicate is transmitted, it must be clearly linked to the original invoice by a mention such as "duplicate," "copy," or "continuity copy," appearing on the document or in the accompanying information (invoice number, date, amount, original channel, reason for sending, and an indication that it is not a new invoice).
The guide provides an express tolerance for this requirement: during the startup phase, the absence of an explicit mention on the document will not be penalized if the company can demonstrate that adding such a mention would have required specific development, that the document is clearly linked to the original invoice by other means, and that the measures taken successfully prevented duplicate payments, accounting entries, deductions, or declarations.
Companies whose mandatory adoption does not begin until September 1, 2027 (SMEs, small businesses, and micro-enterprises) may voluntarily join the system as early as 2026 to test their tools, train their teams, and align their practices with those of their main clients. This voluntary adoption follows the reform's framework: transmission via an approved platform, complete and compliant invoices, and tracking of statuses and rejections.
Two points of clarification are worth noting for practitioners.
First, if voluntary adoption fails, the company may temporarily revert to its usual invoicing methods without being subject to penalties, as it is not yet legally bound by the mandate. It must simply avoid duplicate invoicing, inform its client, and keep a record of the failure.
Second (and this point is of considerable practical importance in client/subcontractor relationships) a client cannot impose electronic invoicing on a supplier whose obligation does not begin until 2027. The guide states that a client must not refuse to process or pay an invoice solely because it is not electronic. Contractual agreements may naturally organize a paperless exchange, but these should not be confused with the legal obligation resulting from the reform.
Practical advice. This response serves as a valid argument in commercial negotiations. SMEs facing a large client demanding electronic invoicing by September 2026 under threat of payment suspension can usefully point out that the reform does not support such a requirement and that refusing payment solely on the basis of format is not in line with the administration's position. We recommend anticipating this point when reviewing the general terms of purchase imposed by major accounts.
The obligation to transmit transaction and, in some cases, payment data applies from September 1, 2026, for large companies and intermediate-sized enterprises (General Tax Code, arts. 290 and 290 A; Annex II, arts. 242 nonies M to 242 nonies P; Annex IV, arts. 41 septies I to P).
In the event of technical difficulties, the company must neither suspend its activity nor interrupt the transactions in question. It should identify the source of the issue, contact its platform or software provider, and organize the transmission as soon as it becomes possible again.
The guide suggests distinguishing between two situations: a one-off inability to transmit data that is otherwise available (in which case the data is stored, the incident is documented, and the delay is rectified through a regularization process) and an inability to correctly produce the expected data, which requires adjusting settings or internal processes. Two pitfalls are explicitly highlighted: doing nothing while waiting for a global solution, or bulk-transmitting clearly erroneous data to catch up on a delay.
Key point: a temporary e-reporting difficulty does not invalidate invoices, affect payment of transactions, or disrupt business operations. E-reporting is an obligation to transmit data to the administration, distinct from the substantive rules governing the transaction, the invoice, the payment, and the right to deduction.
The guide sets out a protective rule: a company should not be penalized solely for a failure attributable to a third party, provided it can demonstrate that it took the necessary steps within its responsibility. Specifically, it must establish that it selected a solution capable of meeting the requirements, reported the issue to the provider, monitored the resolution of the incident, implemented transitional measures where necessary, and organized regularization whenever possible.
This exemption is therefore not automatic: it requires that the company has actively managed its compliance process and has not used a third party's failure as a pretext to indefinitely delay its adoption of the system. The expected evidence is specifically listed: correspondence with the service provider, support tickets, incident notifications, reported dates of occurrence and resolution, affected data flows, and temporary solutions implemented.
When an incident involves the directory, the hub, or the exchange system, the guide reiterates that the system is designed to prevent a temporary outage of the directory from blocking the entire invoicing process. Platforms can rely on previously retrieved copies or data from the directory, as well as technical addresses used in exchanges, particularly Peppol addresses where available and relevant.
A company is not expected to resolve a failure in a public tool itself. However, it must be able to demonstrate that it identified the incident, took appropriate measures to mitigate its effects, and did not use it as an excuse to delay its entry into the system.
This is the core of the system. A serious roadmap does not require everything to be perfectly stable from day one; it does, however, require the company to have identified its obligations, initiated the necessary work, and organized a process for addressing any difficulties encountered.
The guide lists the relevant elements:
Conversely, a simple statement of intent is not enough: the company must provide concrete, dated, and consistent evidence. The administration's stated objective is to distinguish between genuine startup difficulties and a lack of preparation or a refusal to adopt the system.
Practical advice. We recommend creating a timestamped startup file without delay, centralizing all these documents and updating them on an ongoing basis. This file serves a dual purpose: it substantiates the expected roadmap if the administration makes contact, and it forms the foundation of your defense in the event of a future challenge. Reconstructing it after the fact, once a difficulty has already occurred, would significantly reduce its evidentiary value—as the administration specifically emphasizes the need for the provided evidence to be dated and consistent.
The administration may contact companies when it identifies non-compliance or significant difficulties. The approach is primarily intended to understand the situation, verify the steps taken, and help the company get on a path toward compliance.
The guide clarifies, which is reassuring in practice, thatcompanies are not expected to report every minor incident, isolated rejection, or quickly resolved issue : these situations should first be handled with the platform, software provider, accountant, or client, while keeping relevant records. However, when the administration does contact the company, it must respond in a complete and documented manner—as this dialogue does not constitute authorization to remain outside the system.
The answer to the twenty-ninth question is the most discussed and the most delicate to interpret. Penalties will not be applied immediately, automatically, and indiscriminately simply because a company encounters startup difficulties, provided that these difficulties are genuine, documented, and followed by corrective actions. However, this approach does not mean that the obligation is postponed or suspended.
The guide sets out the criteria that the authorities will use, and this list should be read as a risk assessment framework
The guide reiterates that the regulations provide for penalties. Failure to comply with the electronic invoicing obligation is punishable by a fine per invoice, within the limits set by Article 1737 of the French General Tax Code (CGI). Failure to comply with the data transmission obligations set out in Articles 290 and 290 A falls under the regime of Article 1788 D. Regarding receipt, failure to use an approved platform is subject to a formal notice mechanism—providing a three-month period to comply—before the fine is applied, under the conditions set out in Article 1737, IV bis of the CGI.
The guide expressly defines what the startup approach does not cover
persistently ignoring the obligation;failing to take any action;refusing to participate in the system;intentionally maintaining parallel systems without regularization;using startup difficulties as a pretext to withhold payments or delay compliance.Perspective. The distinction between documented technical difficulties and deliberate inertia is, in principle, welcome: it aligns with the logic of the "right to make a mistake." However, it places the company in an asymmetrical evidentiary position. It is not the tax authorities who must prove bad faith; it is the company that must demonstrate good faith by producing documentation. Yet, the criteria used ("reality" of the difficulty, "quality" of the documentation, "speed" of the correction) are flexible standards, the assessment of which will largely depend on the individual official. In the absence of a legal basis or binding doctrine under Article L. 80 A of the French Tax Procedures Code (LPF), the boundary between an excusable difficulty and a sanctionable failure remains uncertain. This uncertainty argues, in our view, for rigorous and proactive documentation rather than reliance on promised leniency.
Based on the guide as a whole, we believe five areas of work should be addressed immediately.
Designate the receiving platform. This is the first item the authorities will look for, and the only one that materially determines the ability to receive compliant invoices by September 1st. Failure to use an approved platform is also the only situation for which the text explicitly provides for a three-month prior formal notice.
Map the workflows. Distinguish between what is ready and what is not, switch the former immediately, and formalize a dated remediation plan for the latter. The guide explicitly advises against waiting for full stabilization.
Adapt internal procedures. Processing invoices received outside the electronic system, identifying and marking duplicates, distinguishing between technical rejections and reasoned refusals, managing lifecycle status governance, and systematically archiving error messages.
Review client contractual requirements. Particularly those that might condition payment on electronic invoicing before the supplier's legal deadline.
Open and maintain an evidence file. Contracts, schedules, tests, correspondence, support tickets, remediation plans, and internal guidelines—all timestamped.
The administration's position can be summarized as follows: comply where possible, continue operations where necessary, document everything, and demonstrate progress toward full compliance. It is this final requirement, rather than the stated tolerance, that will determine a company's actual exposure to the risk of sanctions.
%20(1).webp)
Partner
%20(1).webp)
Partner
Discover the latest news on indirect taxation and the firm.
.webp)