Business Central Consultant in Norway

Norwegian localization, SAF-T and the standard code mappings

Microsoft provides Business Central in a Norwegian country version, and its localization typically includes Norway-specific accounting and tax features. Microsoft has also documented SAF-T related functionality for Norway, but what your environment includes depends on the version and on any apps your partner adds, so check the current documentation and see it working with your data.

The SAF-T export is only as good as the mappings behind it. In Business Central that means two pieces of setup:

• Account mapping: each general ledger account linked to the appropriate standard account or grouping code. If you keep your existing Norwegian account plan, every account still needs that link, and new accounts must get one when created.
• Tax code mapping: each combination in the VAT posting setup linked to the standard tax code that describes it, covering domestic sales and purchases, imports, reverse charge on services from abroad and exempt or zero-rated cases.

Norway's VAT return generally draws on those same standard codes, so a careful mapping supports more than the SAF-T file. Your accountant decides which code applies to each transaction type; I make sure the posting setup reflects their decisions and that a test file passes validation before go-live.

I also ask who maintains the mappings afterwards. When a new account or VAT combination appears later, someone must map it immediately, or the next export will be incomplete. That task belongs in the finance close checklist. The wider Dynamics decision is covered on the Dynamics 365 consultant Norway page.

Posting groups and dimensions for jobs, vessels and contracts

Norwegian project and service businesses usually buy Business Central for one reason: they want to see margin per job, vessel, contract or department while work is still running. That view comes from two design areas that are often rushed.

Posting groups. General business and product posting groups determine revenue and cost accounts; VAT posting groups determine tax treatment; customer, vendor and inventory posting groups determine balance sheet accounts; job posting groups determine where work in progress and job costs are held. I design these as one matrix with your accountant, keeping the number of groups small enough that users cannot pick the wrong one.

Dimensions. Business Central lets you attach dimension values to every entry. Good dimension design for a Norwegian project business typically covers:

• the global dimensions, kept for the analysis people run every day, such as department and job or vessel
• shortcut dimensions for region, contract type or business line
• defaults set on customer, vendor, item and resource cards, with a clear rule for which wins
• mandatory dimensions on the accounts where analysis matters, and blocked combinations that make no business sense

With jobs, the job card itself can carry dimensions, so purchases and timesheets inherit them. I test the result by posting a realistic month of activity and checking whether the job profitability and department reports agree with the general ledger. When they do not, the cause is almost always in the posting or dimension setup, and it is far cheaper to fix before go-live.

KID references, payment files, statements and EHF

Cash handling in Norway relies on structured references and bank files, and public invoicing relies on EHF. A Business Central proposal should say precisely how each is handled, not just that it is supported.

• Outgoing invoices with KID: how KID numbers are generated on sales invoices, which check digit method is used and whether it matches your bank agreement. Check whether this comes from the Norwegian localization in your version or an app.
• Incoming payments: how the bank's payment file is imported so customer entries close on the KID, and how payments without a reference are handled.
• Supplier payments: how payment journals produce a file your bank accepts, carrying the supplier's KID or message, and how returned or rejected payments are reported back.
• Bank statements: the import format or connected service per bank, and the reconciliation rules for fees and combined payments.
• EHF out and in: which app or service sends sales documents to Peppol as EHF, how buyer references and credit notes are handled, and how incoming supplier EHF invoices are received and matched to purchase orders.

Each of these normally involves an app or service with its own publisher, licensing basis and support. I list them in one register with the owner, the fallback procedure and the person to call. Then each bank account goes through a real file test, and a public customer receives a trial EHF invoice and credit note before the first live billing run.

Reviewing a Norwegian partner's statement of work

Business Central is usually implemented by a partner under a proposal, a statement of work and a separate support agreement. I review all three because problems often hide between them.

Items I check in a Norwegian project:

• Requirement coverage: is each item on your list, including SAF-T mapping, KID, EHF and job costing, explicitly in scope with a named solution?
• Who does the mapping: SAF-T and tax code mapping is finance work. Is the partner doing it, guiding your team, or assuming your accountant will?
• Apps and licensing: which apps are included, who invoices for them and on what basis.
• Data migration: open entries, balances, job history and work in progress at cutover, and who reconciles them.
• Testing and acceptance: what the partner tests, what your team tests and what counts as accepted.
• Estimate type: fixed, capped or time-based, and how change requests are approved and priced.
• After go-live: support hours, response commitments, how updates from Microsoft are tested against extensions, and what happens if key partner staff leave.

You receive a marked-up document with questions to send back, and a side-by-side comparison if several partners are bidding. The vendor proposal review page sets out how I approach such reviews in any country. I do not take referral fees, so my only interest is a contract that protects you.

When to pause before choosing Business Central in Norway

Business Central fits many Norwegian companies with project, service or group complexity. I recommend pausing when:

• the business is a single, simple entity that a Norwegian accounting system and a lighter operational tool would serve well
• the real gap is customer relationships and frame agreements, where Zoho CRM in Norway might be a quicker fix
• a stock-heavy operation on a tight budget might get broader coverage from Odoo, which deserves an honest comparison
• nobody internally can own the finance design, the mappings and the partner relationship after launch

No Microsoft income and no partner commissions reach me, so Business Central is scored exactly like every competing option. Where it comes out on top, I stay involved through contracting and acceptance. More is on my Business Central consulting page; for the selection method see ERP consultant Norway, and for country context the Norway hub. All work is remote and scheduled within the Norwegian working day; Norwegian-language layouts and user guides come from your team or the partner.