ERP Business Analyst in Norway

SAF-T: mapping accounts and VAT codes as requirements

Norwegian rules expect bookkeeping data to be available in the SAF-T Financial format when the tax authorities ask for it. The export itself is a software feature, but whether the file is right depends on decisions made during design: how the chart of accounts maps to the standard account codes, how each internal VAT code maps to the standard tax codes, and whether customer and supplier records carry the identifiers the file expects.

In the BRD I write these as concrete data requirements:

• A mapping table from every account to the standard grouping your accountant uses.
• A list of VAT codes the business really needs, each with a plain-language description and its standard code, confirmed by your accountant.
• Rules for master data, such as organization numbers on customers and suppliers.
• Who produces the export, how it is validated and where it is archived.

When groups bring their own chart of accounts, I document the second mapping too, from the Norwegian structure to the group one, so both reports come from the same transactions. In demonstrations, I ask vendors to produce a sample export from test data rather than show a menu option. I do not interpret tax rules; current obligations should be confirmed with your accountant or tax advisor.

EHF invoices, KID numbers and the cash cycle

Selling to Norwegian municipalities, hospitals and state bodies generally means delivering invoices in EHF, the Norwegian Peppol-based format, through an access point. Private customers may request the same. If the ERP cannot send EHF reliably, or cannot attach the buyer reference the public customer requires, invoices are rejected and cash arrives late.

I document the invoicing side as requirements: which customers need EHF, which references and order numbers each one expects, how rejections and credit notes are handled and which connector or access point the platform uses. Inbound EHF from suppliers belongs in the same section, along with approval routing.

Payments are the second half. Norwegian invoices commonly carry a KID number so incoming payments can be matched automatically. The requirements state how KID numbers are generated, how bank statements are imported, how unmatched items are handled and how supplier payments are approved and sent to the bank. For businesses invoicing in dollars or euros, they also cover currency accounts and how exchange differences are posted.

Every one of these items appears again as a UAT case. The broader platform discussion is on my pages about Odoo in Norway and Dynamics 365 in Norway.

Projects, service contracts and spare parts

Norwegian businesses serving industrial, energy or maritime customers often do not fit a simple buy-and-sell template. They run projects with milestones, carry out service work on equipment they or others supplied, keep spare parts in several locations and invoice a mix of fixed fees, hours and materials. Their requirements are where generic ERP demonstrations tend to become vague.

In process mapping sessions with project managers, service coordinators and finance, I trace the full life of a job:

• How an inquiry becomes a quote, a contract and a project or work order.
• How hours, materials, subcontractors and travel costs are captured against it.
• How spare parts are reserved, issued, returned and replenished.
• When and how the customer is invoiced, including milestone and time and material billing.
• How margin is reported, in the contract currency and in kroner.

Each step becomes a requirement with acceptance criteria. In the fit-gap matrix, these items usually show the biggest differences between platforms, which is exactly why they need to be written before demonstrations begin rather than after a contract is signed.

Trading with the EU from outside the customs union

Norway takes part in the EU single market through the EEA but sits outside the EU customs union, so goods crossing the border to Sweden, Denmark or other EU countries pass through customs. For an ERP, that is mostly a question of data. If item, customer and shipment records lack the right information, your logistics team and your freight forwarder fill the gap by hand for every shipment.

In workshops with purchasing, sales and logistics, I capture what the system must hold and produce. Typical requirements cover tariff codes and country of origin on items, delivery terms on orders, commercial invoices and packing lists in the format your forwarder or broker uses, and landed cost on imports so that duty and freight reach the item cost. Where proof of origin matters for preferential treatment, the data needed to support it is recorded too.

I do not advise on customs classification or duty; your forwarder, broker or advisor confirms the rules. My role is to make sure the confirmed rules become fields, documents and tests. A useful UAT scenario is a complete cross-border order: quotation, picking, export documents, invoice and the matching payment. The gap analysis then shows which platforms handle that flow natively.

Payroll interfaces, personal data and Norwegian review

Payroll and statutory employee reporting in Norway usually run through a dedicated payroll system or provider, not inside the ERP. The requirements therefore focus on the boundary: how salary journals arrive, with which project, department or vessel dimensions, how hours registered against projects reach payroll and how travel and expense claims are approved. Getting this interface right is what makes project margins trustworthy.

Norway applies GDPR through the EEA, so the BRD also records which personal data the ERP needs, who has access and when it is deleted. National identity numbers, for example, should normally stay in payroll rather than spread across the ERP.

All workshops and documents are in English. Norwegian-language invoice texts, reminder letters, labels and work instructions are prepared or proofread by bilingual employees or a local partner, listed in the BRD with owners. Sessions run remotely while the Norwegian working day overlaps with my afternoon and evening in India, and every area is approved in writing. For the wider decision, read my ERP consultant page for Norway and the Norway overview.