Connecting e-invoicing 2026 and ERP: the role of no-code tools

France's e-invoicing reform, introduced by ordinance 2021-1190, is not a simple upgrade to PDF delivery. It restructures B2B invoice flows so that every transaction passes through a state-accredited private platform — known as a PDP (accredited e-invoicing platform) — which validates, routes and reports fiscal data to the tax authority (DGFiP). For directors of SMEs and smaller businesses, the question is no longer whether to comply, but how your ERP or billing software will interface with this new infrastructure without consuming months of IT development.

This is precisely where no-code and low-code tools enter the picture. Before examining the available options, the regulatory milestones need stating with precision, since deadlines differ by company size and the architecture has changed significantly since the reform was first announced.

Direct answer. Reception of e-invoices is mandatory for all French VAT-registered businesses from 1 September 2026. Emission follows the same date for large enterprises (GE) and mid-sized companies (ETI); SMEs, very small businesses and sole traders have until 1 September 2027. The free public PPF (public invoicing portal) for emission and reception was abandoned on 15 October 2024: every business must now use an accredited PDP or Chorus Pro (public sector only) for its B2B flows.

The schedule falls into two distinct phases:

• 1 September 2026: mandatory reception for all French VAT-registered businesses, regardless of size. Large enterprises and mid-sized companies must also be capable of emitting structured e-invoices via a PDP by this date. E-reporting obligations (B2C transactions and international flows) start on the same date.
• 1 September 2027: emission obligation extended to SMEs, micro-businesses and sole traders.

The one-year gap between reception and emission for smaller structures is frequently misread. Being "reception-ready" means your system must accept, process and archive structured invoices received from large-company suppliers from 1 September 2026 — even if you are not yet emitting structured invoices yourself. Ignoring the reception obligation risks blocking your own supplier payment processes.

The PPF (public invoicing portal) was originally designed as a free public platform handling both emission and reception. This project was officially abandoned by DGFiP on 15 October 2024. The consequence is significant: there is no longer any free public solution for B2B e-invoice flows.

The PPF now fulfils two technical functions that are invisible to most business directors:

What the PPF no longer does: emit, receive or store invoices on behalf of businesses. Chorus Pro remains the sole official channel for public-sector invoicing (B2G) and should not be confused with private B2B flows.

A PDP (Plateforme de Dématérialisation Partenaire — accredited e-invoicing platform) is a private operator accredited by DGFiP. It handles the secure transmission of invoices between buyers and sellers, manages the invoice lifecycle (emission, delivery, acceptance, rejection, payment acknowledgement) and forwards fiscal data to the PPF.

Choosing a PDP involves several criteria: supported formats (Factur-X, UBL, CII), native connectors with your ERP, API quality for no-code integration, and per-invoice pricing. The official list of accredited PDPs is published on impots.gouv.fr.

Three formats form the accepted technical base, all compliant with the European standard EN 16931:

1. Factur-X (hybrid PDF/XML invoice format): a PDF readable by humans with an embedded XML file for automated processing. The most widely adopted format in early French implementations.
2. UBL (Universal Business Language): an XML standard widely used across Northern Europe and in international trade.
3. CII (Cross Industry Invoice): an XML format derived from the UN/CEFACT standard, common in industrial sectors.

For an SME working with diverse partners, the ability of your ERP or no-code orchestrator to produce and consume all three formats is a non-negotiable selection criterion.

The French Finance Act 2026 (LF 2026) set the applicable penalties:

The amounts appear modest per incident, but an SME emitting several hundred invoices a month reaches the annual ceiling quickly. The risk is not only financial: non-compliance identified during a VAT audit reinforces scrutiny across the entire tax file.

Three integration architectures coexist, with very different levels of complexity and cost:

1. Native ERP editor connector#

Some ERP publishers — including Sage, Cegid, SAP, Odoo and Pennylane — are building or have built integrated connectors to one or more partner PDPs. This is the simplest path operationally, provided your ERP version is actively maintained and the offered PDP meets your requirements. The constraint: you depend on the editor's roadmap and sometimes have a limited choice of PDP.

2. Direct PDP API#

The PDP exposes a REST or SFTP API that your technical team or IT provider can call directly from the ERP. This approach offers the most control over data mapping and output formats, but requires bespoke development — and therefore technical resources and a project budget.

3. No-code / low-code orchestration#

For flows not covered natively, or for businesses without a dedicated development team, no-code tools such as Make, Zapier, n8n and Microsoft Power Automate allow integration workflows to be built without writing code. A typical scenario: extract invoice data from the ERP, convert to Factur-X via a transformation module, push to the PDP API, then retrieve the delivery status for updating in the accounting system.

A worked example covering the full invoice lifecycle:

Scenario: SME using Odoo ERP, accredited PDP partner, Make orchestration

1. Trigger: a new invoice is set to "validated" status in Odoo. A Make webhook is notified.
2. Extraction: Make retrieves the mandatory fields (buyer/seller SIREN, net amount, VAT rate, invoice number, date).
3. Transformation: a conversion module produces the Factur-X file (PDF with embedded XML), applying the correct mapping to EN 16931 fields.
4. PDP submission: Make calls the PDP API with OAuth2 authentication and transmits the file and metadata.
5. Status management: the PDP returns a status (delivered, accepted, rejected). Make updates the "invoice status" field in Odoo and triggers a notification on rejection.
6. Automatic posting: on receipt of an "accepted" status, an accounting entry is created or updated in Odoo's Finance module.

This flow can be deployed within days for an SME with standard invoicing. Complexity increases for multi-currency invoices, complex credit notes or intercompany recharging arrangements.

The appeal of no-code should not lead businesses to underestimate several structural issues:

• Data mapping: your ERP fields do not always correspond to the mandatory fields in the EN 16931 schema. An upfront audit of your counterparty master data (SIREN, address, VAT registration number) is essential.
• Invoice lifecycle management: the reform requires managing and archiving invoice statuses (emitted, delivered, accepted, rejected, disputed). The no-code workflow must write these statuses in a traceable way, not simply transmit the file.
• Credential security: PDP API tokens must be stored in a secure vault, not in plain text inside the Make or n8n scenario. Regular rotation is recommended.
• Volume and SLA: consumer-grade no-code tools have monthly trigger limits depending on the subscription plan. Verify capacity to absorb billing peaks at month-end or quarter-end.
• Archiving: the original signed e-invoice must be retained for ten years. The workflow must cover timestamped archiving, not only transmission.

The temptation for a smaller business is to defer until September 2027, since the emission obligation only applies then. Three arguments support acting earlier:

Reception is mandatory from 1 September 2026: you will receive structured invoices from large-company suppliers before you emit them yourself. If your system is not ready, you risk stalling your own invoice validation and payment processes. Well-positioned PDPs are already reporting onboarding lead times, and businesses that wait until late 2026 will find less flexibility and longer queues. The compliance project also involves data quality work — correcting missing SIREN numbers, incomplete addresses, erroneous VAT registration details — which takes time and should not be started under pressure.

No-code is a relevant tactical lever in a specific context: an ERP without a native connector, no available technical team, and a short runway before the regulatory deadline. It is not a long-term architecture for high-volume emitters or businesses with complex accounting flows.

The sound approach is to audit the current state (ERP, output formats, data quality), identify gaps against PDP requirements, evaluate the three integration paths with their total cost of ownership (deployment, maintenance, future change), then decide with full information. An e-invoicing compliance mission covers this diagnostic upfront, without a predetermined technical outcome.

For businesses pursuing a broader digital transformation of their finance function — ERP, reporting, automated close — a finance digital transformation mission provides a more structured framework.

This article provides a general analytical framework. Technical choices and regulatory obligations must be assessed against your specific business situation, ERP configuration and the current accreditation status of PDP platforms. Information is current as of 29/05/2026; deadlines and conditions may evolve — consult impots.gouv.fr for the applicable texts.