Overview
Electronic invoicing is often treated as a file-format project. Finance teams hear that a country requires UBL, Factur-X, Peppol BIS or another XML standard then assume readiness means configuring Odoo to generate the correct document.
That is only one part of the requirement.
Modern e-invoicing increasingly involves company registration, legal identifiers, recipient-directory checks, government platforms, B2B and B2G routing, invoice-status responses, incoming document processing, e-reporting and country-specific validation rules.
The challenge becomes even greater for international groups. A company operating legal entities in France, Greece, Germany and Belgium cannot assume one e-invoicing configuration will apply to the entire Odoo database.
Odoo 19 fiscal localizations are designed country by country. Odoo specifically notes that each company in a multi-company environment can use a different fiscal localization while branches follow the parent company's localization. Entities operating in different countries should therefore normally be configured as separate companies rather than branches.
Recent Odoo 19 development activity also demonstrates how quickly compliance functionality continues to change. During August 2026 Odoo added or fixed French PDP functionality around multiple-company registration, Chorus Pro, directory lookups, Factur-X imports and e-reporting. Greece's l10n_gr_edi module has also continued receiving development work around myDATA integration and EDI behavior.
For finance teams, Odoo e-invoicing readiness should therefore be treated as an ongoing compliance program rather than a one-time XML configuration.
E-Invoicing Is More Than Generating XML
An electronic invoice is not simply a PDF saved in another format.
A compliant process may require the ERP to identify the legal entity sending the invoice, determine whether the recipient is registered on a network, select the correct document format and route the invoice through an approved platform.
The system may also need to receive invoices, process response statuses, report transaction data to tax authorities and prevent changes after certain documents have already been transmitted.
A complete readiness assessment should therefore cover:
Legal company configuration.
VAT and business registration identifiers.
Fiscal localization modules.
Customer and supplier master data.
E-invoice format.
Network or directory registration.
Approved platform registration.
B2B routing.
B2G routing.
Incoming electronic invoices.
Credit notes and corrections.
E-reporting.
Invoice lifecycle statuses.
Multi-company separation.
Upgrade and regression testing.
Focusing only on the outbound XML file leaves several compliance dependencies untested.
Start With the Legal Entity Structure
The first e-invoicing decision should be organizational rather than technical.
Odoo can manage multiple legal companies in one database. Each company has its own accounting configuration and can use a different fiscal localization. Odoo also allows branches below parent companies but branches inherit the parent's fiscal localization.
This distinction matters for international groups.
Consider a group with:
- France SAS
- Germany GmbH
- Greece SA
If each entity has a separate legal identity and country-specific tax obligations, each should normally operate as its own Odoo company with the correct localization.
A branch structure would be inappropriate if the entities require different country localizations.
| Entity Type | Localization Behavior | E-Invoicing Consideration |
|---|---|---|
| Separate legal company | Can use its own country localization | Suitable for different national requirements |
| Branch | Follows parent localization | Best when legally and fiscally aligned with parent |
| Shared database | Supports multiple companies | Requires company-specific configuration |
| Shared customer/vendor | Possible where appropriate | Legal and e-invoice identifiers still need validation |
Finance teams should therefore review the corporate structure before activating e-invoicing.
Verify the Fiscal Localization for Every Company
Odoo fiscal localization packages do more than install a chart of accounts.
They can configure taxes, tax reports, fiscal positions, legal reports and additional country-specific modules. Some localizations also introduce dedicated electronic invoicing functionality.
Odoo automatically installs core localization components according to the company's country when Accounting is installed. Additional modules may need to be installed manually.
Finance teams should verify for each legal company:
Country.
Localization package.
Chart of accounts.
VAT configuration.
Tax rules.
Company identifiers.
EDI modules.
Government reporting modules.
Required optional localization modules.
Odoo warns that changing the localization package is only possible before accounting entries have been posted.
Incorrect localization selection should therefore be treated as an implementation-level problem rather than something to correct after several months of production accounting.
France Shows Why XML Alone Is Not Enough
France is a useful example because its current reform combines several different compliance layers.
From September 1, 2026, every VAT-registered French company must be capable of receiving domestic B2B electronic invoices through an approved platform. Large enterprises and mid-sized enterprises must also send domestic B2B invoices electronically and submit relevant transaction data through e-reporting.
From September 1, 2027, these sending and e-reporting requirements expand to SMEs and micro-enterprises.
Odoo 19 includes the l10n_fr_pdp module for France's electronic invoicing framework. Odoo states that it is officially certified as a French approved platform and supports receiving Factur-X, UBL and CII documents while outbound invoices through the French network are sent in UBL.
A French readiness project therefore includes much more than selecting UBL.
Register the Company With the French E-Invoicing Network
Before a French company can exchange compliant invoices, the legal entity needs to be registered.
Odoo's current configuration process includes authenticating a legal representative and validating the company's French e-invoicing identity. Once registration is completed, Odoo states that registration in the French electronic invoicing directory becomes effective the following day.
The registration process depends on accurate company information.
Critical data may include:
Legal company name.
SIREN.
SIRET where applicable.
VAT number.
Country.
Legal representative.
Contact email.
Accounting journals.
An ERP database may therefore generate technically valid UBL while still being unable to exchange the invoice because the underlying company identity is incomplete.
This is why e-invoicing readiness should include a legal-master-data audit.
Multi-Company Registration Must Be Tested Separately
The need to register one company does not disappear because several legal entities share the same Odoo database.
This became especially visible in recent Odoo development activity. On August 28, 2026, the Odoo 19 French PDP codebase received an improvement specifically titled “Register multiple companies on same db.”
That is strong practical evidence that multi-company e-invoicing introduces implementation details beyond ordinary invoice generation.
A group with three French legal entities should therefore verify each company independently.
For every entity confirm:
Registration status.
SIREN and SIRET.
VAT identity.
Incoming invoice journal.
E-invoicing identifier.
E-reporting requirement.
User permissions.
Relevant accounting settings.
Do not treat successful registration of Company A as proof that Company B and Company C are compliant.
Verify Customers Against the Directory
French B2B e-invoicing also depends on the recipient.
Odoo 19 allows users to verify whether a French customer is registered on the electronic invoicing network. The customer record must contain the required country and Company ID information before the directory check can succeed.
Recent Odoo code activity again shows why this deserves testing. On August 29 Odoo added a fix to guard French directory lookups through the relevant electronic-address scheme.
Customer master data therefore becomes part of tax compliance.
Finance teams should audit:
Customer legal name.
VAT number.
Company identifier.
Country.
E-invoice address.
Preferred sending method.
B2B/B2C classification.
A missing identifier may prevent electronic routing even when the invoice itself is otherwise correct.
Separate B2B E-Invoicing From E-Reporting
French compliance also demonstrates why not every transaction follows the same route.
Domestic B2B invoices within scope can be exchanged through the electronic invoicing network.
B2C invoices and cross-border B2B invoices are different. Odoo's current French documentation explains that these invoices are not sent through the French e-invoicing network but their transaction information can instead fall under e-reporting requirements.
Odoo automatically submits relevant French e-reporting data periodically and exposes statuses such as Ready, Error, Sent and Completed.
Finance teams therefore need to distinguish:
| Transaction | Main Compliance Channel |
|---|---|
| Domestic French B2B | French e-invoicing network |
| French B2C | E-reporting where applicable |
| Cross-border B2B | E-reporting where applicable |
| French B2G | Chorus Pro / Peppol route |
| Incoming supplier invoice | Approved network / supported import |
One global “Send E-Invoice” policy is not enough.
B2G Invoicing Requires Another Route
Companies invoicing public-sector customers in France need to consider Chorus Pro.
Odoo documents Chorus Pro as the official platform used for French business-to-government invoices. Odoo 19 supports sending these invoices through Peppol with the l10n_fr_facturx_chorus_pro module.
The customer and invoice need additional information such as:
Country.
VAT.
SIRET.
Buyer reference.
Contract reference.
Purchase-order reference.
The company itself also needs the correct SIRET.
Recent Odoo 19 development reinforces the importance of this path. On August 29, 2026, the French PDP module received an explicit B2G / Chorus Pro improvement.
A company serving both commercial businesses and French public organizations should therefore include separate B2B and B2G scenarios in UAT.
Peppol Is a Network Requirement Not Just a Format
Peppol is another area where teams sometimes confuse format with delivery.
Odoo acts as both a Peppol access point and Service Metadata Publisher for supported use cases. Odoo supports registration in many European countries including France and Greece and can send formats such as Peppol BIS Billing 3.0.
Peppol readiness can require:
Company registration.
Supported electronic address.
Recipient availability.
Correct invoice format.
Successful network delivery.
Incoming document handling.
Delivery-status monitoring.
Generating Peppol BIS XML is therefore not proof that the organization can exchange documents successfully on the network.
A proper test should send and receive documents through the complete communication channel.
Incoming E-Invoices Need Their Own Test Plan
Many implementation projects concentrate on customer invoices because outbound billing is highly visible.
Incoming electronic invoices are equally important.
Odoo's EDI framework supports receiving electronic supplier documents through networks such as Peppol where available. France's approved-platform configuration also includes an incoming invoice journal.
Testing should verify what happens when the company receives:
UBL.
CII.
Factur-X.
Credit notes.
Invalid documents.
Duplicate invoices.
Supplier documents with unknown products.
Documents with incorrect VAT information.
Import handling is not theoretical maintenance work. On August 30, 2026, Odoo committed a specific French PDP fix for Factur-X e-invoicing format import.
That fresh change demonstrates why incoming-document regression testing deserves the same attention as outbound invoice generation.
Credit Notes and Corrections Require Testing
Electronic invoicing changes what happens after posting.
In a traditional ERP process, users may reset an invoice to draft, correct it and post it again.
A government-connected e-invoicing process may restrict that behavior after information has already been transmitted.
Odoo's French documentation states that domestic B2B invoices already transmitted through relevant reporting processes can be subject to restrictions around resetting to draft. It also documents correction behavior for invoices already included in e-reporting.
Recent development activity includes work around reset-to-draft behavior and invoice lifecycle handling.
UAT should therefore include:
Incorrect invoice.
Credit note.
Full cancellation.
Partial credit.
Corrected customer information.
Corrected tax information.
Duplicate invoice.
Rejected transmission.
Testing only the perfect invoice creates false confidence.
Greece Shows That Country Localizations Keep Evolving
France is currently receiving intense attention because of its September 2026 reform but it is not the only localization evolving.
Odoo's public Odoo 19 repository includes the Greek l10n_gr_edi module which supports Greek electronic reporting functionality around myDATA.
The module history shows development work around sending classifications to myDATA, moving myDATA configuration into Settings and adjusting preferred classifications. A further UI fix was committed on June 1, 2026.
The important lesson is not one specific Greek field.
It is that localization behavior continues changing even after a major Odoo version has been released.
Finance teams operating internationally should therefore maintain country-level release monitoring rather than assuming that selecting Odoo 19 freezes all compliance behavior for the life of the version.
Company Identity Must Be Treated as Master Data
E-invoicing increases the importance of company identity fields.
The ERP needs to know exactly which legal entity issued or received the document.
Depending on the country, relevant information may include:
VAT number.
Legal registration number.
SIREN.
SIRET.
Peppol identifier.
Electronic address.
Government portal account.
Tax regime.
Registered address.
Company bank information.
Odoo Accounting requires company and branch legal information to be configured individually including VAT numbers where applicable.
These fields should be controlled through finance governance rather than edited informally by general users.
Customer and Supplier Data Need Validation Too
Many e-invoicing failures originate from partner master data rather than accounting logic.
A customer may have the wrong country while a public-sector entity may be missing a buyer reference. Two contacts may share an incorrectly reused VAT number or an old address may no longer match the official directory.
Odoo also warns that multiple contacts sharing the same VAT ID can create incorrect VAT reporting.
Create a master-data checklist covering:
Legal name.
Country.
VAT.
Registration number.
Electronic address.
Fiscal position.
Invoice format.
B2B/B2C/B2G status.
Government references.
Payment information.
E-invoicing should make master-data governance stronger rather than simply automating transmission.
Test E-Invoicing During Every Odoo Upgrade
Localization modules should be treated as high-risk upgrade components.
Odoo's French documentation specifically notes that when upgrading to a version containing additional localization modules some modules may not be installed automatically and may need manual installation.
An upgrade test plan should include:
| Test | Expected Result |
|---|---|
| Localization modules | Correct modules installed |
| Company registration | Identity remains valid |
| Directory lookup | Customer verification succeeds |
| Outbound invoice | Accepted and delivered |
| Incoming invoice | Imported correctly |
| Credit note | Correct reference and transmission |
| B2G invoice | Chorus Pro route succeeds |
| E-reporting | Correct transactions included |
| Multi-company | No cross-company registration errors |
| Permissions | Only authorized users manage compliance |
Do not assume a successful database upgrade means the e-invoicing environment is ready for production.
Monitor Public Code and Official Documentation
For compliance-heavy Odoo deployments, release-note monitoring may not be enough.
Recent public Odoo code changes provide a concrete example. The French PDP module saw multiple commits during August 2026 involving directory behavior, B2G support, multi-company registration, e-reporting views and Factur-X importing.
These changes do not mean finance teams should manually inspect every Git commit.
They do mean organizations should have somebody responsible for monitoring localization changes and translating relevant developments into testing requirements.
Useful monitoring sources include:
Official Odoo documentation.
Odoo release notes.
Localization module changes.
Government guidance.
Peppol requirements.
Tax-authority announcements.
Implementation-partner updates.
Compliance ownership cannot be fully delegated to the ERP software.
Build a Country-by-Country Readiness Matrix
International finance teams should maintain one e-invoicing readiness matrix per legal entity.
A useful structure is:
| Readiness Area | France Entity | Greece Entity | Other EU Entity |
|---|---|---|---|
| Localization verified | Complete | Complete | Review |
| VAT/legal ID verified | Complete | Complete | Complete |
| Network registration | Complete | Applicable | Pending |
| Customer validation | Active | Review | Review |
| B2B tested | Passed | Passed | Pending |
| B2G tested | Passed | N/A | Review |
| Incoming invoice tested | Passed | Passed | Pending |
| Credit-note test | Passed | Review | Pending |
| Upgrade regression | Passed | Passed | Review |
| Responsible owner | Finance FR | Finance GR | Local Finance |
This creates visibility across the group without pretending every country has identical requirements.
How BrowseInfo Can Help With Odoo E-Invoicing Readiness
BrowseInfo can support multi-company Odoo environments where accounting configuration needs to remain aligned with local operational and compliance requirements.
An e-invoicing readiness engagement can include:
Multi-company structure review.
Fiscal localization assessment.
Company-identity validation.
VAT and tax configuration.
E-invoicing module configuration.
Peppol readiness.
Customer and vendor master-data review.
B2B and B2G testing.
Incoming invoice validation.
Credit-note testing.
Localization upgrade testing.
Custom integration review.
User acceptance testing.
Post-go-live support.
The goal should not be to create one generic global invoicing configuration.
The stronger approach establishes common ERP governance with country-specific compliance controls.
Common Odoo E-Invoicing Readiness Mistakes
One common mistake is assuming that generating valid XML means the company is compliant. Network registration, legal identity and recipient availability may still prevent successful transmission.
Another mistake is configuring one entity correctly then assuming every company in the database uses the same localization and identifiers.
Other common problems include:
Missing VAT or registration numbers.
Incorrect company structure.
Unverified customers.
B2G invoices tested as normal B2B invoices.
Incoming invoices ignored during UAT.
Credit notes not tested.
Government statuses not monitored.
Localization modules skipped during upgrades.
No owner for country-specific compliance.
Custom invoice changes not regression tested.
E-invoicing projects should test the full business lifecycle rather than only document generation.
Frequently Asked Questions
1. Does Odoo 19 support electronic invoicing?
Yes. Odoo 19 supports electronic invoicing through its EDI framework and country-specific fiscal localizations. Available formats and government integrations vary by country.
2. Can each Odoo company use a different fiscal localization?
Yes. In a multi-company database each company can use a different fiscal localization. Branches follow their parent company's localization which is why legal entities in different countries should generally be configured as separate companies.
3. What changes in France from September 1, 2026?
From September 1, 2026 every VAT-registered French company must be capable of receiving domestic B2B electronic invoices. Large and mid-sized enterprises must also send applicable B2B invoices electronically and meet applicable e-reporting requirements.
4. Does Odoo support France's approved-platform model?
Yes. Odoo 19 includes the l10n_fr_pdp localization module and Odoo states that it is officially certified as an approved platform for France's electronic invoicing network.
5. Does Odoo support Chorus Pro?
Yes. Odoo supports French B2G invoicing through Chorus Pro using the relevant French localization module and Peppol connection. Customer and invoice references must be configured correctly.
6. Is Peppol only an invoice format?
No. Peppol is an electronic document-exchange network. Successful use requires network registration and routing in addition to generating a supported document format. Odoo can act as a Peppol access point and SMP for supported countries.
7. Why must incoming invoices be tested?
E-invoicing compliance affects both sending and receiving. Different formats, supplier identifiers, duplicates and credit notes can expose issues that are not visible during outbound invoice testing.
8. Should e-invoicing be retested during Odoo upgrades?
Yes. Localization modules, formats, directory services and government integrations continue evolving. E-invoicing should therefore be included in every accounting upgrade and regression-testing plan.
Conclusion
Odoo e-invoicing readiness is not an XML-generation project.
The invoice file is only one layer of a larger compliance process involving legal entity structure, localization packages, company identifiers, customer validation, electronic directories, networks, government platforms, incoming documents, reporting and invoice lifecycle controls.
France demonstrates this clearly.
As of September 1, 2026, every VAT-registered French company must be capable of receiving domestic B2B electronic invoices while larger organizations also enter the mandatory sending and e-reporting phase. Odoo's current French implementation includes approved-platform registration, directory verification, B2B exchange, e-reporting and Chorus Pro support.
The recent Odoo 19 code history is equally important. Multiple August 2026 changes addressed French multi-company registration, B2G support, Factur-X importing and directory behavior while Greek EDI development shows that other national localizations continue evolving as well.
Multi-company organizations therefore need a country-by-country compliance model.
Each legal company should have its localization, VAT identity, network registration, customer data and government-channel configuration reviewed independently. Incoming invoices, corrections and credit notes should be tested just as carefully as standard outbound invoices.
Finally, e-invoicing must become part of upgrade governance.
When localization configuration, legal identity, directory registration, B2B and B2G routing, incoming documents, multi-company separation and regression testing are managed together, Odoo can support electronic invoicing as a controlled accounting process rather than simply producing compliant-looking XML files.
That distinction is becoming increasingly important as European e-invoicing moves from optional digital convenience to regulated financial infrastructure.
