Denmark’s Business Authority has now formalised SAF-T 2.0 as the next step in Denmark’s digital bookkeeping architecture—an upgrade that is less about “a new file format” and more about what the state expects accounting systems to be able to extract and exchange.  

What Changed Versus SAF-T 1.0 

In SAF-T 1.0, the only mandatory section was Header (1..1). Everything else—MasterFiles, GeneralLedgerEntries, and SourceDocuments—could be omitted (0..1).  

In SAF-T 2.0, Denmark flips that baseline: 

• Header stays mandatory (1..1) 

• MasterFiles becomes mandatory (1..1) 

• GeneralLedgerEntries becomes mandatory (1..1) 

• SourceDocuments remains optional (0..1)  

This is the real modernization: Denmark is no longer describing SAF-T as a “file you can produce if asked,” but as a standardized, transaction-level data extract that accounting systems must be able to generate consistently. 

Why “SourceDocuments” stays optional (and why you should still care) 

Keeping SourceDocuments as 0..1 means Denmark is not forcing every taxpayer/system to provide full document-level subledgers (sales invoice lists, purchase invoices, payments, goods movements, etc.) as a universal minimum—at least not yet.  
But the practical message is still clear: the mandatory minimum is now strong enough to reconstruct the ledger story through master data + journal entries. 

Reading the SAF-T 2.0 Structure: 

Header (1..1) 

This is the identity + context layer: who the file belongs to, what period it covers, and how it should be interpreted. It was mandatory before and remains mandatory now.  

MasterFiles (now 1..1) 

This section is the dictionary that makes transactions intelligible and comparable. In your diagram, MasterFiles contains structured reference data such as: 

• General ledger accounts 

• Customers / suppliers 

• Tax table 

• Products and units of measure 

• Assets / physical stock 

• Taxonomies and analysis/movement type tables 

Because it is now mandatory, SAF-T 2.0 is effectively saying: transaction data without standardized reference data is not “audit-ready.”  

GeneralLedgerEntries (now 1..1) 

This is the transaction backbone—journal entries and ledger postings at a level that enables traceability, reconciliation, and control testing. Making this mandatory is what upgrades SAF-T from “sometimes extractable” to operationally reliable for supervision, assurance work, and standardized reporting pipelines.  

SourceDocuments (still 0..1) 

Where present, this is where you can attach the “subledger proof layer” (e.g., sales invoices, purchase invoices, payments, movement of goods, asset transactions). Optional does not mean irrelevant—just not part of Denmark’s mandatory minimum dataset today.  

Why Denmark Is Doing This: Reuse, Automation, and Less “One-Off Reporting” 

Denmark’s broader direction is to make bookkeeping data more uniform and consistently exchangeable—not just for authorities, but also for advisors and third parties. Standardisation is explicitly positioned as an enabler for automation and easier data sharing.  

SAF-T 2.0 supports that direction by ensuring that the “baseline extract” contains: 

• the reference model (MasterFiles), and 

• the actual postings (GeneralLedgerEntries), 

so that downstream users (auditors, regulators, analytics tooling, reporting workflows) are not forced to interpret a half-empty structure. 

Implementation Scope: Who Must Support SAF-T 2.0, and When 

Denmark is applying this through the digital bookkeeping system ecosystem: 

Registered digital accounting system providers 

From 1 January 2027, registered bookkeeping systems must support SAF-T version 2.0.  

Non-registered systems 

Non-registered systems can continue to support SAF-T 1.0 (a header file)—meaning they are not forced into immediate migration.  

This is a classic phased strategy: force capability into the standardized system market first, while avoiding a sudden “rip-and-replace” mandate for every bespoke setup. 

What This Means Operationally 

For system providers: “Export” becomes a product requirement, not a feature 

When MasterFiles + GeneralLedgerEntries are mandatory, vendors must treat mapping/versioning/testing as core functionality. A broken chart-of-accounts mapping is no longer a cosmetic bug—it breaks the meaning of the entire extract. 

For companies: data quality becomes compliance posture 

SAF-T 2.0 will surface weak master data fast: inconsistent customer IDs, messy VAT coding, mismatched account structures, incomplete product tax logic. The more Denmark pushes standardised exchange, the more data hygiene becomes the real control layer. 

---