ERP Rescue Consultant, Sweden

How a Swedish ERP project drifts into trouble

Rescue work starts with understanding the path that led here, because the fix depends on it. In Swedish projects a few patterns appear again and again when the story is reconstructed.

The scope was agreed from a demo and a short requirement list, so Swedish essentials such as the SIE handover, OCR payment matching or Peppol invoicing to public customers were discovered late and solved with add-ons nobody had priced. Key users were expected to test on top of their normal jobs, often across a summer holiday period, and testing was thinner than the plan suggested. Data migration from Fortnox, Visma or an older on-premise system was treated as a file import rather than a reconciliation exercise.

After go-live, the symptoms become visible to everyone:

• The accountant cannot produce the VAT return from the new ledger and falls back on manual workpapers.
• Customer payments sit unallocated because invoice references changed at cutover.
• Stock values disagree between the warehouse and the balance sheet.
• Staff keep a parallel spreadsheet because they no longer trust the system.

None of this means the platform was the wrong choice, and none of it is solved by blaming individuals. It means the project needs a fresh, shared picture and a narrower set of priorities. That is where the ERP recovery method begins.

Establishing the facts before deciding anything

When a project is in trouble, every party has a version of events, and most of them are partly right. Decisions made on one version alone tend to make things worse. So the first phase of a rescue is deliberately about evidence, not solutions.

I speak separately with the sponsor, finance, operations, the internal project lead and the implementer's project manager, so each can be candid. I read the proposal, statement of work, change requests, test results and the open issue list. Then I check the system itself: which processes run end to end, which configuration is incomplete and what state the migrated data is in.

The output is a short written fact base covering:

• What was contractually agreed and what was assumed by each side.
• What has been built and what actually works with real transactions.
• Which open issues block invoicing, payments, the close or stock control.
• Where requirements were never written down, so nobody could have delivered them.
• The real budget and time position, including unbilled work.

This fact base is shared with both your management and the implementer. It is often the first time both sides look at the same list, and it changes the tone of the conversation. The independent second opinion page explains when this step alone is enough.

Keeping month-end, the VAT return and the SIE handover working

A troubled ERP must not be allowed to put statutory reporting at risk. While the deeper fixes are planned, I work with your finance team and accounting firm on an interim routine that keeps the books closeable and the VAT return on time.

That routine is agreed in writing and usually covers:

• Which ledger is the reference for the period if the old and new systems overlap.
• A reconciliation checklist for bank, customer and supplier balances before each close.
• How the SIE export is reviewed and corrected until the mapping is fixed at the source.
• Manual controls for VAT codes known to be wrong, listed with the corrections the accountant has confirmed.
• An owner and a deadline for every backlog: unallocated payments, rejected Peppol invoices, unposted supplier invoices.

Data fixes follow the same discipline. Opening balances are reconciled against the old system's closing figures, open items are compared customer by customer and supplier by supplier, and every correction is documented so the accounting firm and later your auditor can follow it. I do not decide tax treatment or the accounting for corrections; those choices sit with your accountant or tax advisor, and I make sure they have what they need to decide quickly. Once the close runs reliably, attention shifts to stabilizing the business processes, as described under go-live support.

Resetting with your implementer, or preparing a handover

Most Swedish ERP rescues succeed with the existing implementer once both sides agree a new baseline. Relationships are often strained by this point, so I act as a neutral facilitator rather than an advocate for either side. The conversation is built on the fact base, not on who was at fault.

In a reset workshop we sort the remaining work into items needed for stable operation, items that can move to a later phase, items that are no longer needed and items that are genuinely disputed. Disputed items are traced back to the proposal and statement of work. Responsibilities, acceptance criteria and a realistic plan are written down and reviewed at regular checkpoints.

Sometimes the better route is a new implementer. Then the priority is an orderly handover rather than a sudden break:

• Admin access, environments and backups transferred to your control.
• License subscriptions that may be held through the current partner identified and moved.
• Custom extensions, their source and documentation collected.
• Open defects and configuration decisions written up for the next firm.

Swedish implementation agreements often combine general terms with an order and a statement of work. I review those documents against what was delivered and list the points that matter, but questions of breach, withholding payment or termination go to your lawyer. My freelance ERP consultant page for Sweden explains how ongoing client-side support can continue after the reset.

Continue, cut scope or change platform

Once the facts are known and the close is stable, management faces the real decision. I present it as a comparison of options with conditions, not as a single verdict.

Continue with a narrower scope. This is the most common recommendation. The core of finance, sales and purchasing is made solid first, and secondary areas such as advanced warehouse functions or a customer portal move to a planned later phase. It works when the platform handles your Swedish essentials and the remaining gaps are configuration or training.

Continue with a different implementer. Suitable when the platform fits but confidence in the delivery team has gone. The cost is a learning period for the new firm, which a good handover shortens.

Change platform. Occasionally the evidence shows that the system cannot meet core requirements without heavy custom work that will be expensive to maintain through every Swedish rule or format change. Then a structured reselection makes sense, using the lessons from this project as requirements. My ERP selection work in Sweden covers that path.

Whatever is chosen, governance continues: named decision owners, a single plan, change control and honest status reporting. When the system is stable, an ERP audit some time later confirms that the fixes held. More about how I support Swedish companies remotely is on the Sweden overview.