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 one working week. 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.