Norway SAF-T Requirements: Complete Compliance Guide

Norway's SAF-T Financial requirement (known locally as SAF-T Regnskap) applies to all businesses operating electronic bookkeeping systems that meet at least one of two thresholds: annual turnover exceeding NOK 5 million, or more than 600 vouchers processed per year. Organizations that meet these criteria must be able to produce a valid SAF-T XML file on demand and submit it through the Altinn portal whenever Skatteetaten requests one during a tax audit. As of January 1, 2025, that file must conform to version 1.30 of the standard.

The legal foundation sits in the Norwegian Bookkeeping Act and the accompanying regulations issued by Skatteetaten. According to the Norwegian Tax Administration's SAF-T Financial guidance, SAF-T Financial reporting is mandatory for all Norwegian enterprises with electronic bookkeeping for accounting periods starting January 1, 2020 or later, with version 1.30 of the SAF-T standard required from January 1, 2025.

SAF-T Financial is Norway's implementation of the OECD's Standard Audit File for Tax framework. The OECD developed the original schema to give tax authorities a standardized, machine-readable way to access accounting data across jurisdictions. Norway adopted this framework and layered on country-specific requirements, including a mandatory chart-of-accounts mapping to Norway's standard account plan and detailed VAT code structures tailored to Norwegian tax law.

The on-demand submission model

Unlike countries such as Portugal or Poland, where businesses submit SAF-T files on a regular schedule (monthly or annually), Norway operates an on-demand model. There is no periodic filing obligation. Instead, businesses must maintain the capability to generate a compliant SAF-T XML file at any point and deliver it when Skatteetaten issues a request during a tax audit. Romania sits at the other end of the spectrum with recurring D406 submissions for different data sets, which this Romania SAF-T D406 filing guide breaks down by file type and deadline.

This creates a "readiness without routine" compliance challenge. Because the file is never submitted until an auditor asks for it, organizations can go years without generating one. The risk is that mapping errors, missing data fields, or software misconfigurations go undetected until the moment compliance actually matters. By then, remediation is urgent and the stakes are high.

Compliance thresholds and exemptions

The two conditions that trigger the SAF-T obligation are:

The business uses an electronic bookkeeping system (ERP, accounting software, or any digital ledger), AND
The business meets at least one of these criteria:
- Annual turnover exceeds NOK 5 million
- The business processes more than 600 vouchers per year

Businesses that fall below both thresholds and do not maintain electronically available bookkeeping information are exempt. Organizations relying entirely on manual or paper-based bookkeeping are also outside the scope of the requirement, regardless of size.

SAF-T Financial should be distinguished from the SAF-T Cash Register module, which covers point-of-sale transaction data and carries its own distinct requirements, including digital signature obligations. The two modules serve different audit purposes and have different technical specifications. This guide focuses on SAF-T Financial.

Foreign companies that are VAT-registered in Norway face the same SAF-T obligations as domestic businesses. The specific implications for foreign entities, including practical challenges around ERP configuration and local representation, are covered in detail later in this guide.

SAF-T Financial Data Structure and Required Fields

A Norwegian SAF-T Financial file is an XML document built around three main components: the Header, Master Files, and General Ledger Entries. Each component serves a distinct purpose during a tax audit, and your ERP system must be capable of exporting all three with complete, accurate data.

Header

The Header block identifies your company and defines the scope of the export. It contains:

Company information — organization number, name, and registered address
SAF-T version — the schema version used to generate the file (currently 1.30)
Selection criteria — the accounting period covered by the export, defined by start and end dates
Default currency — the base currency of the accounting system (typically NOK)

The Header is straightforward, but errors here propagate downstream. An incorrect organization number or mismatched accounting period will cause the entire file to fail validation against Skatteetaten's official XSD schema.

Master Files

Master Files form the reference backbone of your SAF-T export. This section contains four primary data sets:

General ledger accounts — every account in your chart of accounts, including account ID, description, and the standard account type classification. Each account must be mapped to a standard grouping using GroupingCategory and GroupingCode. This mapping links your internal account structure to the Norwegian Standard Account Framework (Norsk Standard Kontoplan), giving tax authorities a consistent way to interpret your financial data regardless of how your chart of accounts is organized internally.
Customer master data — name, organization or personal identification number, address, and contact details for every customer referenced in the general ledger entries.
Supplier master data — the same fields as customer data, covering every supplier with transactions in the reporting period.
Tax table — a mapping of your internal VAT codes to the standard SAF-T tax codes defined by Skatteetaten. This ensures that every tax-related transaction can be interpreted uniformly.

One persistent source of validation failures deserves specific attention: address fields cannot be blank. When you submit a SAF-T file through Altinn, incomplete master data — particularly missing street addresses, postal codes, or city names on customer and supplier records — will trigger rejection. This is not a best-practice recommendation. It is a practical requirement. Many organizations discover this only after their first failed submission, so auditing master data completeness before generating your SAF-T file is essential.

General Ledger Entries

The third component contains your actual financial transactions. Each journal entry must include:

Documentation date — the date of the underlying document (invoice, receipt, or other source)
Document reference — a traceable link to the original supporting documentation
Account specification — the general ledger account(s) debited and credited
Customer/supplier specification — where applicable, the customer or supplier associated with the transaction, linking back to the Master Files

Every entry must balance, and every account, customer, and supplier referenced must exist in the Master Files section. Cross-referencing integrity between these components is something Skatteetaten's validation tools check explicitly.

Scope and Future Expansion

The current Norwegian SAF-T standard operates at the general ledger level. Your export obligation covers account balances, journal entries, and the master data that supports them. Skatteetaten has indicated that future versions of the standard are planned to include detailed invoice-level and source document data, but this granularity is not yet required. For now, ensuring your general ledger export is complete, correctly mapped, and free of blank required fields is the compliance baseline.

Skatteetaten publishes the official XSD schema for validation, and provides tools to check your XML file against it before submission. Running this validation step locally — before uploading through Altinn — catches structural and data-quality issues early.

Version 1.30: What Changed and Why It Matters

SAF-T Norway version 1.30 became mandatory for all accounting periods beginning on or after January 1, 2025. This was not an incremental update. Version 1.30 introduced structural changes that broke backward compatibility with version 1.20, requiring every compliant organization to revisit and rebuild core parts of its SAF-T export.

The Breaking Changes in Detail

The most disruptive change was the replacement of the StandardAccountID element with two new elements: GroupingCategory and GroupingCode. Under version 1.20, organizations mapped their chart of accounts to a standard account ID. That entire mapping framework was discarded. GroupingCategory now identifies which classification system applies (such as the Norwegian standard two-digit or four-digit account plans), while GroupingCode specifies the exact code within that system. Every account in the chart of accounts had to be remapped from scratch.

Beyond the chart of accounts overhaul, version 1.30 introduced several additional structural changes:

New balance account structures for both customer and supplier accounts, altering how opening and closing balances are reported at the sub-ledger level.
A new method for presenting VAT in transactions, changing how tax amounts and tax codes are structured within journal entries.
Three new data fields added across various elements in the schema.
Previously optional elements became mandatory, meaning SAF-T files that validated successfully under version 1.20 would fail validation under version 1.30 even without the other changes.

Why a Simple Version Bump Was Not Enough

Organizations that had invested significant effort in building a compliant version 1.20 export could not update a version number in the XML header and call it done. The GroupingCategory and GroupingCode replacement invalidated every existing chart of accounts mapping. ERP administrators had to work through their entire account structure, assign the correct GroupingCategory, and select the appropriate GroupingCode for each account.

This rippled through the software ecosystem as well. ERP systems and accounting software vendors had to update their SAF-T export modules to produce the new XML structure. Finance teams then had to test the updated exports, validate the output files against the new XSD schema, and confirm that balance totals and VAT presentations matched their source data. For organizations with complex charts of accounts or multiple entities, this represented weeks of mapping, testing, and validation work.

Open-Source Validation Resources

Skatteetaten publishes the updated XSD schema and official code lists on GitHub at github.com/Skatteetaten/saf-t. This is unusual among tax authorities globally and gives ERP administrators and software developers direct access to the authoritative validation resources. Organizations can validate their version 1.30 files against the official schema before any audit request arrives, catching structural errors during testing rather than during a live tax examination.

SAF-T and Norway's Digital VAT Return

In January 2022, Skatteetaten replaced Norway's traditional VAT return with a new digital format called mva-melding. This was not a cosmetic update. The new return is built directly on SAF-T tax code logic, making Norway one of the few countries where the standard audit file format actively shapes routine tax compliance rather than sitting dormant until an auditor requests it.

The previous VAT return used 19 reporting lines. The mva-melding expanded this to 30, with each line structured around SAF-T tax code classifications. Companies reporting VAT in Norway now map their transactions to SAF-T codes that flow into two distinct outputs from the same underlying data: the XML audit file that Skatteetaten can request during an examination, and the periodic VAT return submitted through mva-melding.

This dual role is unusual in European tax administration. In most countries that have adopted SAF-T or similar audit file standards, the audit file exists as a standalone compliance artifact. Companies generate it on demand when tax authorities ask for it, and the mapping exercise remains largely separate from day-to-day reporting. Norway took a different path by embedding SAF-T code logic into the structure of the VAT return itself, so the same classification decisions that determine audit file accuracy also determine what appears on every VAT filing.

The practical consequence is straightforward but easy to underestimate. A mapping error in SAF-T tax codes does not just create a problem for some future audit scenario. It produces an incorrect VAT return in the current period. If a transaction is assigned to the wrong SAF-T code, the mva-melding will slot it into the wrong reporting line, potentially misreporting output VAT, input VAT deductions, or reverse charge obligations. The error compounds with each filing period until someone catches it.

For finance teams and ERP administrators, this means SAF-T code mapping deserves the same level of scrutiny as any other element of the VAT return preparation process. Treating it as a secondary compliance task, something to address only when an audit looms, misreads how Norway's system actually works. Every VAT return submitted through mva-melding is, in effect, a partial demonstration of SAF-T readiness.

SAF-T Obligations for Foreign Companies in Norway

Foreign companies registered for VAT in Norway are subject to the same SAF-T requirements as domestic businesses. There are no exemptions based on foreign domicile. If a foreign entity meets the standard compliance thresholds — using electronic bookkeeping and either exceeding NOK 5 million in annual turnover or processing more than 600 vouchers — it must be capable of producing a compliant SAF-T file upon request from Skatteetaten.

This equal treatment catches many international businesses off guard. A German manufacturer with a Norwegian VAT registration, a UK-based consultancy billing Norwegian clients, or a US software company with taxable digital sales in Norway all face identical obligations to a Bergen-based firm of the same size.

The practical difficulties, however, are considerably greater for foreign entities.

Accounting system compatibility is the most common obstacle. Non-Norwegian ERP systems such as SAP, Oracle, or regional platforms used in the company's home country rarely support Norwegian SAF-T XML export as a native feature. Generating the required XML schema typically demands either a purpose-built module, third-party middleware, or a custom extraction and transformation layer. The cost and complexity of this varies widely depending on the ERP platform and how its data model maps to SAF-T's structure.

Chart of accounts mapping presents a related challenge. Norway's SAF-T standard requires every general ledger account to be tagged with a GroupingCategory and GroupingCode that align with Norwegian standard account frameworks. A foreign company's chart of accounts will almost certainly follow a different structure — the home country's local GAAP, IFRS categories, or an internal corporate framework. Bridging these two structures requires building mapping tables that translate each account into its Norwegian equivalent, a process that demands both technical precision and familiarity with Norwegian accounting conventions.

Dual reporting obligations compound the workload. Foreign companies must maintain data that satisfies their home jurisdiction's reporting requirements while simultaneously keeping their Norwegian transactions in a SAF-T-ready format. This can mean running parallel ledger structures or maintaining a secondary reporting layer specifically for Norwegian compliance. Neither approach is trivial, and both require ongoing maintenance as either country's requirements evolve.

Language and Altinn access are less severe obstacles than they once were — Skatteetaten publishes English-language SAF-T guidance and schema documentation — but certain regulatory updates may appear in Norwegian first. All submissions flow through the Altinn portal, which requires a Norwegian organization number and digital credentials. For companies without a physical presence in Norway, this registration can require coordination with Norwegian authorities or a local representative.

Foreign companies should not treat SAF-T compliance as a problem to solve only when an audit notice arrives. Skatteetaten can request a SAF-T file with limited advance notice, and building the export capability retroactively — particularly when it involves middleware integration and account mapping — is far more expensive and error-prone than establishing it proactively.

How Norway's SAF-T Compares to Other European Standards

Each country that adopted the OECD's 2005 SAF-T framework has adapted it differently, and several European nations use entirely separate formats. Norway's on-demand model contrasts sharply with countries that require routine submissions, including phased models covered in this Bulgaria SAF-T rollout timeline and data-readiness guide.

Dimension	Norway (SAF-T)	Portugal (SAF-T PT)	Poland (JPK)	Netherlands (XAF)	Sweden (SIE)
Format basis	OECD SAF-T (XML)	OECD SAF-T (XML)	OECD SAF-T (XML)	Auditfile Financieel (XML), not SAF-T	SIE (Standard Import Export), not SAF-T
Submission model	On demand only	Monthly (mandatory)	Monthly or quarterly	On demand only	No mandatory submission
Linked to VAT return	Yes, SAF-T codes feed the digital mva-melding	No, separate obligation	Yes, JPK replaced the VAT return entirely	No direct link	No
Certified software required	No	Yes, with mandatory ATCUD codes on every invoice	No, but structured data formats enforced	No	No
Validation tools	Government-published, open source	Tax authority validation portal	Ministry-provided validation tools	No centralized government validator	No centralized government validator

Portugal requires monthly SAF-T submission with certified billing software and per-invoice ATCUD tracking codes — the most intensive routine model in Europe. See Portugal's SAF-T compliance framework for its four file types and certification rules.

Poland replaced its traditional VAT return entirely with SAF-T-based JPK_VAT files in 2020, submitted monthly or quarterly. Each submission must classify transactions using Poland's 13 GTU codes and procedural markers, making the audit file the primary tax reporting mechanism.

The Netherlands also uses an on-demand model, but the Dutch XAF audit file standard is not based on the OECD SAF-T schema — it follows its own XML structure, and mapping between XAF and SAF-T is not straightforward for companies needing to comply with both.

Sweden uses Sweden's SIE accounting data format, the standard for accounting data exchange since the 1980s, rather than adopting SAF-T. SIE bears no resemblance to SAF-T XML schemas.

Penalties for SAF-T Non-Compliance in Norway

Businesses that fail to produce a valid SAF-T file when requested by Skatteetaten face a fixed penalty of NOK 13,450, equivalent to ten rettsgebyr (court fees). This amount is not discretionary or scaled to company size. It applies uniformly whenever a business cannot deliver the required data in the correct format during a tax audit.

A repeat failure within twelve months doubles the penalty to NOK 26,900. The escalation resets after the twelve-month window, but repeated non-compliance across multiple audit cycles can compound reputational risk with the tax authority beyond the financial penalty itself.

One exemption exists. No penalty applies if the business can demonstrate that non-compliance resulted from circumstances genuinely beyond its control. In practice, this is a narrow defense. System migrations, vendor delays, or internal resource constraints rarely qualify. The burden falls on the business to prove the circumstances were truly unavoidable, not merely inconvenient.

The on-demand nature of Norway's SAF-T model creates a deceptive risk profile. Because Skatteetaten only requests SAF-T files during audits or specific inquiries, businesses may operate for years without ever generating one. The penalty risk materializes only at the point of an audit request, and by then it is too late to address underlying gaps in data mapping, chart of accounts alignment, or export functionality. A business that discovers its ERP cannot produce a compliant file has no grace period to fix the problem after receiving a request.

This makes proactive validation essential. The financial penalty itself is modest relative to most corporate budgets, but the inability to produce a SAF-T file during an active audit can trigger extended scrutiny, estimated assessments, and delays that carry far greater cost than the fine alone.

Practical SAF-T Readiness: Preparing for a Tax Audit

Because no routine SAF-T submission exists in Norway, the first real test of your export capability often arrives alongside an audit request from Skatteetaten. Data quality issues, mapping errors, and software incompatibilities surface under tight deadlines. The following steps form a practical checklist for maintaining audit readiness year-round.

Validate your chart of accounts mapping. Every general ledger account must map to the correct GroupingCategory and GroupingCode values under the current v1.30 schema. This mapping is the structural backbone of the SAF-T file. Review it whenever new accounts are created or the chart of accounts is restructured. Run the output through Skatteetaten's published validation tools to catch misclassifications before they accumulate across reporting periods.

Run periodic test exports. Generate a complete SAF-T XML file at least quarterly and validate it against Skatteetaten's XSD schema. Do this after any major system change as well, whether that is an ERP upgrade, a module migration, or a change in accounting policy. A quarterly cadence catches drift early. Waiting until an audit request arrives to discover that your export has been broken for eighteen months is an avoidable failure.

Verify master data completeness. Customer, supplier, and account records must carry complete address fields and all required identifiers. Blank or partial address data is one of the most common reasons SAF-T files fail Altinn validation. Periodically audit master data for completeness, paying particular attention to records created through automated imports or API integrations where field mapping may be incomplete.

Consolidate multi-system data. Many organizations run accounting data across multiple platforms, such as a primary ERP alongside a separate invoicing tool, expense management system, or payroll application. If relevant financial data lives outside the main ledger, establish a documented process for consolidating it into a single SAF-T XML file. The standard expects one file per company per period, not fragments from disparate systems. The quality of your SAF-T output is bounded by the quality of your source data: invoices with inconsistent supplier details, missing VAT identifiers, or incomplete transaction references will propagate those gaps into the SAF-T file.

Keep SAF-T tax code mapping aligned with mva-melding. The same tax code mapping that drives your digital VAT return also underpins the SAF-T audit file. When these mappings diverge, errors compound across both compliance obligations. Any update to VAT codes for the mva-melding should trigger a corresponding review of the SAF-T export configuration.

Monitor Skatteetaten's open-source resources. The Norwegian tax authority publishes schemas, code lists, validation APIs, and example files on GitHub at github.com/Skatteetaten/saf-t. API documentation is available at skatteetaten.github.io. This level of government transparency in tax technology is uncommon in Europe. Use it. Subscribe to repository updates to catch schema revisions and new validation rules as they are released rather than discovering them during an audit.

Prepare for EHF e-invoicing. Norway is proposing mandatory B2B e-invoicing using the EHF format, with sending obligations targeted for 2028 and receiving obligations for 2030. Structured electronic invoices will feed cleaner source data into SAF-T generation, and organizations investing in SAF-T readiness now are building infrastructure that serves both obligations. Denmark has already moved in this direction with its mandatory digital bookkeeping rules under Bogføringsloven.

Secure Altinn access before you need it. When an audit request arrives, the SAF-T file is submitted through the Altinn portal. Verify that your organization is properly registered on Altinn and that authorized personnel hold the necessary digital certificates or delegated access rights. Testing this access path during a routine quarter is far preferable to troubleshooting portal permissions while a Skatteetaten deadline is running.