Fyrn
Back to blog
nordiccompliance

SAF-T and SIE Compliance: Automating Nordic Tax Reporting Across Systems

How to automate SAF-T (Norway) and SIE (Sweden) tax file generation from multiple source systems instead of manual XML and text file exports.

Fyrn Engineering ·

If you run a business in Norway, you must produce SAF-T files on demand. If you run a business in Sweden, you almost certainly deal with SIE files daily. These aren’t optional — they’re the formats your tax authority expects, your auditor requires, and your accounting ecosystem depends on.

For companies running a single accounting system, this is straightforward — Tripletex exports SAF-T, Fortnox exports SIE. But for companies with multiple data sources — separate billing systems, e-commerce platforms, payroll systems, project management tools — generating a complete, accurate tax file becomes an integration problem.

SAF-T: Norway’s Standard Audit File

SAF-T (Standard Audit File for Tax) has been mandatory in Norway since January 2020 for businesses with turnover above 5 million NOK. Since January 2025, version 1.30 is required.

What SAF-T Contains

A SAF-T file is an XML document containing a company’s complete financial data for a given period:

<?xml version="1.0" encoding="UTF-8"?>
<AuditFile xmlns="urn:StandardAuditFile-Taxation-Financial:NO">
  <Header>
    <AuditFileVersion>1.30</AuditFileVersion>
    <AuditFileCountry>NO</AuditFileCountry>
    <AuditFileDateCreated>2026-01-04</AuditFileDateCreated>
    <SoftwareCompanyName>Fyrn</SoftwareCompanyName>
    <SoftwareID>Fyrn Integration Platform</SoftwareID>
    <SoftwareVersion>2.0</SoftwareVersion>
    <Company>
      <RegistrationNumber>987654325</RegistrationNumber>
      <Name>Example AS</Name>
      <!-- ... -->
    </Company>
    <SelectionCriteria>
      <SelectionStartDate>2025-01-01</SelectionStartDate>
      <SelectionEndDate>2025-12-31</SelectionEndDate>
    </SelectionCriteria>
  </Header>

  <MasterFiles>
    <GeneralLedgerAccounts>
      <Account>
        <AccountID>1500</AccountID>
        <AccountDescription>Kundefordringer</AccountDescription>
        <StandardAccountID>1500</StandardAccountID>
        <AccountType>GL</AccountType>
        <OpeningDebitBalance>125000.00</OpeningDebitBalance>
        <ClosingDebitBalance>142500.00</ClosingDebitBalance>
      </Account>
      <!-- ... all accounts ... -->
    </GeneralLedgerAccounts>

    <Customers>
      <Customer>
        <CustomerID>C-1001</CustomerID>
        <Name>Customer Company AS</Name>
        <RegistrationNumber>123456789</RegistrationNumber>
        <!-- ... -->
      </Customer>
    </Customers>

    <Suppliers><!-- ... --></Suppliers>
    <TaxTable><!-- ... --></TaxTable>
  </MasterFiles>

  <GeneralLedgerEntries>
    <NumberOfEntries>4521</NumberOfEntries>
    <TotalDebit>8945230.50</TotalDebit>
    <TotalCredit>8945230.50</TotalCredit>
    <Journal>
      <JournalID>GL</JournalID>
      <Description>General Ledger</Description>
      <Transaction>
        <TransactionID>2025-001234</TransactionID>
        <TransactionDate>2025-03-15</TransactionDate>
        <Description>Invoice #INV-2025-0042</Description>
        <Line>
          <RecordID>1</RecordID>
          <AccountID>1500</AccountID>
          <DebitAmount><Amount>12500.00</Amount></DebitAmount>
          <CustomerID>C-1001</CustomerID>
        </Line>
        <Line>
          <RecordID>2</RecordID>
          <AccountID>3000</AccountID>
          <CreditAmount><Amount>10000.00</Amount></CreditAmount>
        </Line>
        <Line>
          <RecordID>3</RecordID>
          <AccountID>2700</AccountID>
          <CreditAmount><Amount>2500.00</Amount></CreditAmount>
          <TaxInformation>
            <TaxCode>3</TaxCode>
            <TaxAmount><Amount>2500.00</Amount></TaxAmount>
          </TaxInformation>
        </Line>
      </Transaction>
      <!-- ... thousands more transactions ... -->
    </Journal>
  </GeneralLedgerEntries>
</AuditFile>

A full-year SAF-T file for a mid-size company can be 50-500 MB of XML. It includes every general ledger transaction, every customer, every supplier, every account, and every tax entry for the period.

When Skatteetaten Asks

SAF-T in Norway follows an on-demand model. You don’t submit SAF-T files regularly — Skatteetaten (the Norwegian Tax Administration) requests them during audits or investigations. When they ask, you must produce the file promptly and accurately.

This creates a latent compliance risk: if your data is spread across multiple systems and you haven’t automated SAF-T generation, you’re in a scramble when the request arrives.

SIE: Sweden’s Accounting Standard

SIE (Standard Import Export) is a Swedish standard maintained by SIE-Gruppen since 1992. It has near-100% coverage in Swedish bookkeeping software — Fortnox, Visma, Bjorn Lunden, and essentially every other Swedish accounting system supports it.

SIE Format

Unlike SAF-T (XML), SIE is a tagged text file format. It’s simpler but less structured:

#FLAGGA 0
#FORMAT PC8
#SIETYP 4
#PROGRAM "Fyrn" 2.0
#GEN 20260104
#FNR 1
#ORGNR 5567778899
#FNAMN "Example AB"
#RAR 0 20250101 20251231
#RAR -1 20240101 20241231
#KPTYP BAS2023

#KONTO 1500 "Kundfordringar"
#KONTO 2610 "Utgaende moms 25%"
#KONTO 3000 "Forsaljning"
#KONTO 1910 "Kassa"

#IB 0 1500 125000.00
#UB 0 1500 142500.00
#IB 0 2610 -31250.00
#UB 0 2610 -35625.00

#VER A 1 20250115 "Faktura #2025-0042"
{
  #TRANS 1500 {} 12500.00 20250115 "Kundfordran"
  #TRANS 3000 {} -10000.00 20250115 "Forsaljning"
  #TRANS 2610 {} -2500.00 20250115 "Moms 25%"
}

#VER A 2 20250120 "Inbetalning kund C-1001"
{
  #TRANS 1910 {} 12500.00 20250120 "Inbetalning"
  #TRANS 1500 {} -12500.00 20250120 "Kundfordran"
}

SIE has five file types:

TypeContentUse Case
Type 1Year-end balancesAnnual reporting
Type 2Period balancesMonthly/quarterly reporting
Type 3Object balancesCost center reporting
Type 4Full transactionsComplete audit trail
Type 4IImport transactionsImporting entries from external systems

Type 4 is the most common for compliance — it includes every transaction, equivalent to SAF-T’s journal entries.

SIE in Practice

SIE files are used for:

  • Skatteverket submissions — tax declarations reference SIE data
  • Auditor access — auditors request SIE Type 4 files for review
  • System migration — moving between accounting systems (Fortnox → Visma, etc.)
  • Inter-system data transfer — payroll systems export SIE Type 4I to import salary entries into the main accounting system

The Multi-System Problem

The challenge arises when financial data lives in multiple systems:

Revenue data ── Shopify (e-commerce orders)
                Stripe (payment reconciliation)
                CRM (recurring invoices)

Expense data ── Procurement system (purchase orders)
                Corporate card (Pleo, Spendesk)
                Payroll (Hogia, SD Worx)

Accounting ──── Fortnox (Sweden) or Tripletex (Norway)

If all data flows cleanly into the accounting system, SAF-T/SIE generation is the accounting system’s job. But in practice:

  • E-commerce transactions may be aggregated in the accounting system (daily totals) while the source system has individual order details. SAF-T requires transaction-level detail.
  • Payroll entries arrive as monthly journal imports. The detailed employee-level data lives in the payroll system, not the accounting system.
  • Multi-entity operations require consolidated reporting across systems that don’t share a chart of accounts.

Automating SAF-T Generation

A declarative integration approach to SAF-T generation:

flow: saf-t-generation
description: "Generate SAF-T 1.30 file from multiple source systems"
schedule: on_demand  # Triggered by compliance team or API call

sources:
  - system: tripletex
    data:
      - general_ledger_accounts
      - customers
      - suppliers
      - journal_entries
    period: "{{ request.start_date }} to {{ request.end_date }}"

  - system: shopify
    data:
      - order_transactions  # Individual order details not in Tripletex
    period: "{{ request.start_date }} to {{ request.end_date }}"
    filter:
      status: completed

  - system: hogia
    data:
      - payroll_entries  # Detailed salary components
    period: "{{ request.start_date }} to {{ request.end_date }}"

transform:
  # Map all sources to SAF-T 1.30 schema
  header:
    version: "1.30"
    country: "NO"
    company: "{{ config.company }}"
    period: "{{ request.start_date }} to {{ request.end_date }}"

  master_files:
    accounts: "{{ tripletex.general_ledger_accounts | to_saft_accounts }}"
    customers: "{{ tripletex.customers | to_saft_customers }}"
    suppliers: "{{ tripletex.suppliers | to_saft_suppliers }}"

  journal_entries:
    # Merge entries from all sources, deduplicate by transaction ID
    entries: "{{ merge(
      tripletex.journal_entries,
      shopify.order_transactions | to_journal_entries,
      hogia.payroll_entries | to_journal_entries
    ) | deduplicate_by: transaction_id | sort_by: date }}"

  validation:
    - total_debits_equals_credits
    - all_accounts_referenced_exist
    - all_customer_ids_valid
    - vat_amounts_reconcile

output:
  format: saf-t-xml
  version: "1.30"
  schema_validation: strict
  destination: "{{ config.output_path }}/SAF-T_{{ request.year }}.xml"

This config pulls data from three systems, maps everything to the SAF-T schema, validates the output, and produces the XML file. When Skatteetaten asks, you run the flow and deliver the file — not spend two weeks of accountant time manually exporting and reconciling.

Automating SIE Generation

Similar approach for SIE:

flow: sie-generation
description: "Generate SIE Type 4 file from multiple source systems"

sources:
  - system: fortnox
    data: [accounts, balances, vouchers]
    period: "{{ request.period }}"

  - system: shopify
    data: [order_transactions]
    period: "{{ request.period }}"

transform:
  sie_type: 4
  chart_of_accounts: BAS2023
  company:
    org_number: "{{ config.org_number }}"
    name: "{{ config.company_name }}"

  accounts: "{{ fortnox.accounts | to_sie_accounts }}"
  balances:
    opening: "{{ fortnox.balances.opening | to_sie_ib }}"
    closing: "{{ fortnox.balances.closing | to_sie_ub }}"

  vouchers: "{{ merge(
    fortnox.vouchers,
    shopify.order_transactions | to_sie_vouchers(series: 'E')
  ) | sort_by: date }}"

output:
  format: sie
  encoding: PC8  # SIE standard encoding
  destination: "{{ config.output_path }}/SIE4_{{ request.year }}.se"

Common Pitfalls

1. Character encoding. SIE uses PC8 (CP437) encoding by default — a legacy IBM PC encoding. If you generate SIE files in UTF-8, some Swedish accounting software will reject them or display garbled characters. Always verify encoding.

2. Account mapping. SAF-T uses the Norwegian Standard Chart of Accounts (NS 4102). SIE uses the Swedish BAS chart. If your source system uses a custom chart of accounts, you need a mapping table for each target format.

3. VAT reconciliation. Both SAF-T and SIE require VAT amounts that reconcile with the transaction details. If your transactions are aggregated (daily totals from e-commerce) but VAT was calculated per-order, the amounts may not match. Always validate VAT totals.

4. Transaction-level detail. SAF-T requires individual transactions, not summaries. If your accounting system stores daily aggregated entries for e-commerce, you need the source system’s detail to produce a compliant file.

5. Period boundaries. SAF-T and SIE define periods differently. SAF-T uses explicit start/end dates. SIE uses fiscal year indices (0 = current year, -1 = previous year). Ensure your date logic handles both.

The Compliance Automation ROI

For a mid-market company producing SAF-T or SIE files:

ActivityManualAutomated
Data collection from multiple systems2-5 daysMinutes
Reconciliation and validation1-3 daysAutomatic
File generation1 daySeconds
Error correction and re-generation1-2 daysAutomatic with validation
Total per request5-11 working days< 1 hour

When Skatteetaten or Skatteverket comes knocking, the difference between “we’ll have it ready in two weeks” and “here’s the file” is significant — not just for efficiency, but for the confidence it signals to auditors.

Tax compliance is deterministic. The rules are specified. The formats are documented. The data exists in your systems. The only thing missing is the integration pipeline that assembles it automatically. Build it once, run it whenever you need it.