System Integration Consultant, Norway

A typical Norwegian integration landscape

Before choosing tools, I draw the landscape as it is today. For a Norwegian company with projects, stock or field staff, the picture usually contains more connections than anyone expected:

• Banks: payment files out, statements and receipt data in, often through a bank-provided integration service or a connector supplied with the ERP.
• An EHF access point: for invoices to public buyers and to private customers who prefer electronic documents, and for receiving supplier invoices the same way.
• Payroll and time: a payroll provider handling employer reporting, plus apps where field staff record hours, travel and expenses.
• Operations tools: field service, equipment rental or maritime systems holding work orders and asset data.
• Trade with the EU: forwarders and customs agents who need tariff codes, origin and delivery terms from the ERP.
• Sales and reporting: a CRM, a webshop for parts, and a BI tool combining financial and operational data.

Each flow gets a row in the inventory: what moves, which system owns it, how often, how it travels today and who would notice if it stopped. That last column is the most revealing. In many companies the honest answer is that nobody would notice until month-end. Those flows go to the top of the risk list, regardless of how technically simple they are.

KID references and bank connections, step by step

KID numbers let a Norwegian bank tell your ERP exactly which invoice a customer paid. When the design is right, most receipts match themselves. When it is wrong, finance spends mornings matching payments by amount and name. The difference lies in details agreed before anyone builds.

The specification I write covers:

1. How the ERP generates KID numbers, which check digit method the bank agreement expects and whether the KID identifies the invoice, the customer or both.
2. Which bank channel carries receipts and statements, and how often data arrives.
3. Matching rules for exact payments, part payments, several invoices paid together and payments with a missing or mistyped KID.
4. How outgoing supplier payments are created, approved and transmitted, and where approval rights sit.
5. How rejections, returned payments and status messages reach someone who can act.

Banks set their own requirements for formats and agreements, and those change over time, so I confirm them with the bank and your finance team rather than relying on a generic template. Accounts in euros or dollars get their own section, stating how receipts in those currencies are recognized and which accounts carry gains and losses, with your accountant approving the treatment. If you are also selecting an ERP, these requirements belong in the bidder tests; the ERP selection page for Norway explains how.

EHF in and out through an access point

EHF invoices are validated automatically by the receiver, which is useful because errors surface immediately, and awkward because they surface in someone else's system. The integration design has to make sure the data is right before the invoice leaves and that rejections come back to a person.

On the outgoing side I specify:

• Where the buyer's organization number, electronic address and required references are stored, and at which point in the sales process they become mandatory.
• Whether the ERP sends through its own access point service or through a separate provider, and how delivery status is shown on the invoice.
• How credit notes reference the original invoice, so the buyer can process them.

Incoming EHF invoices are the other half. I design a single intake route so electronic documents, scanned PDFs and the occasional paper invoice all land in the same approval flow. The rules cover matching to purchase orders and goods receipts, routing to project managers for approval and duplicate checks for invoices that arrive twice through different channels.

Requirements for public buyers are set by the authorities and the buyers themselves, so your advisor or the buyer's instructions confirm what applies today. My job is turning those requirements into fields, validations and tests. The CRM consultant page for Norway shows how buyer references are captured at the sales stage.

Hours, payroll and project costs from one entry

Project and service businesses in Norway often record the same hours three times: once in a time or field app, once for payroll and once for project costing in the ERP. Every copy is a chance for the numbers to drift, and drift between payroll cost and project cost is hard to explain to a customer or an auditor.

I design a flow where hours are captured once and then distributed:

• The time or field app owns the raw entry: employee, date, project or work order, activity and any allowances.
• Approved hours go to the payroll provider, which handles pay calculation and employer reporting.
• The same approved hours go to the ERP for project costing and, where relevant, customer billing.
• Payroll returns a summarized journal by department, project or vessel, which finance reconciles against approved hours.

The mapping workshop agrees which pay elements belong to which accounts, which allowances are billable and how corrections after approval are handled. Employee master data needs a clear owner, usually the HR or payroll system, with the ERP receiving only what it needs. That limits personal data in places it does not belong, a point your privacy advisor should confirm.

The ERP integration service describes this kind of ownership matrix in general terms.

Choosing the method and running it after go-live

Not every Norwegian interface deserves the same technology. I decide flow by flow, using a few practical tests:

Whoever builds, whether in-house developers, your implementation partner or an integration firm, works from the specification, and I review against it.

Testing uses Norwegian failure cases: a payment with the wrong KID, an EHF invoice rejected for a missing reference, a payroll journal with a closed project, a customs record without origin data. Finance reconciles totals across systems before sign-off.

After go-live, each interface has a log, an alert to a named person and a runbook entry. The ownership matrix states who handles bank issues, who handles EHF rejections and who renews credentials. When a bank or the ERP vendor changes something, the affected flows are retested. The Norway page covers my other remote services for Norwegian companies.