ERP Rescue Consultant, Denmark

Many suppliers, no single owner

Danish ERP projects increasingly combine a core platform with apps from several publishers: bank and payment connections, document capture, e-invoicing, expenses, shipping and webshop sync. Add an external payroll provider and a separate agency for the online store, and a company may have several suppliers touching a single business process. When something fails, each can reasonably say the fault lies elsewhere.

This is a common route into rescue territory. Defects bounce between suppliers, tickets stay open, and the implementation partner bills time for investigating problems in components it did not build. The finance team, meanwhile, works around everything by hand.

Other familiar causes add to the pressure:

• Requirements were written as a feature list, so Danish essentials such as FIK codes, EAN numbers for public customers or voucher storage were solved late and inconsistently.
• Key users tested in the gaps of their normal jobs, and the go-live date did not move when testing slipped.
• Data from C5, NAV or e-conomic was imported without a full reconciliation of balances and open items.
• Nobody inside the company had the authority to make design decisions quickly.

None of these is anyone's personal failure. They are structural, which is why the fix starts with structure: one picture of the facts, one owner per problem and one plan. The method follows my ERP recovery approach, adapted to the multi-supplier setups common in Denmark.

One fact base for every party involved

The first phase of a Danish rescue is about agreeing what is true. Until the partner, the app vendors and your own team are looking at the same list, every meeting repeats the same argument.

I begin with a supplier map: every party, what they were contracted to deliver, who the contact is and which process steps depend on them. Then I interview your sponsor, finance lead, operations and key users, the person running the project internally and the partner's lead consultant one at a time, and contact app vendors where a defect clearly involves their component. Documents come next: proposals, statements of work, app subscriptions, change requests and the open ticket list.

Finally I test the system with real transactions. Can a sales order become an invoice with the right FIK code? Does an invoice to a municipality leave with its EAN number and arrive? Does a bank statement import and match? Does stock agree with the ledger?

The fact base records, for every open problem, which component it sits in, who owns it, what it blocks and whether it was in anyone's scope at all. Gaps that were never in scope are as important as defects, because they show where the original requirements fell short. The fact base is shared with management and all suppliers concerned. When a company only needs this independent view, the second opinion page describes it as a standalone step.

Running the old and new systems side by side safely

Many troubled Danish rollouts end up with two systems in use: the new ERP for some processes and the old one, often C5, NAV or e-conomic, for the ledger or for areas that never went live. Parallel running can be a sensible bridge, but only if its rules are explicit. Without rules it doubles the work and creates two versions of the truth.

With your finance team and accountant I agree a written arrangement covering:

• Which system is the reference ledger for each period, and for which entities.
• Where vouchers are stored during the overlap, so documentation stays complete and retrievable under the bookkeeping rules your accountant applies.
• How transactions are reconciled between the systems, by whom and how often.
• Which system prepares the VAT return, and how known setup errors in the new system are corrected before filing.
• The criteria for ending the overlap and how the old system's data will be kept accessible afterward.

I do not decide the accounting treatment or the retention requirements; your accountant does, and I make sure the arrangement reflects their decisions. The aim is a short, controlled overlap that ends with the new system as the only ledger. The implementation consultant page for Denmark discusses how archiving the old system's history is normally planned before cutover.

Clearing payment, invoice and data backlogs

A painful go-live leaves backlogs that grow every day the causes stay unfixed. Clearing them is part of stabilization, but only after the cause of each is understood, otherwise the same items return next week.

Customer payments. Receipts that did not match because FIK codes changed at cutover, or because matching rules were never set up, are allocated with finance in a structured sweep. The rules are then corrected and tested so new receipts match automatically.

Public e-invoices. Invoices rejected for missing EAN numbers or order references are corrected and resent, and the customer and order setup is changed so the fields cannot be skipped.

Supplier invoices. Documents stuck in the capture app or in the e-invoice inbox are processed in date order, with payment priorities agreed so suppliers are not alienated.

Data corrections. Opening balances, unpaid receivables and payables and inventory valuations are reconciled with the closing position in the old system. Where batch or lot data matters, for example in food or life sciences, traceability records are checked before anything else. Every correction is documented so your accountant and later your revisor can follow it.

Once the backlogs are clear and stay clear, the first clean month-end close becomes the milestone that shows the recovery is real. The go-live support page describes how that first close is handled.

Resetting with the partner and choosing a direction

With the facts agreed and finance steady, the reset conversation can be productive. I facilitate a neutral workshop with the implementation partner and, where needed, the main app vendors. Remaining work is sorted into what is needed for stable operation, what can wait for a later phase, what is no longer needed and what is disputed. Disputed items are traced to the proposal and statement of work rather than argued from memory. Ownership, acceptance criteria and a plan with checkpoints are written down.

If the decision is to change partner, the handover is planned carefully: admin rights and environments under your control, license and app subscriptions that may run through the partner identified and transferred, extensions and their documentation collected, and the open issue list handed over intact.

Danish implementation agreements may combine standard terms with an order and appendices. I compare those documents with what was delivered and record the gaps, but any question of breach, compensation or termination goes to your lawyer.

Management then chooses between continuing on the full plan, continuing with a narrower first scope, changing partner or, if the platform cannot meet core needs without heavy custom work, reselecting. Each option comes with its conditions and risks. Once stable, an ERP audit later on confirms the fixes held. My wider remote work for Danish companies is summarized on the Denmark page, and platform-neutral advice sits under ERP consulting in Denmark.