Norwegian businesses face two obligations that Odoo core does not cover out of the box. When the tax authority (Skatteetaten) requests it during an audit or bookkeeping review, you must be able to hand over a SAF-T Financial file — a strictly-schema'd XML export of your ledger, accounts, customers, suppliers and tax codes mapped to the national standard account set. Separately, to invoice the Norwegian public sector (and increasingly B2B partners), you must send EHF 3.0 documents over the Peppol network rather than PDF. Stock Odoo (account, account_edi, l10n_no) gives you a Norwegian chart of accounts and MVA tax setup, but there is no SAF-T generator, no standard-account cross-mapping, no EHF 3.0 UBL builder, and no KID reference on the payment slip. Teams end up exporting to spreadsheets and re-keying invoices into an Access Point portal by hand.

This is what ECOSIRE builds for you as a made-to-order module. On the SAF-T side we add a generator that walks your account.move / account.move.line data for a selected period and emits the Skatteetaten Audit File - Financial structure: masterfiles (accounts, customers, suppliers, tax table), the general-ledger entries, and the header block carrying your Organisasjonsnummer. Each Odoo account is cross-mapped to the SAF-T standard account (NS 4102-based) via a configurable mapping model, so your own multi-digit chart still exports against the government's standard codes. Every MVA tax in Odoo is mapped to its SAF-T tax code, and we generate the MVA-melding (VAT return) summary figures from the same posted entries. Before anything leaves the system the XML is validated against the official XSD, so you catch structural errors at your desk instead of at the portal.

On the e-invoicing side we implement EHF 3.0 / Peppol BIS Billing 3 as a document type extending account_edi. When you confirm a customer invoice, the module renders Access-Point-ready UBL 2.1 — correct cbc/cac structure, Peppol participant identifiers derived from the validated Organisasjonsnummer, MVA breakdown per rate, and a computed KID (kidnummer) payment reference using the MOD-10 or MOD-11 check-digit scheme your bank uses. The UBL is handed off to your chosen Peppol Access Point for transmission; we do not resell network access, we make Odoo produce a document your provider will accept. We also add inbound EHF: supplier documents you receive are parsed into draft account.move vendor bills for review, so incoming Peppol traffic lands in Odoo instead of an inbox. All of this ships as clean, upgrade-safe code — proper __manifest__.py dependencies, models.Model extensions with @api.depends computes for the KID and MVA fields, ir.model.access.csv plus record rules for who can export SAF-T, XML/OWL views, and a QWeb layout for the KID-bearing invoice. The JSON-RPC/XML-RPC API surface stays intact so your other integrations keep working.

Because it is build-to-order, delivery follows a short, predictable path: a scoping call to confirm your chart of accounts, MVA setup, bank KID scheme and Access Point; a fixed quotation; then we build, validate against the XSD and a real Peppol test corner, run UAT on a staging copy of your database, and deploy with a documented rollback. Typical delivery is one working week from confirmed scope, and we support Odoo 17.0, 18.0 and 19.0 on Community or Enterprise. Pricing starts from $999 (indicative, single-company base scope); additional legal entities, a non-standard chart of accounts requiring deeper standard-account mapping, custom KID rules, or inbound-EHF automation depth increase the quoted scope.