The consultation deadline for the Danish Business Authority's amendment of the requirements order for digital standard bookkeeping systems expired on 17 August 2026. Now the authority has to read what it received.
The interesting part is not that a consultation memorandum will follow. One always does. The interesting part is which objections are accommodated — and which are merely noted without anything happening. The two look identical on paper, and the difference between them is the whole difference for whoever has to build the system.
I submitted a consultation response of my own with seven remarks. Below I take three topics: what is proposed, what in my assessment does not hold, and what I would do myself.
And then there is the date. However the authority lands the three topics, they converge in one place: December 2026. That is when the entire market must be notified, objections must be handled, and everything must be ready for 1 January 2027 — in the one month when both the vendors' support desks and the customers' bookkeeping departments are half closed. These are not three independent matters. They are three matters with the same due date.
Enrolment happens by itself
Briefly, for those not following closely: the Danish Bookkeeping Act distinguishes between registered and non-registered bookkeeping systems. For the registered ones, it is the vendor's responsibility that the system meets the requirements. For the non-registered ones, it is the company's own. This amendment concerns only the registered systems — which becomes important towards the end.
The draft enters into force on 1 January 2027 and does three things.
01 — The vendor enrols the customers. Under the current rules, the system must make it possible to join the Nemhandel registry. The customer is asked and says yes. Under the draft, the vendor must enrol its customers unless the company actively opts out. Passivity becomes the very basis of enrolment.
02 — The system must point to e-invoicing first. When invoicing, the system must look up the Nemhandel registry and present electronic delivery as the first option when the recipient is registered.
03 — MitID across the entire user base. The identity of new and existing customers, end customers and users must be confirmed with MitID. Add mandatory master data on outgoing documents, and locked fields that can henceforth only be edited on virk.dk.
Where it does not hold
The timeline cannot be met as written. The notification duty enters into force on 30 November 2026. The company has four weeks to object. Enrolment must be completed by 1 January 2027. If the notice is sent on the first possible day, the objection window expires on 28 December 2026, leaving the vendor three days to enrol its entire customer base. Sent ten days later, the provision cannot be met at all.
Then consider what the task actually is. The authority's list holds more than a hundred registered systems, and together they count the bulk of Danish business as customers. Each vendor has five weeks to notify its entire base, receive and record objections from those who decline, and enrol the rest in a central registry — in the part of the year when both their own support and their customers' bookkeeping departments are shut down. That is not a technical task. It is a logistical one.
And who actually receives the notice? The right to say no belongs to the end customer — the company subject to the bookkeeping obligation. But the draft only says the notice must be given "by direct message", not through which channel. In a large part of the market, it is the accountant or the bookkeeping firm that uses the system, and the owner never logs in. Delivered in the user interface, the notice reaches the bookkeeper — not the party holding the right to say no.
The lookup points to one registry, not to the infrastructure. By the authority's own technical description, the Nemhandel registry is a central SMP — one of several possible address services in the Peppol architecture. The general route to finding a recipient runs through the SML to whichever SMP the recipient is attached to. A recipient who is fully reachable in the infrastructure but registered elsewhere therefore does not trigger the first-choice rule. To the user, it looks like the system cannot send electronically to someone who can receive electronically.
And then MitID. The requirement is sensible in its aim. But let us say it as it is: in practice MitID is used through an app, and that app lives in two stores — Apple's and Google's. The alternative is the code display device, which works, but which no vendor wants to build an onboarding flow around. So we have a requirement meant to strengthen control over Danish companies' data — delivered through two American platforms. I am not pointing this out to be difficult. I point it out because sovereignty is something you lose in small steps, and because it is rarely mentioned when the requirements are written.
My assessment — the requirements order
The direction is right. Opt-out is, in my assessment, the single measure that can actually move e-invoicing adoption, and adoption is the entire premise of the gain — an e-invoice is only worth something if the recipient can receive it. The authority should stand firm on this, also when the pushback comes.
What I would change is the timeline — and of my seven points, that is the one I most want accepted. Either the notification duty is moved forward, or enrolment is tied to four weeks after the notice rather than to a fixed date of 1 January 2027. As it stands, the objection window is formally four weeks and in reality somewhat shorter — and the legal effect of missing it is that you are enrolled in a public infrastructure without ever having taken a position.
And if I sat at a vendor today, I would not start with the code. I would start by finding out who we even have to notify. Do we know which of our users are end customers, and which do the books for others? Do we have a way to reach those who never log in? It is tedious mapping work that cannot be demoed to anyone and produces no release notes. Which is probably why it has not started in many places.
Two version numbers, two deadlines, no validation
On 15 June 2026, the Danish Business Authority sent an amendment to SAF-T into consultation with a deadline of 29 June 2026. Two responses came in. Two — on a change that affects every registered bookkeeping system in Denmark. The memorandum with the authority's answers followed on 3 July 2026.
It is worth reading, because it is one of those places where you can watch an authority think out loud.
The centrepiece is the Deductibles field, which splits the VAT amount on the individual entry line into a deductible and a non-deductible part. It was originally proposed as mandatory. After the consultation, the authority proposes MIFU — mandatory if used — with a deadline of 1 January 2027, and then mandatory from 1 January 2028. Note that this is the memorandum's proposal — the change has not been adopted yet.
What the authority answered — and what it did not
The authority accommodated two things. The naming clash is fixed: the element was called DeductibleAmount and collided with the field inside its own structure, so it will be renamed Deductibles. And the requirement is split across two deadlines, so systems that do not yet support the split get time "to find a good solution".
Two things were not accommodated. It was requested that the XSD schemas be published during the consultation, so vendors can test the consequences while there is still time to respond. The authority cannot promise this, but will work towards it.
And schematrons were requested — the rule files that make it possible to machine-check whether a file actually complies with the standard beyond what the schema itself catches. The answer is short: "There are currently no plans to produce and release schematrons; the request has been noted."
Add to that what I wrote about in the last issue and raised in my own consultation response: the requirements order does not reference a version number at all, but "a standard file as defined by the authorities". The authority's February news item says 2.0 from 1 January 2027; the authority's own technical documentation describes the standard as 2.1. Both are true, and neither is in the order.
My assessment — SAF-T 2.1
The biggest thing in SAF-T 2.x is not Deductibles. It is the leap from 1.0.
Under the current 1.0, a company can get by with producing a header file — in effect a cover sheet. With 2.0, Masterfiles and GeneralLedgerEntries become mandatory. From a cover sheet to the full master data and ledger extract. Add the MIFU concept, a set of fields tied directly to the requirements order, fields intended for reporting to the Danish Tax Agency and Statistics Denmark, and a new handling of empty values.
For a vendor, that is not an addition. It is a rewrite of the export layer — which is what the consultation response meant when it said large parts of the system would have to be rewritten.
For a company it means something different and more concrete: the day you are selected for an audit, the difference between 1.0 and 2.x is the difference between handing over a cover sheet and handing over your entire bookkeeping at transaction level. It is worth having reviewed your own extract before then — not because something is necessarily wrong, but because that is a bad day to find out.
The schematron answer is what worries me most. Without a binding, versioned test suite, a standard format gets filled in differently by every vendor. The result is files that each comply with the schema but cannot be compared or processed automatically at the receiving end — precisely not the automation the whole exercise exists for. Leaving that part to the market means, in practice, that every vendor builds its own interpretation and discovers the disagreement the day an authority reads the files side by side.
Here I think the authority should reconsider. Not because prioritising is unreasonable — but because a standard without a common test is not a standard. It is a recommendation.
2027 will be the year of empty fields. Deductibles becomes MIFU, so it only has to be filled in by those who hold the information. At the same time, it is the year vendors must build the split everyone has to deliver the year after. That is a sensible staircase, if you use it. If you do not, 1 January 2028 becomes a wall.
And there is a point of principle no one has addressed: the split is not a fixed quantity. The deduction percentage under section 38 of the Danish VAT Act is provisional through the year and is only adjusted at year-end, so the line split in the file is a snapshot. The file validates impeccably — but it and the VAT return do not tell the same story until the adjustment has been booked.
Because no schematrons are coming, I built a validator. You drag your SAF-T file into the browser and are told where it fails. The file never leaves your machine — validation runs locally in the browser. The result is free and fully visible.
Denmark is waiting for a specification it does not control
OIOUBL 3.0 was abandoned, and Denmark is moving to Peppol instead — specifically to PINT, Peppol's international model, with national extensions on top. The Danish result will be called Nemhandel Faktura. The authority is candid about why: it "does not wish to use naming owned and controlled by private actors", pointing out that Norway does the same with EHF and Singapore with InvoiceNow.
The transition is confirmed in the consultation memorandum of 27 May 2026, which addressed twelve consultation responses.
Three things that are not solved
The timeline hangs on a specification the authority does not own. The migration is set at 18 months, split evenly between testing, phase-in and phase-out, and the clock only starts when Nemhandel Faktura goes into production. That can only happen once OpenPeppol has published the underlying specification — work the authority does not control. The authority writes that the 18 months in total "can only be extended with difficulty", and the far end is locked by ViDA, which requires cross-border e-invoicing in the EU from 1 July 2030. If the starting gun slips, the whole sequence slips — and there is no slack at the other end.
The national extensions have been deemed necessary, not avoided. The consultation responses asked for the opposite: as few Danish special requirements as possible. The authority's assessment is that adaptations are necessary to secure data quality and preserve functionality. That is probably true. But then the question is not whether there will be Danish particularities, only how many — and the governance mechanism meant to keep the extensions in check afterwards does not yet exist.
Here I miss one number no one has put forward: what will it cost Danish business to build, maintain and use the special fields? Not the price of the migration itself, but the running cost of having a national variant of an international format. That bill is paid by the vendors first and the companies after, and I think the authority should calculate it and put it on the table before the extensions are fixed. It is not an argument against adaptations. It is an argument for knowing what they cost.
And the invoice is only the first document. The strategy takes the invoice first, but Nemhandel today carries an entire portfolio: orders, catalogues, credit notes, reminders, utility specifications and response documents. The authority expects the related documents to continue unchanged, while also writing that no decision has been made to upgrade them. The same goes for the public procurement documents, where Denmark is already committed to Peppol standards. Each of those documents raises the same question about national extensions once more — and the governance mechanism meant to answer it has still not been built.
My assessment — OIOUBL and Peppol
Let me first explain how the chain fits together, because it is not obvious from the outside.
At the bottom sits the standard chart of accounts: it determines how an entry can be classified. On top of it sits SAF-T, the file in which the entries leave the system. And on top of that sits everything that derives something from the numbers — the VAT return, Regnskab Basis, Statistics Denmark's extracts. The e-invoice feeds the other end: that is where the entries come from. In short, the entire automation agenda rests on the two formats and the chart of accounts fitting together.
The authority's own climate chart-of-accounts project is the best illustration. It completed its first phase in June 2026 with ten companies and five system vendors, and its whole point is that climate figures are derived from booked entries instead of being collected on the side. That only works if the classification at the bottom is stable. When the chart of accounts, the file format and the invoice format are all moving at once, everything on top inherits the movement — including projects that otherwise have nothing to do with e-invoicing.
And then there is the group no one talks about. Both the requirements order and SAF-T 2.x hit only the registered systems. That sounds reasonable, until you look at who is left outside.
The authority's own list holds a good hundred systems — Dynamics 365, e-conomic, Visma, Uniconta, Odoo, Xledger and many more. But SAP is not on it. Neither are Sage, NetSuite or Oracle. In other words: a fair share of the systems running Denmark's largest groups and their foreign sister companies sit in the non-registered track. Add custom-built systems — a group that will not shrink, now that it has become realistic for an ordinary company to build its own with AI assistance. That is precisely the flexibility the order for non-registered systems was written to allow.
Those companies must still be able to send and receive e-invoices, and it is they themselves — not a vendor — who are liable. Yet nowhere does it say how they should relate to the requirements now being imposed in the other track, or when something similar will reach them.
I think that is a mistake, and a bigger one than it looks. A company pushed into an unplanned migration away from its group system and onto a registered standard system that cannot do what the business needs is not facing an IT task. It is facing a risk to its entire operation. You cannot impose vendor regulation on a company that built its own system — that would be wrong. But you can tell it what you have in mind.
Add the asymmetry in the infrastructure itself: the same e-invoice can be sent into the same infrastructure, in one case after MitID identification and with locked master data from the CVR register, in the other with neither. The access points transporting the documents cannot tell the difference — they see two valid documents. If identity assurance is the justification for the requirement in one track, one should be able to explain why it is unnecessary in the other.
What I would hold on to if I sat on the other side of the table: opt-out, the shared infrastructure, and the transition to Peppol. Those three are right, and they will come under pressure because they are inconvenient in the short term.
What I would give ground on: the timelines. Both the December notification window and the 18 months that "can only be extended with difficulty". A timeline that only holds if nothing goes wrong is not a timeline. It is a hope with dates on it.
In the works
I am working on an issue about the coming Norwegian rules — the regulation work, the sending obligation from 2027, and the question of whether accounting system vendors should be regulated at all. It is a decision that lands before Christmas, and it resembles the Danish one more than you would think.
There will also be 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.