ERP Implementation Consultant, Denmark

What goes wrong in Danish implementations

Most of the trouble in Danish ERP projects comes from small decisions made without the right people present. These are the patterns I plan around from the start:

• Apps pile up quietly. Bank connections, e-invoicing, expense handling and reports each arrive as a separate app. Each is reasonable alone, but together they add running cost, update risk and support questions nobody priced.
• The accountant is consulted at the end. VAT codes, account structure and period routines get configured without the bookkeeper or auditor, and the first VAT return exposes the mismatch.
• Old vouchers are an afterthought. The project focuses on what moves into the new system and forgets that records from the old one must remain accessible.
• Batch and quality data is simplified. Open batches move without expiry dates or quality status, and quarantined stock becomes saleable by accident.
• Danish document texts arrive untested. Invoice wording, reminders and delivery notes are translated late and never run through UAT.

None of this needs heroic effort to prevent. It needs owners, checkpoints and tests in the plan. The business analyst page for Denmark shows how they are captured as requirements.

Leaving e-conomic, C5 or NAV: what moves and what is archived

The migration plan depends on what you are leaving. A cloud accounting service such as e-conomic or Dinero usually holds a clean ledger, customers, suppliers and attached vouchers, while stock and orders live elsewhere. An older on-premise C5 or NAV system may hold many years of detailed history, heavy customization and data quality problems nobody has looked at for a long time.

Together with your finance lead and accountant I settle what migrates in detail: typically opening balances, open customer and supplier items with payment references, active masters, open orders, stock with batches and locations, and open projects. Closed history usually stays behind in the old system or an export archive, still searchable. That decision must respect how long Danish rules expect records and vouchers to stay available, which your accountant confirms.

For older Microsoft systems there is also the customization question. Every modification in the old system should be listed and given a decision: rebuilt, replaced by standard features or an app, or dropped. Partners sometimes propose recreating everything; often a good share is no longer needed.

After every trial load, finance and operations sign off a reconciliation pack: account balances side by side with the old ledger, receivable and payable ageing that ties to the control accounts, stock and batch status by location, and spot checks of master records. Anything that does not agree is assigned and explained before the next run. My ERP data migration page and the legacy software migration page cover the method.

Overseeing the partner, the apps and the design

Danish Business Central projects, and many Odoo projects too, are assembled from a core product, a localization layer and a set of apps. That makes the partner's design choices as important as the platform itself. I review those choices from the client side before configuration starts.

For each process area I ask the partner for a short design document and walk your process owner through it, in plain language, before sign-off. For each app I record what it does, who publishes and maintains it, how it is licensed, how updates are tested and whether it duplicates something the core already offers. That list becomes part of the risk register and the handover pack, so your internal owner knows exactly what the system depends on.

Between checkpoints I join the sessions that settle design questions, record decisions with their reasons, and put new requests to the sponsor alongside the partner's estimate. Unusual estimates get questioned, and missing requirements get named in writing the same day.

The aim is a project where the business decides and the partner builds, which is what good Danish partners want too. Platform notes are on the Business Central in Denmark and Odoo Accounting in Denmark pages, and the general method on my ERP implementation page.

Cutover: e-invoice receiving, FIK, banks and payroll

A Danish go-live has several local switches that must happen in the right order. Each gets a line in the runbook, an owner and a verification step, and we rehearse wherever the platform permits.

• Period boundary. Choose a cut-off that coincides with the end of a VAT period, after the legacy month is closed, so no return straddles two systems. How balances are trued up afterwards is your accountant's call.
• E-invoice receiving. Incoming electronic invoices from suppliers and public bodies follow your registered endpoint, usually tied to your CVR or location number. Moving it from the old provider needs a planned date so invoices do not stall in between.
• FIK codes and banks. Invoices from the new system must carry payment codes your bank recognizes, and the bank must deliver statements and payment files to the new system. Any bank agreement changes are arranged ahead of the switch.
• Payroll journal. The payroll provider keeps running pay and reporting. The salary posting file it produces must land on the right accounts and departments, which we prove with a genuine pay run.
• Stock and batches. A count, batch status and quarantine flags are confirmed at the cut-off point.

Rules and formats change, so confirm current requirements with your bank, provider and advisor. For the general go-live playbook, see ERP go-live support.

Role-based testing, Danish material and the first weeks

I organize Danish UAT around roles rather than modules. An order handler tests a webshop order, a backorder and a return. A buyer tests a purchase with a price difference. A quality approver releases and blocks batches. A bookkeeper receives an e-invoice, matches an FIK payment, posts the payroll journal and prepares the VAT figures for the accountant to check. Each person signs off the scenarios they will own after go-live, which builds confidence as well as evidence. Findings go to a joint triage with the partner, which separates genuine faults from design gaps, training points and new wishes.

The engagement runs in English. Danish guides, quick reference cards and training for staff who prefer Danish are produced by your key users or by a local partner, often in a train-the-trainer format: key users learn the system in depth during UAT and then teach their colleagues. I review the material for process accuracy and make sure Danish invoice and letter texts pass through testing.

Once live, one issue list and a quick check-in each morning carry the team through to the first VAT period and month-end, after which an internal owner takes over with the documentation, the app register and a list of improvements for later. More on test design sits under ERP testing and UAT. Companies still comparing platforms can begin with ERP selection for Danish companies or the Denmark overview. The work is remote throughout, with on-site time only by arrangement.