Norway SAF-T Financial

Key Features

SAF-T Financial XML generation as a codeunit over `G/L Entry`, `VAT Entry`, `Cust. Ledger Entry`, `Vend. Ledger Entry` and `Dimension Set Entry` for any date range

Streaming export using `XmlWriter` so multi-year periods generate without exhausting the tenant memory limit

Validation of the produced file against the Skatteetaten SAF-T XSD before release, reporting the failing node path back to the user

`SAF-T Mapping Setup` page pairing every G/L account with its Norwegian standard account, with a pre-export check that blocks unmapped in-scope accounts

Tax code mapping derived from your existing VAT posting setup combinations rather than re-keyed into a separate table

Dimension export mapped to SAF-T analysis types, with explicit control over which dimensions are in scope and how blank values are represented

One posting produces both the submission XML and a human-readable report for controller and auditor review, from the same dataset

Job queue entry for scheduled or long-running exports, so month-end generation does not tie up a user session

`SAF-T Export Log` table recording period, company, user, timestamp, row counts, file size and hash of every export

Rejection handling: authority rejections recorded against the original run, with a correction workflow tracked through to acceptance

Compliant archiving of every generated file with immutable log linkage, so a past submission can be reproduced exactly

Multi-company support with per-company scope selection, for groups where only some legal entities file in Norway

Dedicated permission sets separating mapping maintenance, export execution and read-only log access

API pages over REST API v2.0 / OData v4 exposing export status and log entries to Power Automate, Power BI and Dataverse

Event subscribers and a dedicated object range only — no base-application modifications, so release-wave updates stay clean

Built and tested for both Business Central online (SaaS) and on-premises deployments on current release waves

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

When Skatteetaten asks for a SAF-T Financial file, the clock starts. Norwegian bookkeeping rules require accounting data to be produced in the Standard Audit File for Tax (SAF-T Financial) XML format on request, covering the general ledger, the chart of accounts mapped to the Norwegian standard accounts, customers, suppliers, tax codes, dimensions and every posted journal line for the requested period. Finance teams running Dynamics 365 Business Central usually discover at that moment that the setup on hand does not match how their company actually posts: the standard-account mapping is incomplete, VAT codes were extended locally, dimensions carry meaning the schema does not know about, or the group runs multiple companies where only one is in scope. What follows is a spreadsheet-and-XML exercise done under a deadline, by hand, outside the system of record.

This is where Business Central out of the box runs out of road for a lot of Norwegian filers. The platform gives you posted entries, dimensions and VAT posting setup, but it does not give you a governed mapping layer between your own G/L accounts and the Norwegian standard accounts, it does not validate the produced file against the published XSD before you send it, and it keeps no record of what was exported, by whom, for which period, and whether the authority accepted it. Nothing stops a second, silently different export of the same period being handed over weeks later.

ECOSIRE builds a per-tenant AL extension — or an AppSource-packaged app where you prefer that distribution — that closes those gaps inside Business Central. A SAF-T Mapping Setup page pairs each G/L account with a Norwegian standard account and each VAT posting setup combination with the required SAF-T tax code, with validation codeunits that refuse to run an export while any in-scope account or tax combination is unmapped. Generation runs in a codeunit over G/L Entry, VAT Entry, Cust. Ledger Entry, Vend. Ledger Entry and Dimension Set Entry, streams XML with XmlWriter so a multi-year period does not exhaust the tenant memory limit, and validates the result against the Skatteetaten XSD before the file is ever released.

Long-running exports are handed to a job queue entry so nobody has to hold a session open, and the same posting produces both the machine XML for submission and a human-readable report you can give a controller or an auditor. Every run is written to a SAF-T Export Log table with period, company, user, file hash, row counts and status; if the authority rejects a file, that rejection is recorded against the original run and a correction workflow tracks the re-export through to acceptance. Table and page extensions surface mapping and log where finance already works, dedicated permission sets separate who may map, who may export and who may only read, and API pages exposed over REST API v2.0 / OData v4 let a Power Automate flow or a Dataverse-connected process read export status without anyone needing a Business Central licence they would not otherwise have. Everything is built on its own object range with event subscribers rather than base-application changes, targeting current release waves on both SaaS and on-premises.

This is a build-to-order product, not an existing AppSource download. Delivery starts with a short scoping call where we look at your actual chart of accounts, VAT posting setup, dimension usage, company structure and Business Central version — those are exactly the variables that decide how much mapping and how much correction workflow you need. From confirmed scope, typical delivery is 2 to 4 weeks. We build against your version, deploy to your sandbox first, run user acceptance testing on real posted data with your finance team, then install to production with a documented rollback, hand over the git repository and source code, and stay with you through an agreed post-go-live support window.

What you get

Installable AL extension source code, built and compiled against your specific Business Central version and release wave

Installation and configuration on your sandbox and production environments, including permission set assignment and job queue setup

Technical documentation: object ID ranges, table and page extensions, codeunit structure, event subscribers, API endpoints and upgrade notes

End-user guide plus a live training session for your finance team covering mapping maintenance, export, validation errors and the correction workflow

User acceptance testing on a staging environment against your real posted data, with a documented rollback plan before the production install

Mapping workbook prepared from your live chart of accounts and VAT posting setup, reviewed with your accountant before go-live

Post-go-live support window for defect fixes and configuration adjustments at no additional charge

Full git repository handover with commit history, branch structure and build pipeline configuration — you own the source

Who this is for

Finance Manager / Regnskapssjef at a Norwegian-registered company

Accountable for producing a SAF-T Financial file when Skatteetaten requests one, usually on short notice. Needs the export to come out of Business Central complete and schema-valid on the first attempt, and needs to show which accounts map to which standard accounts without defending a spreadsheet.

Group Controller with Norwegian subsidiaries

Runs several legal entities in one Business Central tenant, only some of which file in Norway. Needs per-company scoping, consistent mapping governance across entities, and a single log proving what was submitted for each company and period without opening each company one at a time.

Business Central Solution Architect or IT Manager

Owns the tenant and its upgrade path. Wants compliance functionality delivered as a clean AL extension on its own object range using event subscribers, with its own permission sets and API pages that fit the existing Power Platform estate — no base-application changes to carry forward.

External accountant or audit firm serving Norwegian clients

Prepares or reviews SAF-T submissions on behalf of clients. Needs the human-readable output alongside the XML to check the numbers, and needs the archived files and audit trail to answer questions about a submission made months earlier.

How Norway SAF-T Financial Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your chart of accounts and VAT setup	Mapping built from your live master data during delivery and reviewed with your accountant before go-live	As good as the developer's grasp of SAF-T; usually one pass, rarely reviewed by an accountant	Generic mapping template you populate yourself, with support that cannot see your data	No standard-account mapping layer; reconciliation happens outside Business Central
Pre-submission validation	File validated against the Skatteetaten XSD before release, with the failing node path shown to the user	Often deferred to a later phase and never built; errors surface at the authority	Usually present, though errors tend to name the schema fault rather than the Business Central record behind it	None — the first validator is the authority
Audit trail and archiving	Every run logged with period, user, row counts and file hash; archived files reproducible years later	Whatever was in scope at the time; frequently a file saved to a network folder	Basic export history, often without file hashing or rejection linkage	No record that an export ever happened
Rejection and correction handling	Rejections recorded against the original run, with a correction workflow tracked through to acceptance	Handled by email and memory unless explicitly specified and paid for	Re-export the period; the link between rejected and corrected file is yours to keep	Entirely manual
Upgrade safety across release waves	Own object range and event subscribers only; tested against upcoming waves before they reach you	Depends on developer discipline — base-application changes are a common shortcut	Generally upgrade-safe, but you wait on the vendor's release cycle	Nothing to break, and nothing to use
Power Platform integration	API pages over REST API v2.0 / OData v4 exposing export status and logs to Power Automate and Dataverse	Only if specified up front; typically added later at extra cost	Varies widely; many apps expose no API surface at all	Standard APIs exist but carry no SAF-T export concept
Source code ownership	Full git repository handed over — no runtime lock, no licence server	You own it, and you also own every future fix	Vendor-owned binary rented per user or per tenant, indefinitely	Not applicable
Time and cost to a working export	2 to 4 weeks from confirmed scope, fixed on an agreed quotation	Months of internal developer time plus the SAF-T domain learning curve	Fast to install, then weeks of self-service mapping and support tickets to make it fit	Immediate to start, indefinite to finish — the work simply moves to spreadsheets

Frequently Asked Questions about Norway SAF-T Financial

How long does delivery take?

This is a build-to-order extension, not an instant AppSource download. From confirmed scope, typical delivery is 2 to 4 weeks. That covers building against your Business Central version, preparing the account and tax mapping from your live master data, sandbox deployment, user acceptance testing with your finance team, and the production install. The scoping call itself takes about 30 minutes and is what turns an estimate into a confirmed timeline. Complex multi-company structures or heavily customised VAT setups sit at the longer end of that range, and we will say so before you commit.

What happens with support and Business Central updates?

Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because the extension uses its own object range and event subscribers rather than modifying base-application objects, Business Central release-wave updates do not normally break it. We test against upcoming release waves and, for clients on a support agreement, ship a compatibility update before the wave reaches your environment. A change to the Skatteetaten schema is handled the same way. You also receive the full git repository, so your own team or another partner can maintain it if you ever choose to.

Does this work on Business Central on-premises as well as online?

Yes. The extension is built and tested for both deployment models on current release waves. Online tenants receive it as a per-tenant extension, or as an AppSource-packaged app if you prefer that distribution route; on-premises environments receive the same AL app packaged for your server version. The practical difference is the XSD validation and archiving path, which we configure to whatever storage your on-premises environment uses.

We already have the Norwegian localisation. Why do we need this?

The localisation gives you Norwegian posting behaviour. It does not give you a governed mapping layer between your specific chart of accounts and the Norwegian standard accounts, pre-submission XSD validation, or a durable record of what was exported and whether it was accepted. Most of the manual effort in a real SAF-T request sits exactly there — reconciling locally extended VAT codes and dimension usage into the schema. That is what this extension automates and documents.

What do you need from us to scope this?

Your Business Central version and release wave, whether you are online or on-premises, an export of your chart of accounts and VAT posting setup, which dimensions carry accounting meaning, and how many companies in the tenant are Norwegian filers. If you have already produced a SAF-T file by hand, sending us that file and any rejection messages you received is the single most useful input — it tells us precisely where your data and the schema disagree.

Can the export run automatically on a schedule?

Yes. Exports run on demand from the SAF-T page or through a job queue entry, so a monthly or annual file can be generated and archived without anyone holding a session open. Scheduled runs write to the same export log and pass the same XSD validation as manual runs. Some finance teams schedule a monthly generation purely so that a validated file already exists if the authority asks.

Who owns the code once it is delivered?

You do. We hand over the full git repository with commit history and the build pipeline configuration alongside the compiled app. There is no runtime lock, no licence server call, and no dependency on ECOSIRE remaining engaged. Clients stay with us for support because the support is worth having, not because the code holds them there.