ERP Requirements Consultant, Norway

The anatomy of a Norwegian requirements document

Partners in Norway quote faster and more accurately when the document they receive has a familiar, predictable layout. I build it in parts that each answer one question.

1. Company profile: legal entities, locations, user groups, volumes and the systems that will remain.
2. Process requirements: grouped by area, for example tender to invoice, purchasing with approval of incoming invoices, stock and spare parts, projects and service orders, and closing the books.
3. Norwegian compliance section: SAF-T, VAT reporting, EHF, KID, retention and document language.
4. Platform requirements: hosting, access, logging, performance and availability.
5. Interfaces and data migration: one entry per integration and per data object.
6. Glossary: terms such as KID or EHF defined once for any non-Norwegian bidder.

Every line carries an identifier, owner, priority, source and a sentence on why it matters. The workshops that uncover these needs, and the process maps behind them, are described on my ERP business analyst page for Norway. Here the concern is different: a document that survives quoting, negotiation and testing without being reinterpreted. The general method is set out under ERP BRD consulting.

Phrasing SAF-T, EHF, KID and VAT lines so they can be proven

A line such as must support SAF-T tells a partner almost nothing, because nearly every system can produce some kind of file. What you need is a statement whose result can be inspected. The wording I work toward looks like this:

• For a chosen period, the system generates a SAF-T financial file that your accountant validates and reconciles to the general ledger, with every account and tax code mapped to the standard codes they have approved.
• The VAT return is prepared from posted tax codes and submitted through the route your accountant confirms, with the submission receipt stored against the period.
• Invoices to public customers are issued as EHF documents, and incoming EHF invoices land in the approval flow with the original attached.
• Each outgoing invoice carries a KID reference that the system matches automatically when the bank statement is imported.
• Payroll is run by the payroll provider, and the ERP imports its journal by department and project.
• Vouchers and their change history stay accessible for the period your auditor confirms, even after the old system is switched off.

Interpreting Norwegian rules is not my role. Your accountant and auditor confirm each obligation, and the document notes who confirmed it and when the wording was agreed.

Hosting, access and sites far from the office

Platform requirements tend to be the thinnest part of Norwegian specifications, usually a line about security and nothing else. Yet they shape cost and risk as much as any process need, so I give them a full section.

• Hosting and data protection: where production data, backups and support access are located, whether an EEA region can be selected and how changes to subprocessors are communicated. Answers go to whoever owns GDPR internally.
• Roles and segregation: separation between maintaining suppliers and releasing payments, approval limits that follow your structure and how deputies are set up during holidays.
• Change logs: which edits to posted entries, bank accounts and prices are logged, and how the log is exported for audit.
• Load: expected behavior during month-end, large invoicing runs and payment batches, stated as expectations to agree rather than invented numbers.
• Remote and offline work: what crews on a construction site, a fish farm, a vessel or an Arctic depot must still be able to record when the connection is poor, and how that data syncs.
• Exit terms: the format and completeness of the data export you receive if you leave.

Partners can quote these lines only if they are written down before the proposal stage.

Interfaces, migration and the trail from line to test

Few Norwegian companies replace their whole landscape at once. Payroll often stays with a provider, banks connect directly, and time registration or field service tools may remain. For every interface the document records direction, timing, trigger, data content, error handling and owner.

Migration requirements are written the same way. They say which balances, open invoices, project positions and attachments come across from Tripletex, PowerOffice, Visma or an older ERP, what is archived and how each object will be reconciled. A SAF-T file from the old system can serve as a reconciliation reference, and the document says when that is expected.

Ranking happens with process owners. A must line is one whose failure would stop you signing; should and could lines guide trade-offs; will-not lines record what was consciously excluded. Each line then links to the demo scenario that shows it during selection and to the test case that proves it before go-live. That trail lets a project manager follow any Norwegian obligation from the document into the fit-gap matrix and on to acceptance testing, without relying on memory.

Version control, contracts and gaps in Norwegian specifications

When the document is released, it becomes the requirement annex partners answer line by line. The scripted demos described on my ERP selection page for Norway are built from it, and the agreed version is named in the partner agreement and statement of work so acceptance is judged against it. Companies covered by public procurement rules follow the format their procurement advisor sets, with the specification inside it.

Each release has a version number, an approval record and a change log explaining why lines were added, reworded or removed. Changes after release follow the same route, which keeps the contract tied to the document people actually signed off.

Gaps that put Norwegian projects at risk include:

• SAF-T named as a feature, with no line on who maintains the tax code mapping as accounts change.
• EHF sending covered, but receiving and approval of incoming invoices missing.
• No statement on how the VAT return leaves the system.
• Customs and import data for goods from the EU left out, although the business imports regularly.
• Unfinished projects and work in progress not mentioned in migration.
• Norwegian print layouts and reminders treated as trivial.

More on remote support for Norwegian companies sits on the Norway hub, and the wider advisory role is on my Norwegian ERP consultant page.