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.

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:

1. The business uses an electronic bookkeeping system (ERP, accounting software, or any digital ledger), AND
2. 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 SAF-T Norway chart of accounts 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 documentation barriers are less severe than they once were. Skatteetaten has published English-language guidance specifically addressing SAF-T obligations for foreign businesses, and the technical documentation for the XML schema is available in English. Still, certain regulatory nuances, interpretive guidance, and updates may appear in Norwegian first, creating a lag for non-Norwegian-speaking compliance teams.

All SAF-T submissions flow through Altinn, Norway's digital government services portal. Foreign entities must register for Altinn access, which involves obtaining a Norwegian organization number and setting up the appropriate digital credentials. For companies without a physical presence in Norway, this registration process itself 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

The OECD published the original SAF-T standard in 2005 as a recommended framework for tax audit data exchange. Each adopting country has adapted it differently, and several European nations use entirely separate formats that serve a comparable purpose. Understanding these differences matters for any finance team operating across borders, because compliance obligations vary dramatically in frequency, format, and scope.

Norway's model is distinctive in one critical respect: SAF-T files are generated on demand, not submitted routinely. Businesses maintain SAF-T-ready data in their accounting systems and produce the file only when Skatteetaten requests it during an audit or control action. This contrasts sharply with countries that have turned audit file submission into a regular reporting obligation.

The following comparison highlights how four European approaches differ from Norway across the dimensions that matter most to practitioners.

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 represents the most intensive routine compliance model in Europe. Since 2013, businesses must submit SAF-T files monthly to the Autoridade Tributária. Billing software must be certified by the tax authority, and every invoice carries a unique ATCUD (Código Único de Documento) identifier. The combination of mandatory certification, monthly submission, and per-invoice tracking codes creates an ongoing compliance workload that Norway's on-demand approach deliberately avoids. Organizations operating in both countries can find a detailed breakdown of Portugal's SAF-T compliance framework, including its four distinct file types and certified software rules.

Poland's JPK (Jednolity Plik Kontrolny) took the SAF-T concept further than any other country by replacing the traditional VAT return with a SAF-T-based file in 2020. Polish businesses submit JPK_VAT files monthly or quarterly depending on their size, making the audit file itself the primary tax reporting mechanism. Norway's digital VAT return shares the conceptual link between SAF-T codes and VAT reporting, but Norway keeps these as two separate processes rather than merging them into a single submission.

The Netherlands uses an on-demand model that superficially resembles Norway's approach, but the underlying format is entirely different. The Dutch XAF audit file standard is not based on the OECD SAF-T schema. The Auditfile Financieel follows its own XML structure, and version 4.0 actually reduced the number of required data elements. Businesses produce XAF files when the Belastingdienst requests them, but mapping between XAF and SAF-T is not straightforward for companies that need to comply with both.

Sweden takes yet another path. Rather than adopting SAF-T, Sweden's SIE accounting data format has been the standard for accounting data exchange since the 1980s. SIE (Standard Import Export) is deeply embedded in the Swedish accounting software ecosystem and serves a similar audit-readiness function within the Nordic region, but its structure bears no resemblance to SAF-T XML schemas.

Two characteristics set Norway apart. First, Skatteetaten publishes open-source validation tools that businesses can run against their SAF-T files before any audit request arrives, enabling proactive compliance checking rather than reactive scrambling. Second, Norway's integration of SAF-T codes into the digital VAT return (mva-melding) creates a feedback loop: the same standardized account coding that structures the audit file also drives routine VAT reporting, which means businesses that maintain clean SAF-T mappings gain accuracy in both obligations simultaneously.

---

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 the broader digital compliance trajectory. Norway is proposing mandatory B2B e-invoicing using the EHF format, with sending obligations targeted for 2028 and receiving obligations for 2030, alongside digital bookkeeping requirements — a trajectory that mirrors Denmark's mandatory digital bookkeeping rules under Bogføringsloven, which already requires registered bookkeeping systems and immutable audit trails. Structured electronic invoices will feed cleaner source data into SAF-T generation compared to PDF-based workflows. SAF-T and EHF e-invoicing together form Norway's dual digital compliance ecosystem, and organizations investing in SAF-T readiness now are building infrastructure that serves both obligations.

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.