Norwegian SAF-T testing for software vendors

Test the SAF-T exports your product generates before release, locally or in CI. Saftlint checks the structure against the matching official XSD and runs documented content checks for SAF-T Financial 1.40.

What should Norwegian SAF-T testing cover?

1. Profile and structure. Identify the declared version and validate namespace, element order and data types against the matching XSD.
2. References and mappings. Check that accounts, customers, suppliers, tax codes and other references resolve against the relevant master data.
3. Totals and balance. Reconcile declared counts and totals with the exported lines, and verify that every transaction balances.
4. Periods. Compare dates, Period and PeriodYear with the file's SelectionCriteria.
5. Regressions. Rerun representative exports and deliberate failure cases on every change and release.

Read about XSD versus semantic validation, testing VAT-code mappings and inspect the full documented rule catalogue.

When the XSD passes but the content is wrong

A SAF-T file can conform to the XML schema while containing a broken reference or an unbalanced transaction. A semantic test layer turns those internal inconsistencies into reproducible findings.

Official XSD  ✓ PASS
Saftlint       ✕ ledger.transaction.balance

See the rule and investigation guidance.

Regression testing locally and in CI

Keep representative, synthetic SAF-T fixtures in the product test suite. Pin the Saftlint version and expected result so exporter changes become visible before production release.

saftlint validate testdata/valid-1.40.xml
saftlint validate --json testdata/unbalanced-1.40.xml

Read more about Norwegian SAF-T validation in CI and the native Saftlint CLI.

Test 1.30 and 1.40 as separate profiles

Saftlint identifies and validates both 1.30 and 1.40 against their matching XSD. Full content validation is implemented for 1.40; 1.30 is limited to profile detection and XSD. A passing 1.30 result is therefore not semantically equivalent to a passing 1.40 result.

Is your Norwegian SAF-T 1.40 export production-ready for 2027?

For the 2027 financial year, 1.40 becomes the only valid format. The Norwegian Tax Administration's documentation establishes the deadline. Run a local, pinned check against a representative test export before releasing the implementation.

From release check to maintained dependency

A defect in one export implementation can affect files from many customer businesses. Saftlint packages the test knowledge as a maintained, versioned dependency instead of something every product team builds alone.

If your software also receives SAF-T

Use Saftlint as a diagnostic check before further processing: identify format and version, distinguish unreadable, unsupported and nonconformant files, and see which checks could run. Saftlint does not repair the file or decide that it is safe to import.

Local testing with Saftlint

• Run locally. Financial data stays in your environment.
• Run in CI. Catch regressions before release.
• Pin the ruleset. The same rules produce the same result in reproducible builds.
• Receive maintained releases. Checks, fixtures, code lists and SAF-T versions are updated together.
• Dispute a finding. We investigate the source, document the interpretation and turn resolved cases into regression tests.

Web validator or local evaluation?