Belgium's move to mandatory structured B2B e-invoicing changes what "sending an invoice" means. A PDF attached to an email is no longer an invoice in the eyes of the process — the legally meaningful document is a structured XML file, validated against Peppol BIS Billing 3.0 rules, transported through a certified access point to your customer's receiving corner, with a transport-level acknowledgement you can produce months later. The finance team's pain is not the format itself; it is that the format is unforgiving. A missing enterprise number, a VAT category code that does not match the tax you actually charged, a unit of measure Odoo stores as "Units" and the schema expects as C62 — any one of these turns a posted invoice into a rejected transmission that nobody notices until the customer chases the payment.

Odoo native gets you partway. account_edi and the UBL/EDI framework in 17.0 and later can produce a UBL document, and Odoo Enterprise ships its own e-invoicing plumbing, but there is a real gap between "Odoo can emit UBL" and "our Belgian entity is compliant". The gap is in your data and your process: the Belgian legal-form and enterprise-number fields on res.partner, the mapping from your specific account.tax records to the correct VAT category and exemption reason codes, what happens when a customer's Peppol participant identifier is unregistered, who is told when a transmission is rejected three hours after posting, and how a credit note is linked back to the original document so the correction is machine-readable rather than a note in the chatter.

What we build is a Belgium-specific compliance layer that sits on top of account.move rather than replacing it. Concretely: an inherited account.move carrying transmission state, the Peppol document identifier, the access-point message id and the returned status, all computed and stored so they are searchable and reportable; a res.partner extension for participant identification (typically 0208 enterprise number for Belgian counterparties) with a lookup against the access point's directory so you learn a customer is unreachable before you post, not after; a configurable mapping layer from your account.tax master data to VAT category codes and exemption reasons, kept as data records so your accountant can amend it without a developer; and a QWeb report so the same posting produces both the machine document and the human-readable PDF your customer's AP clerk still wants to look at, generated from one source of truth so the two can never disagree. Transmission runs through a queued, retry-aware outbound job driven by an automated action or a scheduled ir.cron, so a slow access point never blocks the invoicing user. Rejections come back into a correction workflow: the invoice is flagged, the specific BIS rule that failed is stored in readable form on the record, the responsible user is notified via the standard mail thread, and the corrected document is re-sent or credited with the original reference preserved. Access-point credentials live in system parameters and are exposed only to an accounting-manager group via ir.model.access.csv and record rules, and every sent payload plus every acknowledgement is archived as an immutable attachment with a timestamped audit trail you can hand to an auditor.

Everything is built against the Odoo release you actually run — 17.0, 18.0 or 19.0 — with the __manifest__.py pinned to that series and dependencies declared honestly, including whether the work sits on Community or leans on Enterprise accounting features you already licence. Views are extended, never replaced, so an existing customisation on the invoice form survives the install. Where you need to drive the flow from outside Odoo — a treasury tool, a portal, a middleware layer — the transmission and status models are exposed through the standard XML-RPC/JSON-RPC API rather than through a private hook.

This is a build-to-order product, not a download. It starts with a scoping call where we look at your chart of accounts, your tax records, your customer master data and your access-point arrangement, and we agree in writing what "done" means. From confirmed scope, typical delivery is one working week. You get the module installed on a staging database first, a UAT pass against real historical invoices, then a scheduled go-live with a rollback plan, followed by a post-go-live support window while the first real cycles run. The source code and its git repository are handed over to you at the end — there is no lock-in and no obfuscated build.