Odoo PA: Time to Deploy

Our previous article of April 27 announced Odoo's final approval as an Approved Platform (PA) by the DGFiP. The strategic debate “Odoo or an external PDP” is settled. Now come the concrete questions asked by finance, accounting, sales administration, and IT teams: how will it work for us? Which workflows? Which settings? Which gaps compared with our current processes? Odoo France's email of May 18 to its integrator partners finally provides the operational material. This article breaks down the architecture, flows, statuses, master data, and the 42 use cases from a field perspective — that of an ERP project manager who has to deliver compliance in September.

1. From “it's approved” to “here is how we implement it”

On April 27, we shared on this blog the news awaited for months: Odoo is no longer registered “subject to conditions”, final approval has been obtained, and interoperability tests with the Public Invoicing Portal have been validated. For finance departments, it was the removal of the last major uncertainty.

Since then, another question has been rising among our customers: how will this actually work in our Odoo database? What changes in day-to-day accounting? What differences in effort depending on our current version? Which master data to clean up first?

The email sent by Odoo France to its integrator partners on May 18 finally provides this operational material. That is the subject of this article: not the compliance strategy (already covered in April), but the deployment mechanics.

2. Functional architecture of the Odoo PA solution

2.1. The role of the Approved Platform

In the French reform, an Approved Platform plays three roles simultaneously:

1. B2B invoice router: it transmits the structured invoices issued by your company to your customers' PAs, via the Peppol network between PAs.
2. E-reporting issuer: it transmits to the tax authorities the transaction data not covered by e-invoicing (B2C, international B2B, cash transactions, payments).
3. Status manager: it receives, updates, and redistributes invoice life cycle statuses (submitted, rejected, refused, paid, etc.).

Odoo chose to integrate these three functions natively in the ERP. No external connector, no third-party PDP to plug in, no per-invoice cost, no separate contract to negotiate. Everything happens in Odoo.

2.2. The flow diagram for B2B France

For an invoice issued from your Odoo to a French business customer:

1. The invoice is generated natively in Odoo (quotation → sales order → invoice, or direct invoicing).
2. Odoo PA automatically converts the invoice to the standard format (Factur-X or UBL).
3. The invoice is routed via Peppol between PAs to the recipient customer's PA.
4. In parallel, the invoice is transmitted to the Public Invoicing Portal (PPF), which keeps the legal archive.
5. Life cycle statuses are fed back into Odoo automatically as they occur.

Operational consequence: the invoice is no longer sent by email. The PDF can still be generated for internal archiving or commercial use, but the legal transmission goes through the platform network.

2.3. The flow diagram for e-reporting

For flows that are not B2B France (B2C, international B2B, payments):

1. Odoo collects the relevant data as invoicing and payments take place.
2. Before each deadline set by the DGFiP, Odoo PA aggregates this data into a structured file.
3. The file is transmitted automatically to the PPF.
4. No manual intervention required within the standard scope.

3. ⚠️ The current “E-invoicing” module: not to be confused

A point of attention we systematically raise with our customers during audits.

In your Odoo database, you currently find a module named “E-invoicing”. Several teams have, in good faith, activated this module and registered their company in the Peppol directories, thinking they were ahead on compliance.

This module is NOT Odoo's future PA module. It is a generic Peppol connector, relevant in European contexts (notably B2G in Belgium or the Netherlands), but it is not intended to meet the French PA requirements.

What to do:

• Do not activate the current module if it is not already active.
• If you have activated it and registered your company in a directory, inform your integrator before the official module is published to avoid technical conflicts at deployment.
• Wait for Odoo's official communication on the availability of the new PA module, which will come in the next few weeks.

4. Supported Odoo versions

An important clarification from Odoo on May 18 compared with our April article: backporting to V17 is now confirmed, whereas it was still under discussion a month ago.

Operational reading for your teams:

• If you are on V16 or earlier: migration is non-negotiable. No workaround is possible.
• If you are on V17: you will be covered, but with a delay in the delivery of fixes and enhancements. An acceptable position in the short term, to be questioned in the medium term.
• If you are on V18 or V19: you are in the right place.

Our Auguria recommendation to all teams on V17 or lower: plan the migration directly to V19, rather than aiming for V18 and having to redo the work in twelve months. A single migration operation, to the current version, is the most economical and least stressful path.

5. Partner master data: the foundation to fix without waiting

This is the workstream most underestimated by project teams, and yet the most fundamental.

E-invoicing relies entirely on reliable identification of partners. Incorrect or missing partner data = an invoice rejected by the PPF or by the recipient PA. With no immediate recourse.

5.1. Mandatory data to fix on the partner record

For each French business customer:

• Nine-digit SIREN that is valid and active (verifiable through the INSEE API integrated in Odoo).
• Fourteen-digit SIRET of the recipient establishment if you invoice a specific establishment.
• Standardized billing address (AFNOR standard), separate from the delivery address if necessary.
• Intra-EU VAT number for European customers outside France.
• Peppol identifier of the customer when their software vendor publishes one.

5.2. Auguria method for auditing master data

We proceed in four steps during our engagements:

1. Extraction of all active partner records over the last 24 months.
2. Cross-checking against the INSEE / VIES databases to identify discrepancies.
3. Detection of duplicates, obsolete records, and missing fields.
4. Cleanup plan: automatable actions (Odoo ORM scripts) versus manual actions (to be assigned to sales administration).

This work has a major impact on sizing. For a base of 1,500 active customers, expect on average 8 to 15 days of work depending on the initial state.

6. Invoice life cycle statuses

The DGFiP requires management of a standardized life cycle. Here are the statuses you will see appear in Odoo after deploying the PA module.

6.1. Mandatory statuses (at a minimum)

• Submitted: the invoice has been correctly received by the recipient PA.
• Rejected: technical rejection (invalid format, unknown identifier, etc.).
• Refused: business refusal by the recipient customer (dispute over the service, commercial disagreement).
• Paid: payment has been made, declared for VAT compliance.

6.2. Optional statuses handled by Odoo

According to Odoo's communication, the vendor will support most optional statuses as standard (made available, taken into account, approved, payment suspended, partial payment, etc.). This is reassuring, as it brings the Odoo model closer to what finance departments already use for internal tracking.

6.3. Impact on internal workflows

A very concrete consequence: your invoice approval workflow must absorb the statuses issued by counterparties.

• A “Refused” status on the customer side must trigger a dispute handling procedure.
• A “Payment suspended” status must alert your collections team.
• A “Paid” status on the supplier side can speed up your automatic reconciliation.

On this point, we recommend a dedicated 2- to 3-day workshop to map your current flows and adapt them to the new incoming statuses. This is typically the kind of engagement where integrator experience saves weeks of trial and error.

7. Operational reading of the 42 use cases published by the State

The State has published a list of 42 use cases that PAs and PDPs can handle. Odoo chose to cover everything its standard solution handles natively and to focus its certified effort on that base. The ability of the integrator ecosystem to extend this base to address sector-specific needs is an architectural question currently being clarified with the vendor (see section 7.4).

7.1. Summary of Odoo coverage

7.2. The 21 cases covered as standard

Multiple orders / multiple deliveries, invoice already paid at issuance, expenses paid by employees (with or without company invoice), lodged card (centrally billed), payments via a marketplace intermediary, debit notes, self-billing, down-payment and final invoices, discount with VAT on receipt or on debits, self-billing individual/business, toll tickets, restaurant bills, single taxable person, VAT already collected, mixed invoices, monthly payments, partial payments, sub-lines and groupings.

If your business falls into general trading, retail, standard services, or classic industry without complex subcontracting, you are covered natively.

7.3. The 7 conditional cases (“If demand”)

These cases will be supported by Odoo if enough customers report them to the vendor. Otherwise, their path joins that of the uncovered cases (see section 7.4).

• Third-party payer known at invoicing (group companies, centralizing bodies)
• Partial coverage by a third party (subsidies, insurance)
• Third party managing payment + supply chain (factoring variant)
• B2B co-contracting (business groupings)
• Order placed by a third party on behalf of the buyer (media agencies, brokers)
• Disbursement invoice (reimbursements outside VAT)
• Gift vouchers and gift cards

If you fall into one of these cases, the path will depend on Odoo's decision: native coverage if the market pushes for it, otherwise the topic shifts to the question of partner extensibility currently under discussion with the vendor (see section 7.4).

7.4. The 14 cases outside the standard scope

Factoring with a determined third-party payer, factor subrogation during the life of the invoice, third-party recipient (property manager, building administrator), transparent intermediary, subcontracting with direct payment (typical of construction), payment intermediary with invoicing mandate, invoicing third party with mandate, deposits, contractual reservation clauses, profit margin scheme, author's notes, professional secrecy, joint ventures, multi-vendor invoices, compensation / netting, barter companies, tax-free sales.

On these cases, a precise technical question determines what comes next. It is not about access to the PA itself — it is clear that the Odoo PA will be reserved for Odoo applications, which is consistent with an integrated ERP vendor — but about the functional content of the Odoo module that connects to the PA:

Will the Odoo PA implement, in its official module, all the structured fields needed for the French extensions EXT-FR-FE- (PAYER for construction subcontracting, ADDRESSED TO for property managers, factor BENEFICIARY for factoring, etc.), or only those strictly necessary for the 21 cases covered as standard?*

Two possible scenarios based on this answer:

• Scenario 1 — The PA implements all Factur-X / EXT-FR-FE-* fields. Integrator partners such as Auguria can then extend the Odoo modules upstream (through classic Odoo inheritance) to use these fields already available in the PA and address the cases not covered as standard. Compliance is then achievable through partner development, with no dependence on Odoo's roadmap.
• Scenario 2 — The PA implements only the fields of the 21 standard cases. In this configuration, an extension module cannot generate in the XML the fields missing for the other 14 cases — the PA would not know how to process them. The compliance path of these customers then depends entirely on Odoo's decision to evolve its PA to include these additional fields.

Technically, the Factur-X EXTENDED-CTC-FR profile defined by FNFE-MPE exists precisely to carry all the necessary fields. The AFNOR standard XP Z12-013 published in May 2025 also standardizes the exchange APIs between enterprise systems and approved platforms.

We have formally asked Odoo this question. The answer expected at the Odoo Insider on June 4 directly determines the compliance path we will be able to offer customers in these sectors (construction with subcontracting, travel agencies, second-hand trading, mid-sized companies using factoring). Auguria will publish Odoo's position right afterward, with the concrete operational implications for each profile concerned.

7.5. Recommendation by sector profile

For the profiles in the last two groups, mapping your use cases is work to start immediately, regardless of the technical decision under way. The sooner you have the precise, quantified list of your at-risk cases, the faster you will be able to decide between the options that arise.

8. The Auguria method for deploying the PA at our customers

Here, in methodological form, is how we sequence a PA compliance project at an SME or mid-sized customer.

Phase 1 — Strategic scoping

• Mapping of your flows against the 42 use cases.
• Assessment of your current Odoo version and recommended migration path.
• Identification of the necessary custom developments, with estimates.
• Overall plan with macro-planning and budget.

Phase 2 — Audit and fixing of master data

• Extraction and analysis of partner records.
• INSEE / VIES cross-checking.
• Cleanup and deduplication plan.
• Setting up quality controls in Odoo.

Phase 3 — Odoo migration if necessary (varies depending on source version)

• Migration directly to V19, rather than via V18.
• Data migration, functional acceptance, team training.
• Switch to production.

Phase 4 — PA module deployment

• Activation of the official Odoo PA module as soon as it is published.
• Registration in the DGFiP directories.
• Configuration of approval workflows to integrate incoming statuses.
• Issuing and receiving tests in a pilot environment.

Phase 5 — Change management and training

• Training of accounting, sales administration, and purchasing teams.
• Update of internal procedures.
• 30-day post-go-live follow-up.

Average total for a standard SME project: 20 to 40 days of work, spread over 3 to 6 months depending on your starting version and the complexity of your business.

9. The last-minute trap

September 2026 is the deadline for the receiving obligation for all VAT-registered companies, and for the issuing obligation for large companies and mid-sized companies. It is May 2026. You have four months left.

On a project of 20 to 40 days, spread over 3 to 6 months, the useful start window closes at the end of June. Beyond that, the operation will be tight, even impossible to carry out under normal conditions.

Our advice: do not procrastinate. A 2-day scoping started now costs you little, but gives you clear visibility on your situation, your workload, and your budget. From there, you can make an informed decision.

10. How Auguria supports you

Auguria, a member of the ANOR group, supports French SMEs and mid-sized companies across their entire Odoo life cycle: strategic scoping, integration, migration, training, support. For the specific topic of e-invoicing, we offer three dedicated services.

PA Compliance Audit (fixed price)

A quick 2- to 5-day scoping to give you complete visibility on:

• Your current situation against the 42 use cases
• The state of your partner master data
• The recommended migration path
• The overall budget and compliance schedule

PA compliance project (on quote)

The complete package to go from your current situation to operational PA compliance: migration if necessary, master data fixing, deployment of the official module, workflow configuration, team training.

Post-go-live support

Once the PA module is deployed, we stay by your side for adjustments, regulatory changes, workflow optimization, and training of new team members.

11. In conclusion

Odoo's final approval in April settled the strategic question. Odoo France's email of May 18 now provides the operational material that was missing to move to execution for the vast majority of businesses.

Let us again commend the quality of the work done by the Odoo France teams: obtaining a PA certification, on time, with a broad functional scope covering Odoo Online, Odoo.sh, private hosting, and Community, is a remarkable industrial achievement. It is also excellent news for the technological sovereignty of French SMEs and mid-sized companies: free software becomes a player in regulatory compliance, and it demonstrates that the open-source ecosystem is mature enough to carry the critical challenges of our economic fabric.

For businesses outside the standard base (construction, travel, second-hand, factoring, regulated professions), the question of the extensibility of the Odoo PA module by integrator partners remains to be clarified with the vendor. We have formally asked this question to Odoo France, and we will publish its answer the day after the Odoo Insider of June 4. Until then, mapping your use cases is work you can start right now: it will give you the material to decide quickly, whatever technical path emerges.

For you, as a business owner, CFO, ERP manager, or project manager, the window for action is clear: between now and September. And more precisely, between now and the end of June to start a project under calm conditions.

If you want to start a dialogue about your specific situation, let's schedule a meeting. The first conversation is free, without commitment, and decision-oriented.