How Odoo helps with French e-invoicing before the deadline
Odoo covers the platform side of French e-invoicing through its approved platform status and the France E-Invoicing (Approved Platform) module, l10n_fr_pdp. It does not cover your company's obligations, your tax decisions or the audit of either. Finance and IT leaders who must receive, and possibly send, French B2B e-invoices and e-reports from September 1, 2026 should treat Odoo as a set of capabilities they configure and operate, while compliance remains a company outcome. Odoo states that it receives Factur-X, UBL and CII documents, so the first task is to confirm which of those formats your trading partners use and which edition and hosting model carry the module in your contract.
Several decisions stay with your company. Company size classification determines whether you must send invoices and e-report from 2026 or only receive them, and the reform applies to all companies from September 1, 2027. Your team also chooses the workflows: how invoices are validated, how rejections and disputes are handled, who approves outgoing documents and how exceptions reach accounting. Legal interpretation of scope, including which transactions fall under e-reporting, needs input from your tax and legal advisers. Finally, the independent auditor or certification body you engage decides whether your controls meet their criteria. Odoo's documentation does not make any of these choices for you.
DeployOpen's work on this topic is to prepare the systems and the evidence your decisions depend on. In practice this means mapping inbound and outbound document flows, testing the l10n_fr_pdp configuration on a duplicated test database with neutralization so that no live data leaves the company, and checking whether l10n_fr_reports and, for points of sale, the anti-fraud module l10n_fr_pos_cert under CGI 286 I-3 bis apply to your sales channels. The target Odoo version also matters. Odoo 19.0 has standard support until September 2028, and Odoo 20.0 was released in September 2026, so confirm which version you will run before the test cycle begins.
Evidence is what makes the setup reviewable. Typical records include the configuration baseline, role and approval matrices, test results for each document format, a runbook for rejected or failed transmissions, and change records for every production update. DeployOpen does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the purpose of this preparation is to give them clear, current material. Before work starts, ask for a written scope that lists the modules, versions, formats, sales channels and deliverables covered, and confirm the edition and hosting requirements for l10n_fr_pdp with Odoo directly.
Mapping each French e-invoicing requirement to Odoo
This table maps each French e-invoicing and e-reporting obligation to the Odoo module or capability that addresses it, along with the configuration steps to confirm. Read the first column for the obligation, the middle column for what Odoo provides, and the last column for what your team must verify in its own instance. The main takeaway is that receiving, sending and reporting duties depend on company size and date, so confirm your timeline and module setup well before September 1, 2026.
| Requirement | Platform capability | Configuration |
|---|---|---|
| Receive domestic B2B e-invoices through approved platforms from September 1, 2026 | Odoo states it is an officially certified approved platform, enabled through the France E-Invoicing module l10n_fr_pdp | Item to confirm: install l10n_fr_pdp and verify the approved platform enablement in your instance |
| Send and e-report for large and mid-sized enterprises from September 1, 2026 | Outgoing invoices and e-reporting handled through l10n_fr_pdp, for companies in scope | Item to confirm: outgoing invoice flows, customer records and reporting settings; confirm your size category with your tax adviser |
| Same obligations for all companies from September 1, 2027 | Same l10n_fr_pdp receiving and sending workflows, applied to every company in your database | Item to confirm: rollout plan and onboarding for smaller entities, including each company's settings |
| Supported formats: Factur-X, UBL and CII | Odoo documents receipt of Factur-X, UBL and CII documents | Item to confirm: which formats each customer and supplier uses, and the format set on each partner |
| Point-of-sale VAT anti-fraud certification under CGI 286 I-3 bis | l10n_fr_pos_cert provides the VAT anti-fraud certification for points of sale | Item to confirm: install l10n_fr_pos_cert on each point-of-sale configuration and verify it is active |
| French VAT report | l10n_fr_reports provides the French VAT report | Item to confirm: VAT tax mapping, report periods and test runs against your ledger in your instance |
Which French e-invoicing dates apply to your company
Three dates set the obligations for French companies, and the first one that applies to your company is the deadline your Odoo project has to meet. From September 1, 2026, every company must be able to receive domestic B2B e-invoices through approved platforms. On the same date, large and mid-sized enterprises must also send e-invoices and e-report. From September 1, 2027, the send and e-report obligations extend to all companies. Read the dates in that order, because the earliest one that applies to you is the one that drives your planning.
Receiving is the obligation that reaches every company first. A company that expects to send invoices only from 2027 still has to receive domestic B2B invoices through an approved platform from September 1, 2026. Inbound invoices, their supported formats and their status handling therefore need to be in place before the first date. Check which invoice flows your team runs today, including supplier invoices that still arrive as PDF files by email, and note which of them must move onto the platform path for each date.
Company size classification is a legal question, and this page does not define it. Whether your company counts as large, mid-sized or in another category depends on criteria that your tax or legal advisor applies to your facts. Ask for a written conclusion that states the criteria used and the date the conclusion was reached. That answer decides which send and e-report date your Odoo configuration and testing must meet, so settle it before the project plan is fixed rather than during the build.
Readiness has to finish before the first date that applies to you. If your company is large or mid-sized, that date is September 1, 2026, and the receiving and sending work must be tested by then. Plan backward from that date: confirm the approved platform setup and the l10n_fr_pdp module in a test copy, run sample invoices in each supported format through the full cycle, and check your VAT and point of sale configuration with the people who file returns. Build in time for corrections, because a failed test found in the final weeks leaves little room to fix it.
If your company falls into the group that starts in 2027, do not treat that later date as a buffer for the whole project. Use it to scope the sending and e-reporting work, but keep receiving on the 2026 schedule. Write down which date applies to each legal entity or business unit, and assign an owner to confirm the classification with your advisor and the vendor before the next project review.
Factur-X, UBL and CII: which format the project must handle
Factur-X is a hybrid format for invoices that people read and systems also process. One file combines a human-readable PDF with a structured data file that carries the same invoice details. A buyer can open the document like any PDF, while their systems extract the fields automatically. French companies that already send PDF invoices by email or portal often look at this format first, because it adds machine-readable data without changing what the invoice looks like to the recipient.
What the project needs to settle:
- Partner expectations: Confirm whether your customers and suppliers expect Factur-X at all, and for which invoice types.
- Odoo receiving: Odoo documents receiving Factur-X documents, enabled through the l10n_fr_pdp module. Verify this on your target Odoo version with your Odoo partner before you rely on it.
- Outbound documents: Ask trading partners whether your outbound invoices must be produced as Factur-X, or whether another format is accepted.
- Archive copies: Decide who keeps the PDF and the embedded data, which system stores each, and how the two stay matched.
- Mixed inbound flows: Plan for suppliers that send Factur-X alongside suppliers that send structured XML only.
Check with your platform and trading partner counterparts which flows use Factur-X, and whether your outbound documents must carry it.
UBL is an XML standard for business documents such as invoices. It carries structured data only, with no visual layer. The receiving system reads the data directly, and any human-readable view must be produced by software. UBL is common in procurement processes that are built around structured documents, including many buyers in the public sector. It suits flows where both sides have automated systems that read the XML without manual review.
What the project needs to settle:
- Partner expectations: Confirm which of your customers or suppliers send and receive UBL, and whether any of them expect it back.
- Odoo receiving: Odoo documents receiving UBL documents, enabled through the l10n_fr_pdp module. Confirm the supported handling for your Odoo version with your Odoo partner.
- Outbound documents: Agree in writing whether outbound invoices must be produced as UBL, and which variant or profile your partners accept.
- Human-readable copies: Decide who needs a visual version for accounts payable, customers or audit, and how it is generated.
- Validation: Ask each partner how they test incoming documents, and plan test exchanges before production.
Check with your platform and trading partner counterparts which flows use UBL, and whether outbound documents must be produced in it.
CII is an XML syntax based on the UN/CEFACT cross-industry invoice model. Like UBL, it carries structured invoice data without a visual layer, so a person needs a rendered view to read it. It is used in exchanges where partners have chosen this syntax, and it often appears alongside UBL in the same inbound flows. Which of the two a trading partner uses is usually a choice made on their side, so your team must ask rather than assume.
What the project needs to settle:
- Partner expectations: Confirm which trading partners send CII and whether any of them require it for outbound documents.
- Odoo receiving: Odoo documents receiving CII documents, enabled through the l10n_fr_pdp module. Confirm the handling on your target Odoo version with your Odoo partner.
- Outbound documents: Agree whether outbound invoices must be produced as CII, and whether a single outbound format serves all partners.
- Conversion needs: Ask whether any flow requires converting between formats, and who owns that step and its testing.
- Operations: Assign an owner for rejected or malformed documents, so that a format mismatch does not stall invoice processing.
Check with your platform and trading partner counterparts which flows use CII, and whether outbound documents must be produced in it.
How the POS anti-fraud certification module fits the project
The point of sale anti-fraud certification is handled by l10n_fr_pos_cert, a module included in Odoo's French localization. It covers the VAT anti-fraud certification for points of sale under CGI 286 I-3 bis. This module is separate from the e-invoicing module, l10n_fr_pdp, which handles receipt and transmission of domestic B2B invoices through an approved platform. Keep the two in separate workstreams in the project plan, with their own configuration steps and acceptance tests. A company may need one of them without the other, depending on how it sells, so the plan should state which module each sales channel depends on before the build begins.
The scope of this work depends on whether the company runs point of sale at all. A business that sells only online or only through invoices may have little or no POS configuration to certify. A business with shops, pop-up stands, or in-store pickup may need the module across several terminals and sessions. Make an inventory of every channel that records a sale in Odoo, including any that take payment on a device outside a shop. Then ask a tax adviser how the certification applies to each channel. The adviser's answer decides whether the module is installed everywhere, only in some locations, or not at all, and it should be written into the scope before any quote is accepted.
Three groups share the work. Finance owns the tax treatment: which VAT rates apply to POS products, how fiscal positions map to POS sales, how session closings post to journals, and how the certification requirements are interpreted for the company. Store operations owns the POS configuration: terminals, payment methods, opening and closing routines, user rights, and who may change a configuration after go-live. The implementation team installs and configures the module, runs test sessions in a non-production copy, and records the evidence. DeployOpen prepares the system and its evidence for review, but the certification itself is not issued by the implementer, so the company must decide who it will present the evidence to.
Before the build starts, confirm the Odoo version and edition the company plans to run and check that l10n_fr_pos_cert is available for it. Agree the list of terminals and sales channels in scope, and ask the tax adviser to confirm the treatment in writing. During testing, run sample sessions for each channel and keep the resulting records, configuration exports, and approval notes together. After go-live, place POS settings under change control so that a rate change or new payment method is reviewed by finance before it reaches production. When requesting a quote, ask for POS work to be itemized separately from the e-invoicing work, with the number of terminals and channels stated as the main drivers of effort.
Evidence to keep for the French e-invoicing project
The readiness file should show what was configured, what was tested and who could act in the system. Each card below proves one part of that record, names an owner and says where the evidence should be stored. Keeping them in one controlled location lets a reviewer follow each step from approved scope to exchanged test documents.
Approved localization scope
This record proves that the French localization was scoped, configured and approved before testing began. List the modules in use, such as l10n_fr_pdp for approved platform exchange and l10n_fr_reports for the French VAT report, and add l10n_fr_pos_cert only where point of sale sales are in scope. Record the chart of accounts, tax mappings and the named approver. The finance controller usually owns it. Store the signed decision with a configuration export in your document management system under change control.
Installed module and version record
This record shows which modules and which Odoo release the French configuration runs on, so each test result can be tied to a known state. Export the installed module list with technical names and versions from every environment, and note the edition in use. Odoo 19.0 has standard support until September 2028, so include that date in the file. Platform engineering keeps the record and refreshes it at each deployment. Store exports in a Git repository with dated commits so every change has an author and a reason.
Neutralized test database records
This record proves that test copies were created by duplicating a production database and then neutralizing it, so test activity cannot reach live customers or send live documents to the platform. Log the source database, the date, the operator and the neutralization result. Confirm separately that external connectors, outgoing email and payment settings were disabled or pointed to test endpoints, because the duplication step alone does not show that. The platform team keeps the log in the ticket linked to each test cycle.
Upgrade test database results
This record shows that the upgraded test database was checked before any production move, as Odoo's upgrade documentation expects. Keep the test plan, the scenarios run (invoice issuance, credit notes, tax reports and transmission to the approved platform), the defects found, their fixes and the final sign-off. Application owners run the tests and the platform lead approves them. Store results with logs in the same repository as the module record, tagged by target version. On-premise upgrades require an Enterprise subscription, so confirm entitlement first.
Sign-in and two-factor controls
This record proves who can sign in to the system that issues and transmits invoices, and how that access is protected. Document the LDAP configuration, including whether users are created on first login from a template, the two-factor authentication settings and any other sign-in method in use, such as Google Sign-In or Microsoft Azure OAuth. List the groups allowed to validate or send e-invoices. The identity or security team owns this record. Store configuration exports and the approval for each privileged group in your access management system.
Test exchange records by format
This record shows that test documents were exchanged through the approved platform in each format the project relies on: Factur-X, UBL and CII. For each format, keep a sample outgoing invoice, the incoming test document, the platform acknowledgment or error message and the reviewer's result. Note which document types were covered, since e-reporting carries its own data requirements. Finance operations keeps the file with the original documents and messages. Store each format in its own folder indexed by test date, so a gap in any format is visible at a glance.
Configuration sequence for French e-invoicing on Odoo
This sequence takes a French company from confirming its legal dates and Odoo edition to a documented, signed-off configuration for receiving and sending e-invoices and filing VAT returns. Each step names what the implementation team does and what the client must provide, so the client can see the work before it starts.
Confirm applicable dates and company profile
The implementation team reviews the company's size category, its B2B and B2C flows, and whether it issues invoices through a point of sale. France's reform requires every company to be able to receive domestic B2B e-invoices through approved platforms from September 1, 2026, while large and mid-sized enterprises must also send them and e-report from that date. All companies follow from September 1, 2027. The client provides the legal entity list, group structure, sales channels and a named tax or finance owner who confirms the obligations with their accountant. Done means a written note stating which obligations apply to each entity and by which date, signed by the client's finance owner.
Confirm hosting, version and support window
The team checks the hosting type, the Odoo edition and the version in use against Odoo's support documentation. Odoo states standard support covers three years after a major release on Odoo Online, Odoo.sh and on-premise. Odoo 19.0 has standard support until September 2028, Odoo 20.0 until September 2029, and Odoo 17.0 standard support ended in September 2026. Only the Custom plan can run on Odoo.sh or on-premise, and on-premise use requires an Enterprise subscription. The client provides the current subscription details, the hosting location and any planned upgrade dates. Done means a recorded version decision, with the upgrade path agreed if the current version is near the end of standard support.
Install the French localization and l10n_fr_pdp
The team installs the French fiscal localization and the France E-Invoicing (Approved Platform) module, l10n_fr_pdp, on the target database. On-premise Enterprise databases are activated by entering the subscription code before modules are added. Odoo states it is officially certified as an approved platform and receives Factur-X, UBL and CII documents, so the team confirms which formats are enabled for the company. The client provides the subscription code, access to the production and test environments and a named administrator for module installation. Done means the modules are installed on the test database with an install log, and the enabled formats are listed in the configuration record.
Configure company and tax data
The team sets the legal identifiers, registered address, fiscal position, default VAT taxes, chart of accounts and journals for each French entity. Errors here carry into every invoice, so the team checks each tax mapping against the client's VAT rates and exemptions and records which product categories use each tax. The client provides the company registration data, the VAT registration details, the chart of accounts in use, and written approval of the tax mapping from their accountant. Done means a signed tax mapping sheet and a set of sample invoices generated on the test database that show the correct taxes, numbering and legal mentions.
Set up neutralized test copies
The team creates a test copy of the production database and neutralizes it before any connection to an external platform. Odoo documents database duplication with neutralization for test copies, which disables scheduled actions, outgoing mail and external connections so a copy cannot send live documents. The team then confirms the copy cannot reach the production approved platform connection. The client provides a test tenant or sandbox access from their platform provider if one is available, and confirms which users may use the copy. Done means a neutralization checklist is completed, with a screenshot or log entry for each disabled connection, and the copy is marked as test in the environment register.
Test receiving and sending by format
The team runs test documents through each enabled format, Factur-X, UBL and CII, in both directions. For receiving, they check that an incoming file creates the correct vendor bill, taxes and attachments. For sending, they check that an outgoing invoice produces a valid file, the correct buyer identifiers and the status returned by the platform. Each format and case gets a result row with the document reference and outcome. The client provides sample invoices from real trading partners, the test identifiers agreed with those partners and the names of staff who will handle rejected documents. Done means every format has passed both directions, and all failures are logged with a resolution or an open ticket.
Configure the POS certification module
This step applies only if the company uses Odoo point of sale to issue invoices or receipts. The team installs l10n_fr_pos_cert, the VAT anti-fraud certification module for points of sale under CGI 286 I-3 bis, and confirms the POS configuration is compatible with it. They then test sales, refunds and closing sessions to confirm the certification output is recorded. The client provides the list of POS terminals, the sales workflows in use and written confirmation from their tax advisor on the certification requirement for each shop. Done means the POS test scenarios pass on the test database, and the advisor has approved the POS configuration in writing.
Test the VAT report with l10n_fr_reports
The team installs l10n_fr_reports and runs the French VAT report on test data that covers every tax type in use, including credit notes and any reverse-charge transactions. They reconcile the report totals against the general ledger and against a manual calculation for a sample period. The client provides a period of test transactions, the accountant who will sign the return and access to the existing filing records for comparison. Done means the report totals match the ledger and the manual calculation for the agreed sample, and the differences found are recorded and cleared.
Document results and obtain sign-off
The team compiles the configuration record, the tax mapping, the neutralization checklist, the format test results, the POS test results and the VAT report reconciliation into one document. Each item links to its evidence and names the person who approved it. The team then walks the client through open items and any remaining risks, and the client signs the document before production use. The client provides named approvers for finance, tax, IT operations and, if relevant, the POS owner. Done means a signed sign-off document is filed, with the open items and their owners listed, and the production change is scheduled only after that sign-off.
What Odoo does not cover in this project
Odoo supplies the software and the approved platform feature, but parts of e-invoicing compliance stay with your company, your advisers and your suppliers. The cards below set out each item, what you must decide or own, and what to confirm before the September 2026 start date.
Legal, tax and company size
Your tax advisers and legal counsel decide how the reform applies to your invoices, credit notes, VAT treatment and reporting. Your company size classification sets your deadline: September 1, 2026 for large and mid-sized enterprises, and September 1, 2027 for all companies. Confirm your classification in writing before you configure transmission and e-reporting in Odoo, because the software cannot make that determination for you.
Terms with other providers
Odoo's approved platform status does not cover the contracts around your deployment. Your hosting provider, any integrator, a document archive or any other service in the invoicing flow each has its own terms for service levels, data location, liability and exit. Ask each provider which steps of the flow they touch, who holds the data at each step, and how termination or migration would work. Review these terms alongside your Odoo subscription.
Trading partner readiness
Your customers and suppliers must be able to receive and process the invoices you send, and their systems determine whether an exchange succeeds. Agree with each significant trading partner which formats they accept, how they return status and how they handle invoices they cannot process. Odoo receives Factur-X, UBL and CII documents, but your partners' acceptance and their own platform choices remain outside this project. Build a test list with them before cut-over.
Independent audit and certification
Where your obligations or your auditors require independent assurance, an auditor or certification body must provide it. Odoo's stated approved platform status does not by itself confirm the assessment an auditor makes of your environment. DeployOpen can prepare configuration, evidence and documentation for review, but does not issue audit reports, attestations or certifications. Confirm with your auditor which evidence they need, when they will test and who signs off the result.
Invoice numbering and dispute handling
Your finance team owns the rules for invoice numbering, sequence gaps, corrections, credit notes and the handling of disputed or rejected invoices. Odoo applies the sequences and workflows you configure, but it cannot decide whether a rejected invoice is reissued, cancelled or contested with the buyer. Write these rules down, assign an owner to each rejection type and train staff before the first production invoice.
Odoo versions outside standard support
Security patches are only provided during standard support, and Odoo 17.0 standard support ended in September 2026. Standard support runs until September 2027 for Odoo 18.0, September 2028 for Odoo 19.0 and September 2029 for Odoo 20.0. You decide which version you run and when you upgrade, and you carry the risk of running a version without patches. Major upgrades are mandatory every two years on Odoo Online and Odoo.sh, and SaaS versions cannot use extended support.
Edition, hosting and version choices that set your deadline
The first decision is the edition, because it determines whether the French e-invoicing features are available to you at all. Odoo's Community edition is fully open source under the LGPL-3.0 license. The Enterprise edition adds features and support, but its source code is not public, so access requires a subscription or partner access. Odoo's pricing page lists the Custom plan as the only plan that can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. A company that needs its data inside its own infrastructure is therefore steered toward Custom. Before you commit, confirm in writing with Odoo whether the France E-Invoicing (Approved Platform) module, l10n_fr_pdp, is available on the edition and plan you intend to buy, and whether the approved platform service is included or billed separately.
Support windows set the real end date for your installation. Standard support for a major release runs three years and covers security updates and bug fixes on Odoo Online, Odoo.sh and on-premise. Odoo 17.0 standard support ended in September 2026, so any company still running 17.0 is outside the window that provides security patches. Odoo 18.0 standard support runs until September 2027. Paid extended support exists only for Odoo.sh on select versions and for on-premise, and Odoo documents that security patches are provided only during standard support. Plan your target version against the standard support end date, not the release date, and ask Odoo which extended support terms apply to your version and hosting type before you rely on them for a compliance date.
Hosting also changes the upgrade calendar. Odoo SaaS versions are released every two to three months and cannot use extended support, so a company on Odoo Online has to keep pace with a steady release cycle rather than plan a single large move. Odoo's upgrade documentation states that major version upgrades are mandatory every two years on Odoo Online and Odoo.sh. On-premise deployments keep control of timing, but they carry the work of testing and applying each upgrade themselves. Whichever hosting type you choose, put the next mandatory upgrade date into the same plan as the e-invoicing go-live, because a reform deadline and an upgrade window can land in the same quarter.
The upgrade service is the documented route from one supported version to the next. It creates an upgraded test database, which should be tested before anything reaches production. Use of the service on-premise requires an Enterprise subscription, and the Community edition has no access to it. A Community deployment would therefore need its own upgrade method, which should be costed and tested before the company commits to that edition. For on-premise Enterprise installations, the subscription code must be entered to activate the database, so the subscription should be in place before the first installation. Odoo also documents database duplication with neutralization for test copies, which lets you rehearse upgrades and French invoicing flows without touching live data.
Turn these choices into a written decision record before any build begins. Record the edition, plan, hosting type, target version, the date each support window closes, the next mandatory upgrade date, and Odoo's written confirmation about l10n_fr_pdp availability. Ask Odoo to confirm, for your specific edition and plan, what is included in the approved platform feature and what it costs to run. Then set a test calendar that includes an upgrade rehearsal on a neutralized copy of production. If the record shows that the chosen version or edition cannot meet the September 2026 and September 2027 dates on your timetable, change the version or hosting decision now, while the cost of change is still low.
How much does French e-invoicing on Odoo cost and take?
What drives the cost of French e-invoicing on Odoo?
Edition and hosting, company count, point of sale use, format and partner testing, data quality and version upgrades are the main drivers. Edition and plan matter first. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that only Custom includes multi-company, Odoo Studio, external API access and custom modules, so a multi-company group on Custom carries more configuration than a single company on Online. Each additional company needs its own fiscal setup and its own tests. Point of sale adds the anti-fraud certification module and register testing. Factur-X, UBL and CII each need tests with every trading partner that sends or receives them. Inconsistent customer identifiers, duplicate partners and uneven tax setup slow every stage. Ask for a quote that prices each driver on its own line, so you can see which choices move the total.
Which costs are one-time and which recur after go-live?
One-time work covers scoping, configuration, data cleanup, format and partner testing, and staff training. Recurring costs are the Odoo subscription itself, which Odoo's pricing page sets per user per month on Standard or Custom with a yearly discount option, plus hosting, support windows and the upgrades that follow. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years, and each upgrade needs a tested upgraded database before production. Test environments also need upkeep. Any change to formats, trading partners or the l10n_fr_pdp configuration needs regression testing. Ask the quote to separate fixed project work from any monthly or annual retainer, and to state which items are included during the first support period and which are billed later.
How often do we have to upgrade Odoo after go-live?
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years according to Odoo's upgrade documentation, and SaaS versions are released every two to three months. Standard support covers the first three years after a major release. Odoo 19.0 (September 2025) has standard support until September 2028, Odoo 18.0 (October 2024) until September 2027, and Odoo 17.0 standard support ended in September 2026. Security patches are only provided during standard support, and paid extended support is limited to Odoo.sh for select versions and on-premise. On-premise upgrades through Odoo's upgrade service require an Enterprise subscription, and the Community edition has no access to that service. Plan upgrade work into your budget from the start, and confirm which Odoo version your database will run at go-live.
What does our team need to provide for the project?
The work needs named decision makers who can approve scope and sign off results. It also needs input from your tax adviser on how VAT, invoice mentions and e-reporting obligations apply to your sales. Provide representative test data, including sample invoices, customer records with tax identifiers and product lists. You also need contacts at each trading partner, platform and integrator you exchange invoices with, plus an accounting lead who can check results during testing. On-premise or Odoo.sh projects need infrastructure access and agreed change windows. Late data and unreachable partner contacts can stretch test cycles, so agree these responsibilities in the written scope, with an owner and a date for each dependency.
Can our own finance and IT team set up French e-invoicing on Odoo?
A capable internal team can configure the French localization and the l10n_fr_pdp module, because Odoo documents the feature and its activation, but the difficult part is testing and the decisions around it. First, confirm which deadline applies to your company: from September 1, 2026, large and mid-sized enterprises must send and e-report, while from September 1, 2027 the same applies to all companies. Your team then needs time for test cases across Factur-X, UBL and CII, trading partner onboarding, the POS anti-fraud module if you sell at registers, and cleanup of historic data. Estimate internal hours realistically, include backfill for people moved onto the project, and decide early who signs off on tax treatment. Many organizations keep decisions in-house and bring in a partner for configuration and test support.
What should a written quote for this work include?
A useful quote lists scope in terms you can check: each company, the Odoo edition and plan, the hosting type (Online, Odoo.sh or on-premise), the modules in scope such as l10n_fr_pdp and l10n_fr_pos_cert, the formats (Factur-X, UBL and CII), the trading partners to test, the data cleanup volume and the training audience. It should name deliverables, acceptance tests, a timeline with dependencies, and client responsibilities with owners. Ask which items are fixed and which are billed on time and materials, what is excluded, and how change requests are priced. Separate project work from Odoo licences, hosting and any support retainer, because these recur on different schedules. Confirm support windows, upgrade work and test maintenance after go-live. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How much time is left before the French e-invoicing deadline?
The legal dates are fixed. From September 1, 2026, every company must be able to receive domestic B2B e-invoices through approved platforms, and large and mid-sized enterprises must also send them and e-report. From September 1, 2027, the same obligations apply to all companies. Work back from those dates, and plan time for scoping, test cycles with each trading partner, and a period of checks before go-live. The length of the project depends on company count, data quality and partner readiness, so no duration should be assumed in advance. Ask each proposal for a timeline with milestones and dependencies, and check it against your own sign-off calendar. Start scoping early, because partner onboarding depends on people outside your organization.
What does point of sale add to the French e-invoicing project?
Point of sale adds the VAT anti-fraud certification module l10n_fr_pos_cert, which Odoo's France localization documentation ties to CGI 286 I-3 bis. Enabling it changes how register data is handled, so the work includes configuring each point of sale, testing sales, returns and closing procedures, and collecting the records your tax adviser needs to review. Confirm with your adviser and Odoo which evidence applies to your setup. Multiple shops, multiple registers and any non-Odoo till software add testing scope. Ask the quote to list each shop and register and the transaction types it will test. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which come from independent auditors, certification bodies or the authorities.
How DeployOpen scopes and delivers French e-invoicing readiness
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Odoo and the French e-invoicing reform, we start from your invoicing flows, your Odoo edition and hosting type, and the dates your company must meet, then deliver the configuration and handover in a written, fixed scope.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which invoice flows must be received, sent and e-reported, and which sales channels, including point of sale, are in the first phase.
- We confirm your Odoo edition, hosting type and version, because the approved platform module and support windows depend on them.
How we build
- We install and configure the France E-Invoicing (Approved Platform) module l10n_fr_pdp and the French localization modules your flows need.
- We set up supported formats such as Factur-X, UBL and CII, and test them against sample invoices from your real customers and suppliers.
- We configure point-of-sale anti-fraud certification with l10n_fr_pos_cert where your stores use Odoo point of sale, and test on a copy of production.
How we hand over
- You receive written configuration records, test results, data-flow diagrams and runbooks for your finance and IT teams.
- We test every change on a neutralized database copy before production, and document the rollback steps for each change.
- We train the people who will validate invoices, correct rejections and answer questions from auditors or tax advisers.
How we support
- Ongoing support, upgrades and testing are available as a retainer, which covers changes after the initial handover.
- Odoo version and support deadlines are tracked, so an upgrade to a supported release is planned before standard support ends.
- Your tax advisers and auditors remain responsible for compliance decisions. We prepare the systems and evidence they review.
