ERP Implementation Consultant, Norway

Where Norwegian implementations run into trouble

Problems in Norwegian rollouts tend to repeat. None is exotic, which is why they are worth planning for from the first week.

• SAF-T mapping arrives late. Accounts and VAT codes get designed for daily posting, and nobody checks the mapping to the standard codes until a file is needed. Fixing it then means reworking posting setup.
• Open jobs are underestimated. Unfinished projects carry costs, hours, purchase orders and billing plans. Moving only their balances leaves project managers without the detail they need to finish them.
• KID payments stop matching. The new invoice layout or reference format does not match what the bank expects, and receipts pile up unallocated in the first weeks.
• EHF receiving is forgotten. Outbound invoices to public buyers get tested, but supplier invoices keep flowing to the old system.
• Payroll is outside the project. The payroll provider keeps running salary and employer reporting, but the journal into the new ERP arrives in the wrong structure.

Each of these gets an owner and a test in my plan. How those needs are documented up front is covered in my Norwegian business analyst work, and platform-specific notes sit on the Business Central in Norway page.

Working alongside the Norwegian partner

My aim is a faster project, not a slower one. Partners deliver better when the client side makes clear decisions on time, and that is mostly what I organize.

Before configuration starts, I walk through the signed scope with the partner's project manager and agree a short list of checkpoints: design sign-off per process area, a SAF-T test export, each migration trial load, UAT entry and exit, and the go-live decision. At each checkpoint the business sees evidence, not a status color.

Between checkpoints, I sit in on the partner's design discussions, note every choice and why it was made, and send any new request to the sponsor with the partner's estimate attached, for a yes, a no or a later. Estimates that look odd get a request for their assumptions, and any requirement that slips out of scope unannounced is raised in writing.

Localization deserves its own attention. Norwegian features may come from the platform vendor, a third-party app or the partner's own extension. I confirm which applies to SAF-T, EHF and bank files, who maintains each piece and whether your support agreement covers updates. Those answers go into the risk register and the handover pack. My ERP implementation service outlines the general approach.

Moving data out of Tripletex, PowerOffice and Visma

Norwegian companies typically move off Tripletex, PowerOffice or one of the Visma accounting products, or an older on-premise system with years of history. Each can export the general ledger, and many can produce a SAF-T file. That file is a valuable cross-check, because it lets you compare balances and transactions from the old system with what landed in the new one, account by account.

The ledger is only part of the job. Open customer and supplier items with their KID or invoice references, customer and supplier masters with organization numbers, item and price data, open sales and purchase orders, open projects and time not yet billed all need their own extracts and templates. I agree with your finance manager and accountant what moves in detail, what moves as a summary and what remains viewable in the legacy system or an archive.

Each trial load is then tested against the source: the ledger compared account by account, customer and supplier ageing compared with their control accounts, stock compared by location and value, open job totals compared with the old project report, and sampled master records compared with the originals. Differences are logged with an owner and fixed before the next load.

Accounting records from the old system must remain available for the period Norwegian rules require, so your accountant signs off the archive approach. The method in more depth is under ERP data migration.

Cutover: VAT terms, EHF registration and payroll

A Norwegian cutover has a handful of local moving parts. I put each one in the runbook with an owner, a date and a check.

• VAT term boundary. Switching at the end of a VAT term, once the old system's month is closed, means each return comes from a single source. Your accountant confirms the approach.
• EHF receiving. Incoming electronic invoices are routed by your registration on the Peppol network, which normally points to one access point. Moving it needs a planned date, and suppliers who email PDFs should be told where to send them.
• KID and bank files. Your bank has to route statements and incoming payment files to the new system, and any agreement covering KID payments may need updating before the first invoice goes out.
• Payroll provider handoff. Salary processing and employer reporting stay with the provider. We map the salary journal they send to the new accounts, departments and projects, and post one from an actual pay run during testing.
• Open jobs and equipment. Hours, costs and rental items still in progress get a clear cut-off so nothing is billed twice or not at all.

Requirements change, so confirm current e-invoicing and bank details with your providers and advisors. ERP go-live support explains the rest of the cutover approach.

Acceptance testing, Norwegian guides and the first weeks live

UAT is where your own people decide whether the system works for them. I write the scenarios with process owners and run them with the staff who will use the system daily: a job from offer to final invoice with a change order, an EHF invoice sent and a supplier invoice received, a KID payment matched from a bank file, an EU shipment with customs data, a payroll journal posted and a SAF-T file exported and reviewed by the accountant. Each finding is reviewed with the partner and sorted into faults to fix, design gaps, training points or ideas for later.

The engagement runs in English. Guides and training for staff who prefer Norwegian, such as warehouse teams, field crews and service technicians, come from your own key users or a local partner. People who tested the system know where colleagues will stumble, which makes their material more useful than a translated manual. I review it for process accuracy.

After go-live I hold a short daily call on a shared issue log until the first VAT term and month-end close are complete, then hand the system to its internal owner along with documentation and a wish list for the next phase. The ERP testing and UAT service sets out the test method. Before any of this, the platform has to be chosen, which is where ERP selection in Norway comes in; the Norway overview has the wider picture. I deliver remotely and visit only by arrangement.