On 8 September 2026 the Danish Business Authority updated its page on the standard chart of accounts and SAF-T. One sentence has changed: from 1 January 2027, registered bookkeeping systems must support version 2.1. Not 2.0.
In issue 2 I wrote that the executive order on system requirements does not mention a version number at all, and that the Authority's news item from February 2026 said 2.0 while the technical documentation described 2.1. One of the two pages has now been corrected. The other is still there — with 2.0.
Three topics in this issue: the version number and the opt-out decision we are still waiting for · green climate data that has to come out of a financial process · and what, in my assessment, Norwegian companies will need when the date hits them.
They end in the same place, and that is why the headline reads the way it does. Dates can move, version numbers can be corrected, and regulations can arrive late. The clean-up of your own master data becomes neither smaller nor easier because of any of it — and it is the only thing in the whole picture where you decide yourself when to get started.
One number has been corrected. The other still stands
Briefly, for those who do not follow it closely: SAF-T is the standard file format in which a bookkeeping system must be able to hand over your bookkeeping. The original intention was to make it easier to switch systems — the bookkeeping must be able to come along out, without the new vendor needing to know the old one's database. That an authority can read the same entries came afterwards. At the same time, the Danish Bookkeeping Act distinguishes between registered systems, where the vendor is liable for the requirements, and non-registered ones, where the company itself is.
Three things are worth having in order after the update on 8 September 2026:
01 — Two pages, two version numbers. The page ["Standardkontoplan og SAF-T"](https://erhvervsstyrelsen.dk/standardkontoplan-saf-t) ("Standard chart of accounts and SAF-T") was updated on 8 September 2026 and now says version 2.1 from 1 January 2027. The page ["SAF-T version 2 og rettelser til standardkontoplanen"](https://erhvervsstyrelsen.dk/saf-t-version-2-og-rettelser-til-standardkontoplanen) ("SAF-T version 2 and corrections to the standard chart of accounts"), updated on 10 February 2026, still says: "From 1 January 2027, the registered bookkeeping systems must support version 2.0." Both pages are publicly available on erhvervsstyrelsen.dk.
02 — The executive order still mentions no version number. The requirement is a standard file as defined by the authorities. That is not an oversight — it is a deliberate construction that makes it possible to update the format without amending an executive order. But it also means the binding content can change without anyone having to be consulted.
03 — The date has not moved. 1 January 2027 stands unchanged on both pages. And for non-registered systems the requirement is still version 1.0 — in practice a header file, that is, a cover sheet without entries.
Where it does not hold
The other decision is still not there. The amendment to the executive order on system requirements — automatic registration in the Nemhandel registry, e-invoicing as the first choice and MitID verification of the entire user base — had a consultation deadline of 17 August 2026. In a notice to the consultation parties on 25 August 2026, which I received as a consultation party, the Authority wrote that the decision had been postponed with reference to the consultation responses, and that the executive order was expected to be issued in mid-September 2026. We are still waiting, and it must be imminent. Note that the draft itself has two dates: the executive order enters into force on 1 January 2027, but the notice ahead of registration in the Nemhandel registry is due as early as 30 November 2026.
And a postponement does not extend the preparation — it shortens it. If the executive order comes later without 1 January 2027 moving with it, there are fewer weeks left for the same work. If the date does move, only those already under way gain. It is worth saying out loud, because postponements are rarely read that way. They are read as permission to wait.
My assessment — the SAF-T version and the postponement
It is reasonable for an authority to correct a version number on a guidance page. It is not reasonable that the correction can only be discovered by laying two pages side by side and seeing that they do not say the same thing. When the executive order deliberately points to "what the authorities have defined", the guidance pages are in effect where the requirement lives — and then the version number should stand in one place and carry a date for what was changed.
But that is not where the big bill lies. The jump from 1.0 to 2.x is not an addition of fields. It is the shift from handing over a cover sheet to handing over the entire bookkeeping at transaction level — master data and entries, that is, chart of accounts, customers, suppliers, VAT codes and dimensions. And that is where a postponement helps no one.
For what is it that actually takes time? Not the code. It is the duplicates in the customer file, the suppliers without a company registration number, accounts that were never mapped to the standard chart of accounts, VAT codes used differently in 2019 and in 2025, and dimensions whose meaning exists only in one person's head. None of it stops you from booking tomorrow. All of it becomes visible the day the file leaves the system.
That is why my advice is the same whatever the Authority lands on: pull a SAF-T extract out of your system in the version it supports today, and read it through. Not to approve it — to see what it says. The day an authority asks for the file is a bad day to discover your own master data.
And if you need a place to start, here it is: a tool that tells you where the file fails. The file does not leave your machine — the validation runs locally in your browser.
The climate figure fails on a field that does not exist
The climate chart of accounts project, which the Danish Business Authority runs together with Ressource City in Næstved, completed its first phase on 12 June 2026 with ten companies and five vendors of bookkeeping systems. The method is the interesting part: the participants' entry extracts for 2025 were pulled out, each entry classified by UNSPSC codes — an international standard for categorising goods and services — and then enriched with emission factors and activity data.
The Authority's own wording is worth dwelling on: it was the first time in the initiative that climate data was derived directly from the companies' existing, booked data. The second phase is about getting the climate chart of accounts into the bookkeeping and ERP systems already in use.
The direction is promising, and there is a figure that explains why. The project description refers to estimates according to which data collection and processing can account for up to 80 per cent of the cost of climate accounts. Note what the 80 per cent is: the share of cost — not how much of the climate data can be derived from financial data. The point is that the reporting itself is the cheap part. The expensive part is getting the figures.
So much for the authorities' side. From those who work with the implementation every day — integrators, warehouse people and ERP consultants — I hear the same thing again and again. It is one problem seen from three sides:
01 — On the invoice, packaging is an amount. In invoice matching, packaging appears as a surcharge line with an amount — that is, a price. But Danish extended producer responsibility and the EU Packaging and Packaging Waste Regulation do not ask for a price. They ask for material and weight, and today the invoice cannot carry that information.
02 — The figure exists in the warehouse — but the warehouse is not the bookkeeping. Warehouse systems have begun registering packaging where it arises: at the packing station, with material, weight and CO2 per gram, and with separate marking of reused boxes. That is the right source. It just sits in a different system from the one the accounts are prepared from.
03 — The fields are a dependency, not a configuration. Packaging and CO2 fields do not yet exist as standard in the bookkeeping systems, and it is not something an integrator can decide their way out of. You are left to follow what the vendor adds — typically through release notes — and in the meantime build user fields, dimensions or a table on the side that has to survive the next upgrade. The figure I most often hear put on the consequence is four to seven systems that have to be run together before anything can be reported.
Where it does not hold
An emission factor is not a number. It is a vintage. The factors are updated. If they are updated across the history, last year's climate figures change without anyone having booked anything. The question to ask your vendor is therefore very concrete: can I reproduce a report with the factor that applied at the time? If the system cannot do that, it is an estimation tool — and that is the whole difference between a figure that holds up in an inspection and a figure that does not.
The data arises in three places and must be reconciled in one. The packaging arises physically at packing, the cost arises on the supplier invoice, and the classification belongs in the chart of accounts. When the three sources disagree, something has to win — and if the disagreement is quietly reconciled away before anyone sees it, the audit trail goes with it. It is the same problem as in the first topic, just with a different field: a figure that cannot be traced back to a transaction is not documented.
And the regulatory picture on top is already moving. The EU Packaging and Packaging Waste Regulation, PPWR, has applied since 12 August 2026 and shifts who in the value chain counts as the producer. Danish extended producer responsibility requires registration and annual reporting per material fraction. And the Omnibus simplification takes listed small and medium-sized enterprises entirely out of CSRD sustainability reporting and raises the threshold for the rest to more than 1,000 employees and EUR 450 million in turnover; the Danish transposition is expected to apply from 1 January 2027. What remains is that the vast majority of Danish companies will not have to report themselves — but will be asked by large customers, banks and tenders. In short: the requirement hits you as a supplier, not as a reporting entity.
My assessment — the green data
Let me first say where I think the potential lies. Deriving the climate figure from the entry instead of collecting it on the side is the cheapest of the paths in play, because it reuses something that has to be right in the first place. It is also the path with the best chance of producing figures that can be compared across companies.
And then there is a real disagreement between the market and the authorities, which I think deserves to be stated without taking sides. The authorities' half: if the climate figure is to be comparable and verifiable, the classification must be uniform all the way down to the entry — otherwise every vendor invents its own. The vendors' half: a chart of accounts is an accounting classification, and an entry tells you what something cost — not what it weighed, what it was made of, or where it physically ended up. If that is to be included, we are not talking about a field but about new master data on thousands of item numbers and warehouse locations. Both are right about their own half.
That is why I think the decisive question should be asked out loud before anyone writes a requirement: should the climate data be derived from the entry, or should it be carried by it? If it is derived, the classification and emission factors can sit centrally and be versioned, and the vendor's task is mapping. If it is carried, every item number needs new master data, and then it is the company that has to supply information it does not have today. The two answers cost very different amounts, and they land on different parties.
The second phase is exactly the place where the question can be answered — it is about getting out into the systems already in use, and it is the vendors who know what that costs. What I would wish for is not that one side gives in. It is that the calculation is laid out before the requirement is written.
Note, by the way, that the first two topics hit the same problem in different variations. In the SAF-T extract, it is the chart of accounts, the customers, the suppliers and the VAT codes that have not been cleaned up. In the climate figure, it is material and weight per item number, which have never been registered anywhere. Different fields, same deficiency: master data that is good enough to book with, and that only falls through the day it has to leave the system and be read by someone else.
Norway has not reached the green data at all yet — there, it is about the e-invoice and a regulation that has not been issued. But the third variation is already waiting: the customer register, and whether it can answer who is able to receive an invoice at all.
Norway is waiting for the regulation. The preparation cannot wait
In issue 3 I wrote that Norway has the calendar and is missing the content. That picture is unchanged: the obligation to send e-invoices between companies applies from 1 January 2027, and the format rules are to be laid down in a regulation, by December at the latest.
On 3 September 2026 I attended the samhandlingsarena (collaboration forum) in Oslo, where the theme was the government's simplification strategy and its vision "fra plikt til flyt" ("from obligation to flow"). I took three things home, and they are all about what happens after the date:
01 — The conversation is no longer only about the invoice. Peppol — the network the e-invoice is sent through — was built for the documents of public procurement, but today it also carries logistics documents. A large part of the day was about freight and delivery documentation, not about bookkeeping. The e-invoicing track Norway starts in 2027 is thus the entrance to something broader than what the law is about.
02 — "From obligation to flow" is a point, not a headline. The practical content is that the obligation only pays off when data can move on by itself. An e-invoice that lands as an attached file and has to be keyed in has cost the sender a transition and saved no one anything.
03 — The liability question has no address yet. I asked from the floor who is liable when an EHF invoice is wrong — the access point that transported it, or the system vendor that generated it. Under the current rules, the answer is the individual company. That is worth holding on to, because it is also the answer in Denmark for the non-registered systems.
Where it does not hold
The reach of the obligation depends on a register, not on a rule. According to the preparatory works, you must send e-invoices to the counterparties listed in ELMA, the Norwegian recipient register run by the Norwegian Digitalisation Agency. That answer sits in the bill — not in the Act, and not yet in any regulation. It is a poor place for the information that determines whom you are required to send to at all.
And the receiving side comes in a separate round. The Ministry has announced transitional rules under which the receiving obligation only has to be met on 1 January 2030, when the requirement for an electronic accounting system also enters into force. If you build only for sending in 2027, you will have to build again in 2030.
And the vendor question is still a question. The review of whether accounting systems and their vendors should be regulated is due on 15 December 2026. If it comes out as a Danish-style registration track, part of the work moves from the company to the vendor. If it does not, it stays where it is. No company can wait for that answer — but everyone can ask their vendor what the vendor expects.
My assessment — Norway after the date
I am a Danish adviser, not a Norwegian lawyer; I read their documents the way I would read ours. But the question of what to do when you cannot yet read the rule is not a legal question. It is an operational question, and there are four things I think Norwegian companies will need.
A clean customer register with organisation number and ELMA status. It is the one preparation that can be done now, because it does not depend on the regulation: which of my customers can receive, with which identifier, and how many of my customer records are duplicates. It is not a project. It is a clean-up — and it is the same one Danish companies have to do for SAF-T.
A written answer on who is liable. When the rule does not place the responsibility with the access point or the vendor, it rests with the company. So the company should buy it back in the contract: what does the system vendor guarantee about the format, what does the access point guarantee about delivery, and who documents that the invoice arrived.
An archive in the original format. The Act requires an e-invoice to be stored in the format in which it arrived. If the system converts incoming invoices to its own format and stores the result, the requirement is not met — and it enters into force together with the sending obligation.
And a plan that counts 2030 in from the start. Two dates, one system. It is cheaper to build the receiving side into the architecture now than to build it on top in 2030.
Then there is what I do not know, and it is worth saying out loud: I do not know the wording of the regulation, and I may be wrong about how narrow the scope for exemptions turns out to be. But none of the four things above becomes wrong, however the regulation lands. That is exactly why they are worth starting on.
And with that, the three topics are the same topic. A version number can be corrected, an executive order can be postponed, a regulation can arrive late, and a climate requirement can end up being written one way or the other. The data quality in your own system is the only preparation that is never wasted, whichever way the decisions fall.
In the works
I have been invited to give a talk for Regnskap Norge's members in October 2026 on what Denmark learned from going first. I will share the experience from it here in the newsletter — and if you would like to hear more already now, you are welcome to [book half an hour](https://book.strukturacompliance.dk/kbr/30min).
Today the SAF-T validator reads your file and tells you where it fails. I am working on letting it say more: what in your master data falls away when the file has to carry 2.x instead of a header file. If you are interested in it, write to me, and I will let you know when it is ready.
And then there are the conversations with European companies in the middle of the requirements — what it cost, what they underestimated, and what they would do differently. Those appear only here.