ERP Rescue Consultant, Norway

Three Norwegian situations that call for a rescue

Troubled projects are not all the same, and the first useful step is recognizing which kind you have. For Norwegian companies, three broad situations are worth telling apart, each with a different starting point.

Stalled before go-live. The budget is largely spent, testing keeps revealing gaps and the partner proposes another phase of change requests. Here the questions are what remains to be done for a safe first go-live and whether the original scope is still realistic.

Live, but project control has collapsed. The ledger works after a fashion, but hours, rental equipment and subcontractor costs no longer reach the right jobs. Project managers have gone back to spreadsheets, and invoicing on milestones or change orders is late. This is common in offshore, maritime and construction-related businesses, where job accounting carries the whole business model.

A group template that does not fit. A Nordic or international parent rolled out its standard ERP to the Norwegian company, and local essentials such as SAF-T mapping, KID references or EHF were left to be solved later. The subsidiary now carries the cost of those gaps.

Each situation needs a different emphasis, but all of them start with the same thing: a factual, shared picture. The ERP recovery page describes the general method, and this page focuses on how it applies to Norwegian companies.

Triage without taking sides

By the time a rescue is requested, trust between the business and the implementation partner has usually worn thin. Finance believes the partner overpromised, the partner believes the business never made decisions, and both are partly right. A rescue that starts by choosing a side fails quickly.

I start by listening to each party separately: the sponsor, the CFO or finance lead, project managers, key users, your internal project lead and the partner's project manager. Then I check the documents and the system. Did the offer describe what the business thinks it bought? Were requirements for project accounting, SAF-T or EHF written down at all? What does the system do today when a real job is invoiced, a supplier invoice arrives or a payment comes in?

Open tickets are sorted into a simple grid:

That grid and the written fact base go to both management and the partner. The failed ERP implementation page explains how the root causes behind such a list are usually found.

Protecting the VAT return, SAF-T readiness and cash

A rescue must not create a compliance problem on top of a project problem. While the system is unstable, I agree with your finance team and accountant a set of interim routines that keep the essentials safe.

• VAT return. Which VAT codes are known to be wrong, how affected transactions are identified and corrected, and who signs off the figures before filing. Your accountant decides the treatment; I make sure the evidence is ready on time.
• SAF-T readiness. Whether the system could deliver a credible file today, which mappings need correcting and whether the old system's data must be kept accessible for earlier periods. Retention questions go to your accountant.
• Cash collection. Customer payments that failed to match because KID references changed at cutover are cleared from the backlog, and the matching rules are fixed so the list stops growing.
• Supplier invoices. EHF invoices stuck in the access point or rejected for missing references are processed, and the receiving setup is checked so suppliers can reach you.

Each routine has an owner and a review date, and is dropped once the underlying fix is proven. Where payroll postings arrive wrongly from the payroll provider, the interface mapping is corrected rather than journals being patched every month. For the go-live side of stabilization, the go-live support page describes hypercare and the first close.

Repairing open projects, WIP and migrated balances

In Norwegian project businesses, the data that hurts most after a difficult cutover is rarely the customer list. It is the open work: jobs that were half-finished at go-live, with costs to date, committed purchase orders, invoiced milestones and agreed change orders spread across the old and new systems.

I lead a structured reconciliation of that position. For a sample of jobs first, then for all material ones, we compare:

• Contract value and approved change orders in the new system against the signed documents.
• Costs to date against the old system's job ledger and supplier invoices.
• Invoiced to date and retained amounts against the customer ledger.
• Open purchase orders and rental agreements against what suppliers believe is outstanding.
• Work in progress balances against what your accountant carried at the last year-end.

Differences are corrected through documented entries agreed with your accountant, not through quiet adjustments that the next auditor will question. The same discipline applies to opening balances, open customer and supplier items and stock values. Once the position is clean, I check that the dimension rules and mandatory fields that should keep it clean are actually enforced, so the problem does not return. The implementation consultant page for Norway explains how open projects should ideally be planned for at cutover.

Your partner, the contract and the decision ahead

With facts established and finance protected, the conversation with the implementation partner can be constructive. Most rescues continue with the existing partner on a reset baseline: agreed priorities, clear responsibilities, acceptance criteria tied to your testing and a plan with regular checkpoints. I facilitate that reset as a neutral party and stay involved to make sure it holds.

If confidence has gone on both sides, a change of partner is planned as a handover: environments and admin rights moved to your control, license subscriptions held through the partner identified, custom extensions and documentation collected, and open issues written up for the incoming firm.

The contract deserves a careful read either way. Norwegian IT agreements sometimes follow standard templates with appendices for requirements, solution description and pricing. I compare those appendices with what was delivered and list the gaps and ambiguities. Any question of breach, withheld payment, compensation or termination belongs to your lawyer, and I keep my role to the factual record.

Finally, management chooses a direction: continue on the full plan, continue on a narrower first scope, change partner, or in rare cases change platform. I set out each with its conditions and risks. Once things are stable, a later ERP audit checks that the fixes held. The Norway overview and the ERP consultant page for Norway describe the rest of my remote work there.