Odoo Accounting Consultant in Norway

Standard accounts, standard tax codes and the SAF-T file

Norway expects bookkeeping systems to hand over their ledger as a SAF-T financial file whenever the tax authorities ask for it. That file does not invent structure; it exposes the structure already in your ledger. So the SAF-T question in Odoo is really a configuration question: is every account mapped to a standard account code, and every tax tied to a standard tax code?

On a test database with the Norwegian fiscal package installed, I work through:

• Chart of accounts: whether the delivered chart fits, or whether you keep your current Norwegian account plan, and how each account links to its standard code.
• Taxes: each tax used on sales and purchases connected to the right standard code, including imports, reverse charge on services bought from abroad and exempt sales.
• Partners: customers and suppliers with organization numbers and addresses stored consistently, because the file includes master data.
• Export route: whether your Odoo version and edition provide a SAF-T export in the localization or need a module, and who maintains it through upgrades.
• Validation: generating a file for a test period and running it through a validator, fixing mapping errors until it passes.

The same standard tax codes are generally used for the Norwegian VAT return as well, so a clean mapping does double duty. Your accountant confirms which codes apply to which transactions; I make sure Odoo applies them consistently. The overall Odoo decision for Norway is covered on the Odoo consultant Norway page.

KID references, bank files and reconciliation in Odoo

Cash handling in Norway relies heavily on the KID reference. A customer paying an invoice enters the KID from the invoice in their bank, and the receiving bank passes that KID back to the supplier inside a structured payment file. If Odoo generates valid KIDs and reads that file, most customer payments match without human effort.

The design I test covers:

• Reference format: how Odoo generates the payment reference on invoices, whether the Norwegian localization in your version offers a KID option, and whether the length and check digit match your bank agreement.
• Incoming files: how payment and statement data from each bank reach Odoo, whether through bank synchronization, file import or an integration service.
• Reconciliation models: rules that match receipts on KID, book bank charges automatically and propose candidates when a receipt arrives without one.
• Supplier payments: payment batches created in Odoo and sent in a format your bank accepts, usually via a module or a payment provider, carrying the KID or message as the supplier requires.
• Exceptions: part-payments, overpayments and combined payments, with a named owner.

I run each bank account through a complete cycle with real files: invoice issued, payment received, statement imported and invoice closed. Afterwards each route is logged with a named owner and a fallback for when the connection breaks. That register is surprisingly valuable when a bank changes its file service, which happens more often than finance teams expect.

EHF invoices leaving and arriving in Odoo

Public customers in Norway generally insist on EHF documents sent through Peppol, and a growing share of private customers prefer them too. Recent Odoo versions include e-invoicing features, and third-party connectors also exist, so which path applies is a matter of your version and edition. Whichever route you choose, EHF documents are validated on receipt, and invoices with missing data are rejected.

For outgoing invoices I check in Odoo:

• your organization number and VAT registration, plus the customer's organization number
• whatever order or contact reference the public body has asked for
• tax categories per line that match the totals
• the KID and bank account, so payment can be matched later
• credit notes that refer to the original invoice

Incoming EHF invoices deserve equal attention. Suppliers increasingly send them, and receiving them directly into Odoo as draft vendor bills, with the original document attached, removes a lot of typing. I test how they arrive, how the supplier is recognized, how purchase order matching works and how approval is routed before posting.

Before go-live I send a real test invoice and credit note to a public customer and confirm acceptance. That one step avoids the most common launch problem I see with Norwegian e-invoicing: a first billing run that quietly fails validation and delays payment.

Norwegian subsidiaries and intercompany with a Nordic parent

Many Norwegian companies are part of a group with a parent in Sweden, Denmark or further afield. The Norwegian entity must keep a ledger that meets Norwegian rules, while the parent wants monthly figures in the group chart and currency. A single Odoo database can hold multiple legal entities under separate fiscal packages, so both needs can be met if the design is deliberate.

The questions I settle with the local finance lead and group controllers:

• Chart mapping: how Norwegian accounts map to the group chart, kept in Odoo or in the group's reporting tool, without breaking the standard account mapping SAF-T relies on.
• Intercompany trade: whether a sale booked by one entity should generate the mirror purchase in its sister company, which Odoo supports depending on edition and configuration, and which flows stay manual.
• Counterparty accounts: separate intercompany receivable and payable accounts for each related company, agreed monthly.
• Currencies: kroner in Norway, kronor or euros elsewhere, with rate sources and revaluation agreed by both finance teams.
• Management charges: how group services are charged and how VAT on cross-border services is treated, as your advisor directs.

My tests run an intercompany cycle from order to settlement, a corrected invoice and a period close in which both ledgers must show the same balance. The general pattern is described on the multi-company ERP page.

Edition choice, upkeep and Norwegian misfits

For Norwegian accounting, the edition decision has practical consequences. Odoo Community supports invoicing and accounting records, but the full accounting application with its reconciliation tools, financial reports and much of the localization reporting belongs to Enterprise. On Community, SAF-T exports, KID handling and bank formats would rest on community modules, each needing review at every upgrade. Most Norwegian companies with an external accountant are better served by Enterprise, while a company with strong in-house development can weigh Community carefully.

I would not make Odoo the Norwegian ledger when:

• only the finance team would use Odoo, and a dedicated Norwegian accounting system already does the job well
• project accounting with deep work-in-progress handling is the core of the business; a platform such as Business Central in Norway may be stronger
• the SAF-T or KID tests cannot be passed without fragile custom work
• nobody will own modules and upgrades after launch

I have no stake in Odoo or any Norwegian implementer, so the recommendation follows the evidence. My Odoo Accounting page covers the product generally, while the ERP consultant Norway page and the Norway hub describe the wider decision. Work runs remotely in Norwegian business hours.