Native Odoo Peppol support gets a single-company, happy-path setup onto the network quickly, but it runs out of road once you invoice across multiple legal entities, route to more than one access point, or need to trade documents beyond the standard invoice/credit-note profiles. Finance teams hit real friction: one endpoint identifier per company, no pre-send validation that the receiver's participant ID is actually registered on the network, limited visibility when a transmission is queued, rejected, or acknowledged, and no clean way to map different customer segments or country profiles to different sending routes. The result is failed submissions discovered days later, manual re-keying into a supplier portal, and compliance risk during e-invoicing mandate rollouts.

This is a made-to-order enhancement — not an existing download. ECOSIRE builds a dedicated module that layers multi-endpoint capability on top of the native account.move e-invoicing flow. Technically, we introduce a configurable endpoint registry (a new models.Model holding access-point credentials, sending profile, and routing rules) linked to res.company and res.partner, so each entity or customer segment resolves to the correct participant identifier and transmission route. A @api.depends-driven compute layer derives the effective Peppol endpoint scheme (e.g. GLN, VAT, org-number) per document, and an outbound service call — via the network access point over the XML-RPC/JSON-RPC-exposed helpers or a REST bridge — validates the receiver's registration in the participant directory before the document is ever built. We generate the UBL/BIS payload, stamp the routing metadata, and record every state transition (queued, sent, acknowledged, rejected, MLR/MDN received) against the source move so accountants see the real network status inside Odoo, not in a separate tool.

The build is grounded in standard Odoo engineering practice: a clean __manifest__.py declaring dependencies on the accounting/EDI stack, models with proper field typing and constraints, access control through ir.model.access.csv plus record rules so multi-company data stays isolated, backend views in XML/OWL for the endpoint configuration and a transmission log, QWeb additions where the printed/emailed document needs the routing reference, and automated actions or scheduled jobs to retry transient failures and poll for acknowledgements. We respect Community versus Enterprise boundaries — where the enhancement depends on Enterprise EDI internals we build against those interfaces; where you run Community we implement the equivalent generation path so the feature set is honest to your edition. Everything targets Odoo 17.0, 18.0, or 19.0, matched to your running version.

Delivery is build-to-order. It starts with a short scoping call to confirm your entities, target endpoints, document profiles, and edition, after which we issue a fixed written quotation. Typical delivery is 2–4 weeks from confirmed scope, including UAT on a staging copy of your database and a rollback plan before anything touches production. Pricing starts from $249 (indicative, single-company base scope); additional legal entities, extra access-point integrations, country-specific Peppol profile depth, and historical document migration volume increase the quoted scope.