Open source e-invoicing for the French reform

What the French e-invoicing reform asks of a self-hosted ERP from September 2026

From the start of the reform in September 2026, a French company running Odoo or ERPNext on its own infrastructure must be able to issue and receive structured invoices and send required transaction data through an approved platform. The ERP itself is rarely the hard part. The platform choice, the connector between the ERP and that platform, and the evidence trail that proves each invoice was handled correctly are the real work. The requirements in this section are a planning summary, not legal advice. Before you scope anything, confirm the exact articles that apply, the go-live date for your company category, and the current list of approved platforms with the French tax administration (DGFiP) and with the platform you plan to use.

Factur-X is a hybrid PDF with embedded structured data: a human-readable PDF that carries a machine-readable XML file inside it. Your ERP has to generate both parts from the same invoice record, so the PDF a customer reads and the data a platform processes never diverge. Plan for validation before transmission and for storing the outgoing and incoming files with their status history. Connector design depends on your ERP. Odoo's pricing page places external API access in the Custom plan, so confirm your edition before you design around it. In ERPNext, Server Scripts are disabled by default from version 15 and are not available on Frappe Cloud public shared benches, so a connector may need a dedicated custom app and a hosting model that allows it.

E-reporting covers transaction data that must be sent to the tax administration for certain transactions beyond the invoice exchange itself. Ask your platform and your advisers which transactions fall in scope for your business, because that determines which ERP data fields must be complete and correct. The 2027 date for small and medium-sized companies is a point to confirm for your own category. Staged dates change the order of work, so a company that qualifies for a later date should still prepare its master data, such as tax identifiers and customer addresses, now. Ask any implementation partner for a dated plan that names the approved platform, the connector, the validation rules and the logs that will show a regulator or auditor how each invoice moved.

Which reform requirements map to ERP, platform and access work

This table maps each French e-invoicing reform requirement to what the ERP and platform must do and how to configure it. Read each row as a work item for your ERP team and your approved platform provider, and confirm every article reference with DGFiP guidance before scoping. The main takeaway is that most failures sit in master data, status handling and archiving rather than in invoice rendering.

Requirement	What the function must do	How to configure it
R1: Issue structured invoices	Generate invoices in a structured format that the approved platform can transmit, including Factur-X output where the flow requires it	Enable the e-invoice output in Odoo or ERPNext, map invoice fields to the required structured syntax, and test sample invoices against the platform's validator
R2: Receive structured invoices	Accept inbound structured invoices from suppliers through the approved platform and route them into payables without manual re-keying	Connect the ERP to the platform's inbound interface, define a supplier-matching rule, and set exception queues for invoices that fail parsing
R3: Transmit through an approved platform	Send and receive invoice and status messages through a platform approved for the reform, with the ERP acting as the sender of record	Confirm the platform's approval status with the authorities, configure API credentials in a secrets store, and keep test and production endpoints separate
R4: Send e-reporting data	Report transactions that fall outside the e-invoice flow, such as certain B2C or cross-border sales, to the tax authority on the required schedule	Tag transaction types in the ERP, build a reporting extract from accounting data, and reconcile totals against the ledger before each submission
R5: Master data identifiers	Hold correct SIREN, SIRET, VAT numbers and customer and supplier identifiers so that invoices can be routed and matched	Make identifier fields mandatory on customer and supplier records, validate formats on entry, and run a cleanup of existing partners before go-live
R6: Invoice status and lifecycle	Track acknowledgements, rejections and payment status for each invoice and feed them back to the accounting record	Map platform status codes to ERP states, trigger alerts on rejections, and block payment runs on invoices with unresolved errors
R7: Retention of issued and received records	Keep the structured file, its visual copy and status history for the required period in a form that can be retrieved and audited	Set archive storage with write-once or integrity controls, index records by invoice number, and document the retention period confirmed with DGFiP guidance

Which open-source ERPs fit a French e-invoicing setup

French companies running self-hosted ERP need to decide which system holds the invoice record and how it connects to an approved platform. The four options below differ in license, deployment and how much custom connector work falls to the client. The French e-invoicing modules and platform connectors are not verified in the supplied facts, so each option needs confirmation before selection.

Odoo Community with a custom connector

Odoo Community is licensed under LGPL-3.0, so the core can be self-hosted without a subscription fee. Community has no access to the upgrade service, so the client carries upgrade testing, and the Community edition does not include the Enterprise features that a French approved-platform integration might rely on. Check whether a French e-invoicing module exists for the Community edition and who maintains it. If none is available, the connector to an approved platform is custom work that must be scoped, tested against the reform's formats, and maintained through each Odoo release.

Odoo Enterprise on Odoo.sh or on-premise

Enterprise is a paid edition built on Community. Per the pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes external API access and custom modules, which a connector typically needs. On-premise use requires an Enterprise subscription, and standard support covers the first three years after a major release. Confirm with Odoo whether its French e-invoicing functionality is included in the subscription, which Enterprise version it targets, and what the vendor commits to for the reform's dates.

ERPNext on Docker Compose or bench

ERPNext is licensed under GPL-3.0, and the Frappe Framework it runs on is licensed under MIT. Self-hosting is free, and it can run on Docker Compose using production images or manually with the bench command line tool. Frappe supports only listed versions, and warranty coverage requires a matching Frappe Cloud support plan. Confirm whether a French e-invoicing app exists for ERPNext, its maintenance status, and how it handles Factur-X generation and submission to the approved platform before the build starts.

Separate invoicing tool beside the ERP

Where the ERP is not the system of record for invoices, a dedicated invoicing or accounting tool can issue and transmit e-invoices while the ERP keeps orders and stock. This split adds an interface that must carry master data such as tax IDs, invoice status and corrections in both directions. Verify each candidate's license, its French format and reporting coverage, and whether it connects to an approved platform. Document which system archives the legal invoice copy, since the retention and audit duties apply to the record wherever it sits.

Which Odoo edition supports the connection and upgrades

Odoo Community is the open source core, published under the GNU LGPL version 3, and it can be installed and run on infrastructure you control. It does not include the Enterprise upgrade service, so moving a database to a newer major version is a project you plan and carry out yourselves, using the source and your own migration scripts. For a French e-invoicing project, that means the connector, any e-invoice module and every change to the database schema must be tested against each new release on your own schedule.

No upgrade service: the Community edition has no access to Odoo's upgrade service, so you cannot rely on Odoo to produce a tested upgraded database.
Self-maintained security patches: security updates for a standard support period come through the Enterprise and hosted channels, so Community operators must track and apply fixes from the source themselves.
Connector freedom: you can write the e-invoice integration in your own code without depending on a vendor plan to permit custom modules.
Staffing: you need in-house or partner skills in Python, PostgreSQL and Odoo module development to maintain it.

Confirm with Odoo which features and support terms apply to the Community edition at the time you plan, because the current pricing page and edition page are the authoritative source.

How to connect Odoo or ERPNext to an approved platform in phases

This sequence moves a self-hosted Odoo or ERPNext system from scoping through to a monitored production connection to an approved e-invoicing platform, with a checkpoint at every phase. Each phase produces evidence the finance, IT and compliance teams can review before the next one starts.

Confirm scope and select the platform
Document which entities, sales and purchase flows, and document types must be covered, and confirm with the chosen approved platform or access provider which French e-invoicing formats, reporting paths and API methods it supports. Confirm your ERP edition and version too: Odoo Community and Enterprise differ in features such as the upgrade service, and the Odoo 17.0 standard support ended in September 2026, so check the support status of the version you run. The step is done when a written scope lists in-scope flows, the platform's supported formats, and the ERP version with its support end date.
Clean and import master data
Review customer, supplier, tax ID, address and product records, and fix gaps that the structured invoice requires before any connector is built. For ERPNext, use the Data Import tool with its downloadable CSV or Excel templates, which support child table rows, and import only a few thousand records at a time as the documentation advises. For Odoo, use the import functions available in your edition and validate the results. The step is done when a sample of records passes a reconciliation check against the source system.
Build the structured output and validate it
Build the connector that maps ERP invoice data to the required structure and produces the invoice output, including the Factur-X PDF where the flow requires it. In ERPNext, Server Scripts run Python on document events or as API endpoints, but from version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so the connector may need to be packaged as a custom app. Validate every output against the platform's validation rules and against the official format rules before testing with partners. The step is done when a set of test invoices passes validation with no unexplained errors and the mapping is documented.
Build an isolated test environment
Create a test copy that cannot reach production customers or the live platform. For Odoo, duplicate the database and use the neutralization option for test copies, which the on-premise documentation describes. For ERPNext, build a separate bench or Docker stack. The frappe_docker single-file demo setup is intended for short-lived evaluation only, so use the production-oriented Compose files for any environment that must persist. The step is done when the test stack runs the connector, outbound calls go only to the platform's sandbox, and the environment is documented.
Test with the platform sandbox and trading partners
Send test invoices and receive test documents through the platform's sandbox, then run agreed scenarios with buyers or partners such as credit notes, corrections, rejected documents and inbound invoices from partners that use different tools. Record each result, the error handling applied, and the fix. Ask the platform provider to confirm the sandbox behavior and any changes to format rules before the go-live date. The step is done when the agreed test cases pass and the partners have signed off the results in writing.
Cut over and monitor production
Switch the production connector on in a planned window, with a rollback plan and a named owner for each flow. Set up monitoring that tracks submission status, rejected documents, inbound invoices not yet processed and failed connector jobs, and confirm that the archive holds each issued and received document with its validation result. Review the first cycle of results with finance and compliance before retiring the manual process. The step is done when production invoices are accepted, alerts reach the on-call owner and the archive is verified.

What auditors and the tax administration will ask to see

This table maps each piece of evidence an auditor or tax administration is likely to request to the component that should produce it and the gap most often found in self-hosted French e-invoicing setups. Read it as a checklist to confirm for your own stack, since the producing components and their log depth depend on the ERP, the connector and the approved platform you choose. The main takeaway is that the ERP audit log alone rarely covers platform status, connector changes and archive retention, so each row needs a named owner before the September 2026 go-live.

Evidence	Which component produces it	Gap to close
Dated record of each issued and received invoice with its platform status	Platform status history, cross-referenced to the ERP invoice record	Confirm the platform keeps status changes with timestamps and that IDs match the ERP document number
Factur-X or structured file copies as sent and received	Archive store, fed by the connector output	Confirm the stored file is the exact transmitted version, not a regenerated PDF
E-reporting submissions and their acknowledgements	Connector log and platform status history	Confirm which e-reporting data is sent, how rejections are retried and where acknowledgements are kept
Mapping between ERP fields and the required invoice data	Versioned field mapping documentation kept with the connector configuration	Confirm each mandatory element, such as seller and buyer identifiers and VAT data, has a documented source field
Access logs for users who issue, cancel or change invoices	ERP audit log, with identity provider logs for sign-in	Confirm the ERP logs changes to posted invoices and that shared or service accounts are excluded or documented
Change records for connector and ERP updates, including ERP version and upgrade records	Change management tickets, ERP version history, connector release notes and upgrade test records	Confirm each ERP and connector upgrade was tested on a copy before production and the version in use on each date is recorded
Test records with trading partners and the platform	Test plan and results kept in the project file, with platform test environment logs	Confirm which partner scenarios were tested, the outcome of each and who signed off
Retention evidence for the archive	Archive store with retention settings and integrity checks	Confirm the retention period, storage location, access controls and that deletion requires an approved request

What the 2027 date for SMEs changes in the plan

The 2027 date for SMEs means the French reform does not reach every company at the same time, so the plan has to be built around the category your company falls into. Confirm your category and the go-live date that applies to it in the official guidance published by the French tax administration, and record the source and the date you checked. Do not copy a date from a secondary article or from a vendor slide into the project plan without matching it to that guidance. Treat the category question as the first decision, because it sets the deadline for every later step.

A company that is not yet in scope can still do most of the preparation that the mandate will require. Start receiving structured invoices now, because inbound files show format and data gaps before your own outbound invoices are affected. Clean master data in the ERP, including supplier and customer VAT numbers, legal identifiers, billing addresses and tax treatment, since these fields drive validation later. Test the connector on a non-production copy. In Odoo, database duplication with neutralization supports this; in ERPNext, the Data Import tool can correct records in batches, and its documentation advises importing only a few thousand records at a time.

An SME on a lean ERP plan should decide early whether it needs a custom connector at all. A custom connector means your team or a partner owns the mapping, the error handling and every later change to the rules. Odoo's pricing page states that only its Custom plan can be hosted on Odoo.sh or on-premise, so a lean subscription may mean a managed platform where the vendor maintains the connection. Ask the vendor which e-invoicing connections are included, who updates them when the rules change, and what data leaves your environment. A partner can then write the scope for whichever path you choose, so the decision is recorded before any build work starts.

What the ERP and the platform will not settle on their own

An ERP, an approved platform and a Factur-X generator can move data correctly, but they cannot decide which transactions fall under which rule, which master data is right, or who signs off what. These items sit with the company, its tax advisers, its auditors and its partners, and they should be settled before the build is locked.

Scope of e-invoicing versus e-reporting

Deciding which transactions must be issued as structured e-invoices and which must only be reported as e-reporting data is a legal and tax question, not a configuration setting. Mixed flows such as B2C sales, exports, intra-EU supplies and services need a documented position from tax counsel before the ERP is mapped. Ask your adviser to confirm the classification for each revenue and cost stream and record the answer as a control.

Tax and identifier master data

Structured invoices are only as reliable as the customer and supplier records behind them. VAT numbers, legal names, registered addresses and routing identifiers that are stale or duplicated will fail validation or send documents to the wrong place. Assign an owner for each master data field, set a cleanup pass before the first live issuance, and check each change against the official registry source your team trusts.

Choice and contract with an approved platform

Whether a company issues through its own tooling, an approved platform or a provider it already uses is a commercial decision. Confirm the platform's approval status for the French reform, the formats and flows it covers, how it handles error responses and how it treats changes to the rules. Agree these points in writing, including the exit terms, before integration work starts.

Inbound approval and process ownership

A received invoice has to be matched, approved and posted, and someone must own each step. Software can route an invoice to an approver, but it cannot decide who may approve a supplier invoice above a given value or what happens when a purchase order does not match. Map the approval chain, name the role for each exception and write the rules into the ERP workflow before go-live.

Internal controls and audit evidence

Controls must be designed, operated and evidenced, and independent auditors test them. DeployOpen can prepare the systems, control descriptions and evidence an assessment will need, but it does not issue audit reports or attestations. Agree with your auditors which controls they expect for invoice issuance, receipt and reporting, and which logs and approvals they will sample.

Upgrades and patches of the ERP

The ERP itself has a support window that determines how long it can stay in production. Odoo's standard support covers the first three years after a major release, with security patches only during that period, and Frappe requires customers to run a listed version with a matching support plan to keep vendor warranty. Plan upgrades ahead of any reporting deadline, because an unsupported ERP can block a compliant invoice flow.

What buyers ask before hiring help on French e-invoicing

What does French e-invoicing work cost and what drives it up or down?

The ERPNext pricing page lists self-hosting ERPNext as free, but the French project still carries costs in several places. Odoo Community is open source, while Odoo Enterprise is a paid subscription, and Odoo's pricing page says only the Custom plan can run on Odoo.sh or on-premise, so the edition you need changes the bill. The main cost drivers are the ERP edition and number of legal entities, the count of integrations (ERP, approved platform, archive, reporting), whether the connector is a platform connector or custom code, expected document volume, and the quality of customer and supplier master data. Ask each bidder to split one-time and recurring costs, state which licences are billed per user or per entity, and list exclusions. DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a French e-invoicing project take on self-hosted ERP?

No duration can be stated until the scope and the dates that apply to your company are confirmed. The timeline depends on the ERP and version you run, how many entities and document types enter the flow, whether the approved platform is already contracted, and how much master data needs cleaning. Confirm the platform's onboarding steps and test environment access with the provider, and confirm with your tax advisor which date applies to your company size. Plan upgrades into the same window: Odoo's standard support covers three years after a major release, and major upgrades on Odoo Online and Odoo.sh are mandatory every two years. ERPNext v15 is supported until the end of 2027 and v16 until the end of 2029, so check your version's end date before fixing a go-live.

What does the client team need to provide for the project?

The project needs four client-side roles in place before design starts:

A finance owner who signs off invoice content, tax treatment, numbering and the rules for credit notes.
An IT owner for hosting, network paths, certificates, secrets, backups and access control.
A master data owner who confirms customer and supplier tax identifiers, legal entity details and delivery addresses.
A list of test trading partners, with named contacts who can exchange sample invoices and confirm receipt.

Without the test partner list, the testing phase cannot start, and without the finance owner, the team will rebuild invoice logic after go-live. Ask the partner to name these roles in the written scope so responsibilities are clear before work starts.

Can our internal team implement e-invoicing without an outside partner?

Yes, for simple flows, provided the team has ERP administration skills and a single entity, one ERP, one approved platform connection and standard document templates. The risks grow with custom logic. In ERPNext, Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them, so the hosting choice must support any custom code. Odoo's upgrade service works through a test database that should be tested before production, which takes internal time every upgrade cycle. Before deciding, ask who will patch the ERP, test each upgrade against invoice flows, and handle the first reporting cycle after a rule change.

What does a fixed-scope e-invoicing engagement actually cover?

A fixed-scope engagement covers the work listed in a written scope, with deliverables and timelines agreed before work starts. For a French project, DeployOpen would plan and implement the self-hosted ERP changes, connect the agreed platform, harden and back up the systems, document the configuration, support testing with trading partners, and prepare the systems and evidence that a compliance assessment will review. DeployOpen does not issue audit reports or certifications, and the platform subscription, legal interpretation of the reform and any independent review stay outside the engagement unless the scope says otherwise. Ongoing support, upgrades and continuous testing are available as retainers after go-live.

What should a partner's e-invoicing quote include before we sign?

A useful quote states the scope, the assumptions behind it and the dates that depend on the client's decisions. Ask for the following to be listed separately:

The ERP editions, versions and number of legal entities in scope.
Each flow (outbound invoices, inbound invoices, e-reporting) and the connector type for each.
The test plan, the number of test partners and the exit criteria for go-live.
Master data cleanup and migration work, and who performs it.
Documentation, handover, training and post-go-live support terms.
Licences and platform fees, marked as passed through or included.
Change handling when rules or formats change, and the exclusions.

If a quote cannot name its assumptions, treat its figures as provisional. DeployOpen issues quotes from written scope.

How DeployOpen scopes, delivers and supports French e-invoicing work

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For French e-invoicing, that means agreeing in writing which ERP, which approved platform connection and which evidence the company needs before any build work starts.

How we scope

Inventory the ERP or accounting version, customizations and the French entities that issue and receive invoices.
Confirm with the chosen approved platform which connection, formats and e-reporting data the written scope will cover.
Agree deliverables, test environments and timelines in writing, since most engagements are fixed-scope before work starts.

How we build

Connect Odoo or ERPNext to the approved platform, keeping the ERP's own invoice data as the system of record.
Configure Factur-X output, mapping of tax identifiers and inbound invoice handling, then test each path against sample documents.
Harden the integration with access controls, logging and change management aligned with the client's security baseline.

How we hand over

Document the configuration, data mappings, credentials handling and error-handling runbooks for the client's own staff.
Deliver test evidence from partner and platform trials, including rejected invoices and how each rejection was resolved.
Run a handover session so the client's team can operate the connection and track changes to the reform's requirements.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Track ERP version support dates and plan upgrades before a version leaves standard support.
Prepare compliance evidence for independent assessors, who issue any audit report or certification, not DeployOpen.

Open source e-invoicing for the French e-invoicing reform