Odoo Peppol e-invoicing

Before a buyer can send or receive e-invoices through Peppol from Odoo, three parts have to line up: the identifier each legal entity uses on the network, the document format the invoice is written in, and the access point that carries the document between the two trading partners. Keeping these separate in your head makes the rest of the project easier to scope, because each one has its own owner, its own registration steps and its own failure modes.

The participant identifier. Each legal entity that sends or receives documents needs a participant identifier in the Peppol network. Your organization, not DeployOpen or Odoo, has to establish which legal entities need one, which company records in Odoo will carry it, and who holds the registration. Multi-company databases add a question: each company that issues or receives invoices may need its own identifier, so confirm the mapping before configuring company records. The exact registration route depends on your country and on the provider you choose, so confirm each step with Odoo and with the national Peppol authority or the provider you plan to use.

The document formats. BIS Billing 3.0 is the Peppol business interoperability specification for invoices and credit notes that most Peppol participants exchange. XRechnung is the German national CIUS, which is used for invoices to German public sector buyers and is built on the same underlying semantic model. Your trading partners and their country determine which format a given document must follow. Ask each customer group and public buyer which format they accept, and confirm with Odoo which format and localization each of your companies will generate and receive, because a sender cannot assume the receiver accepts the other format.

The access point. A Peppol access point is the service that takes a document from the sender's system, looks up the receiver's identifier in the network directory, and delivers the document to the receiver's access point in the required format. Odoo connects to the network through an access point provider, so the arrangement you make with that provider determines transmission, acknowledgements and support hours. Ask the provider which identifier schemes they support, how they handle receiving and sending in your country, what message status information they return to Odoo, and what their onboarding requires from your side. Those answers, together with written confirmation from Odoo on the supported setup, should drive your build plan.

The format you must send depends on where the seller and buyer are, what kind of customer receives the invoice, and what the buyer's public sector or large corporate procurement rules require. Before you configure anything in Odoo, confirm the format per country and per customer type, not once for the whole company. A German public sector buyer may need XRechnung, while a commercial customer in another Peppol country may accept BIS Billing 3.0 through the network. The same seller can therefore need more than one format, and the mapping should be written down as a decision table that finance, tax and the platform team all sign off.

Start with the questions you take to your tax advisor and the national authority or Peppol authority for each country where you sell or buy. Ask whether e-invoicing is mandatory for B2B or only for public sector buyers, which format and syntax are accepted, whether Peppol is the permitted delivery channel, and what applies to cross-border invoices where the buyer sits in another country. Ask how long you must archive the structured file and the rendered PDF, and whether the buyer's identifier must be a specific scheme. Do not rely on a list of eligible countries from memory. Check Odoo's current list of supported Peppol countries and the Peppol authority list for your country, and record the date and version you checked.

Next, confirm that the Odoo localization for each country supports the format and the invoice types you need. Ask the Odoo partner or your own Odoo administrator to show which e-invoicing modules are installed for each fiscal localization, which document types they generate (customer invoices, credit notes, and any corrective or self-billing documents), and which fields are mandatory in the output. Check how tax rates, exemption reasons, unit codes and payment means are mapped, and whether the vendor bill import accepts the same formats you send. Where a localization does not cover a case, decide whether the gap is filled by a custom module, a manual process or a documented exclusion, and check whether that choice is safe to maintain across upgrades.

Test with real-format sample invoices before any production send. Build a set of illustrative cases that represent each country, customer type and tax situation: a domestic B2B invoice, a credit note, a cross-border invoice with reverse charge, a public sector invoice that needs a buyer reference, and an invoice with multiple tax rates. Validate each generated file against the official schematron rules for the format you selected, and send them to a test access point or the test environment of your Peppol provider. Keep the validation reports as evidence. Confirm that rejected messages reach a named person in operations, and that a resend does not create a duplicate invoice in the ledger. Repeat the tests after each Odoo upgrade and after any change to a localization or custom module.

Self-hosting changes the network path first. On Odoo Online or Odoo.sh, the platform operator manages the connections a Peppol integration depends on. In your own cloud, data center or on-premise network, your firewall, proxy and DNS team must allow the Odoo servers to reach the Peppol access point and any country service the invoice flow calls. Ask your access point provider for the exact hostnames, ports and any requirement for fixed outbound addresses or client certificates, then test from the same network zone and service account that runs Odoo, not from a workstation. Also confirm where each country service stores data and who can reach it remotely. The EDPB's guidelines treat remote access from a third country, even only displaying data for support, as a transfer, so this is a data protection question as well as a connectivity one.

Certificates, credentials and secrets are the second group to plan. A Peppol setup usually depends on access point credentials, signing certificates and the database and mail passwords that the server uses. Confirm with Odoo and the module documentation where each secret is stored, which processes and administrators can read it, and how rotation is performed without a service outage. Keep these values out of shared repositories, chat threads and test copies, and record an owner and expiry date for every certificate. Store them in your organization's approved secret management service, and make sure the platform team can restore them during a disaster recovery exercise.

Backups must include the e-invoice documents, not only the database. Confirm which models, attachments and filestore paths hold sent and received invoices, the XML files and the transmission status records, and make sure your backup job captures all of them. Then perform a restore into an isolated environment and check that a received vendor bill and a sent invoice are both intact. Retention periods for these records are set by your tax and records rules, so confirm them with your tax adviser. For test copies, Odoo documents database duplication with neutralization. Verify that neutralization stops the module from transmitting to Peppol, so a copy of production never sends real invoices from a test environment.

The version lifecycle sets the schedule for all of this work. Odoo's standard support covers three years after a major release, and security patches are provided only during that window. Odoo 17.0 standard support ended in September 2026, Odoo 18.0 runs until September 2027, Odoo 19.0 until September 2028 and Odoo 20.0 until September 2029. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so a Peppol integration must be tested again on each upgrade. On-premise upgrades require an Enterprise subscription, and the Community edition has no access to the upgrade service. Build each upgrade around the upgraded test database, rerun send and receive tests with a neutralized copy, and confirm with Odoo whether the Peppol module's upgrade path changes its data models or access point configuration.