Business Process Consultant, Norway

Where processes leak in Norwegian companies

Process trouble rarely announces itself. It shows up as small, recurring frictions that people have learned to live with. Before any workshop, I look for the signals in documents, reports and short conversations with staff:

• Extra work on projects is done on a phone call and only discovered when the customer queries the invoice.
• Incoming EHF invoices sit unapproved because nobody is sure which project or department they belong to.
• Some outgoing invoices leave without a KID number, so their payments are matched by hand.
• The accountant asks the same questions every month because the inputs arrive in a different shape each time.
• Travel and expense claims are approved by whoever is available, not by a defined person.
• New accounts are created during the year without anyone updating the mapping used for statutory reporting.

Each signal is traced back to a step, a role and a missing rule. That gives the mapping work a clear focus. Instead of documenting everything at the same depth, I spend time where a flow actually breaks and keep the rest at a summary level. The resulting picture tells management which problems are about discipline, which are about unclear ownership and which genuinely need a different tool.

Project delivery and the change order problem

Many Norwegian businesses deliver work as projects for industrial, energy, maritime, public or construction customers. In those businesses, the most expensive process gap is often extra work that is carried out but never billed, or billed so late that the customer disputes it.

I map the variation process from the moment a request appears to the moment it is invoiced:

1. Who can receive a request for extra work on site or by email, and how it is recorded the same day.
2. Who prices it, using which rates or estimates, and who approves the price internally.
3. How the customer confirms it, and what counts as confirmation under the contract.
4. How the approved variation is added to the project budget, so hours and materials can be booked against it.
5. When it is invoiced, alongside or separate from the ordinary progress billing.

The target design adds a simple rule: no extra work without a recorded request and a named approver, with an agreed fast route for genuine emergencies. Contract terms and dispute questions stay with your legal advisor; I focus on whether the day-to-day routine matches what the contract allows. For businesses where projects dominate, this connects with the analysis on my ERP business analyst page for Norway, which covers what a future system would need to support.

Purchasing, EHF invoices and approval limits

When most supplier invoices arrive as EHF documents, the bottleneck moves from data entry to approval. The invoice is already in the system; what is missing is a decision about where it belongs and who may approve it.

The procure to pay design I work out with you answers a short list of questions:

• Ordering: which purchases need a purchase order or a written request first, and which can be invoiced directly against a contract.
• References: which order or project reference suppliers must quote, so invoices can be routed without guesswork.
• Receipt: who confirms that goods arrived or services were delivered, especially for deliveries to sites, vessels or remote locations.
• Approval limits: how much each role may approve, when a second approver is needed and who stands in during absences.
• Disputes: who contacts the supplier when price, quantity or quality is wrong, and how a credit note is requested.

The rules are written into an approval matrix that management signs off. It does not depend on any particular platform. Whether the matrix is later enforced in your current accounting system or a new ERP, the decisions are made once, by the business, and can be explained to an auditor. More on the configuration side sits on the procurement automation page.

Month-end, SAF-T mappings and who keeps them current

Norwegian bookkeeping rules expect accounting data to be available in the SAF-T format on request, as your accountant can confirm in detail. The export is a system feature, but keeping it correct is a process question. Every new account, VAT code or department has to be mapped, and someone has to own that task.

In record to report mapping, I make these responsibilities explicit alongside the ordinary close:

• Who may create new accounts, VAT codes or dimensions, and who updates their standard mapping at the same time.
• Who reconciles bank accounts, including receipts that did not match on the KID reference.
• Who books accruals for project revenue and costs, and on what evidence.
• What the external accountant or auditor receives, in which form and by when.
• Who reviews the VAT basis before it is filed, and who signs it off.

The result is a close calendar that names a person for each task and a dependency for each input. It removes the familiar month-end where finance waits for project managers and the accountant waits for finance. Questions about how specific transactions should be treated go to your accountant or tax advisor. The broader context for Norwegian ERP decisions is on my ERP consultant page for Norway.

Making the process stick, then choosing software

A process design only helps if people follow it after the consultant has gone. I build three things into the handover to make that more likely.

First, each end-to-end flow gets an owner, usually a manager who feels the pain when it fails. The owner approves changes, keeps the documents current and is the person staff ask when something is unclear. Second, the documents are short: one map per flow, an approval matrix and procedures of a page or two each, written for the role that uses them. Third, the business agrees a light review rhythm, for example a short check after the first few closes, to catch rules that do not work in practice.

Everything is written in English. Where staff on site or in the warehouse prefer Norwegian instructions, your team adapts them and the English version remains the reference.

Software is the last step, not the first. The gap list from the design tells you which issues need a new routine, which need a configuration change and which need a different tool. Some of those become candidates for business automation in Norway; others become requirements for a system choice. The Norway overview shows all the ways I support Norwegian companies remotely, and the underlying method is explained under ERP process mapping.