Odoo Accounting Consultant in Denmark

Odoo and the Danish digital bookkeeping requirements

Danish bookkeeping legislation now places expectations on the digital systems businesses use. In general terms these cover keeping vouchers digitally, securing and backing up data, logging changes so entries remain traceable, handling e-invoices and, in some cases, being able to export bookkeeping data in a standard format. Certain standard systems are registered as meeting the requirements, while businesses using other systems may need to ensure compliance themselves. Exactly which obligations apply to your company is for your accountant or auditor to determine.

For Odoo, the answer can differ by edition and by where it runs, so I put these questions to the vendor and your advisors and test what can be tested:

• Registration: does the Odoo offering you plan to use, online, on Odoo.sh or self-hosted, have a registered status in Denmark, or would the assessment fall to you?
• Vouchers: are source documents attached to every posted invoice, bill and expense, and kept for as long as required?
• Change trail: does your version log changes to posted entries, and are lock dates used to protect closed periods?
• Backup and access: who backs up the database and documents, where are they stored and how is restoration proven?
• Data export: can the setup produce any standard export your advisor says you need, through the Danish package or a module?

Self-hosting shifts most of these duties to you, which is why I raise them before the hosting decision. The broader platform view sits on the Odoo consultant Denmark page.

Danish VAT, EU sales and the fiscal package in practice

Odoo's Danish fiscal package typically installs a Danish chart of accounts, VAT rates and a VAT report built from tax grids. Many Danish companies trade heavily with Germany, Sweden and the rest of the EU, so the configuration has to handle more than domestic sales, and the package's content changes between versions.

On a test database I set up and verify:

• Domestic VAT: sales and purchase taxes with their grids, including non-deductible or partly deductible cases your accountant identifies.
• EU trade: fiscal positions for EU business customers and suppliers, so goods and services are reported in the right boxes and in the EU sales listing your accountant files.
• Distance sales to consumers: where you sell online to private customers in other EU countries, how Odoo applies destination country VAT and supports the reporting your advisor chooses.
• Imports and reverse charge: purchases of goods from outside the EU and services from abroad, posted so input and output VAT both appear correctly.
• Chart alignment: whether you keep your current Danish account plan or adopt the delivered one, and how history maps across.

I post sample transactions for each scenario and compare the VAT report with your accountant's expected figures. Differences are traced to a tax, a grid or a fiscal position and corrected before go-live. The treatment itself always comes from your advisor; my role is making Odoo apply it consistently. Lock dates are then set so a reported period cannot change silently afterwards.

FIK payment codes, Danish banks and reconciliation

Danish customers often pay invoices using a FIK-style payment code printed on the invoice. The code bundles a type indicator, a reference and the supplier's creditor identifier, and the bank reports incoming payments with that reference, so they can be matched without guesswork. For a Danish company running finance in Odoo, getting this right removes much of the daily reconciliation effort.

The points I check:

• Code generation: whether your Odoo version and the Danish package can produce a valid payment code per invoice, or whether a module or custom field is needed, and whether it validates against your bank's rules.
• Invoice output: the code shown on the PDF and placed in the right element of the electronic invoice.
• Statement import: how statements reach Odoo from each bank, through synchronization, file import or an integration provider, with the reference preserved.
• Reconciliation models: rules that match on the reference, post bank fees and card settlement charges to the right accounts and handle payments that cover several invoices.
• Outgoing payments: supplier payment batches exported in a format the bank accepts, including payment codes from supplier invoices, or approved in Odoo and released in online banking.

Card and payment service payouts deserve their own models, since a single deposit often covers many sales minus fees. I test every bank account and payout source with real files and record the route, its owner and the fallback in a short register.

OIOUBL, Peppol and location numbers in Odoo

Danish public institutions receive invoices electronically, either through the national exchange infrastructure or the Peppol network, in formats such as the Danish OIOUBL standard or Peppol formats. Each receiving unit has its own location number, commonly called an EAN number, and invoices without the right one, or without the reference the buyer requires, are rejected. Newer Odoo releases ship with electronic invoicing features, and outside connectors are available as well; which one suits you follows from the release and edition you run.

In Odoo I configure and test:

• location numbers stored on the correct customer contact or department, since one municipality has many receiving units
• the buyer's order or contact reference captured from the sales order onto the invoice
• CVR and VAT numbers, tax categories and totals that pass validation
• payment codes and bank details inside the electronic document
• credit notes linked to the invoice they correct

Receiving is as important as sending. The Danish bookkeeping requirements touch on the ability to handle incoming e-invoices, and suppliers increasingly send them. I test how incoming documents become draft vendor bills with the original attached, how suppliers and purchase orders are matched and who signs off each bill before it is posted. Before the first live billing run, I send an invoice and a credit note to a real public location number and confirm both are accepted.

Danish groups, intercompany and the edition decision

Danish companies frequently own subsidiaries in Sweden, Norway or Germany. Odoo lets all of them share a database while every entity keeps a separate fiscal package, account plan and currency. The finance design must then answer questions the software leaves open:

• which intercompany sales should generate the mirror purchase automatically, a feature that depends on edition and configuration
• which receivable and payable accounts each pair of companies uses, and how balances are agreed every month
• how prices between entities are set, as your advisors direct
• how kroner, kronor and euro figures are revalued and consolidated for group reporting, inside Odoo or in a separate tool
• which users see which companies

I test a full cycle with a correction and a joint month-end. The multi-company ERP page explains the approach in general.

The edition choice is especially consequential for Danish accounting. The complete accounting application sits in Enterprise; Community users would depend on community modules for reconciliation, reporting, payment codes and e-invoicing, which also complicates the bookkeeping assessment. Where an outside accountant reviews the books, Enterprise is normally the safer foundation for a Danish company. Where Odoo is not the right ledger at all, for example in finance-heavy groups that may suit Business Central in Denmark, I say so. No commercial link to Odoo or to Danish implementers shapes that advice. See my Odoo Accounting page, my ERP consultant Denmark overview and the Denmark hub. All delivery is remote.