What is the difference between transaktionsspor and kontrolspor?
| Term | English gloss | What it covers |
|---|---|---|
| Transaktionsspor | Transaction trail | The connection between the individual posted entries and the company's annual accounts. |
| Kontrolspor | Control trail | The information that documents the correctness of those entries. |
The distinction is not academic. The transaktionsspor answers where in the annual accounts did this entry end up. The kontrolspor answers why is this entry correct. A system can satisfy the first completely and the second not at all — which is typically what happens when an integration writes an entry with a tidy reference to a source system but with nothing documenting what triggered it.
English-language material uses the single phrase audit trail for both. When a vendor's documentation promises an audit trail, the useful question is which of the two requirements it covers. For a group this has a second cost: a control narrative that says audit trail throughout cannot be mapped onto the Danish requirement without the translation being done in the room during fieldwork. Write both Danish terms into the control description and the mapping is done in advance. The wider set — including Datatilsynet's separate logging requirement — is set out under audit trails in Denmark.
Can a posted entry be changed or deleted?
The requirements for digital bookkeeping systems mean that:
- posted transactions cannot be changed, backdated or deleted;
- each entry receives a sequential transaction number;
- each entry receives a registration date;
- each entry carries initials for the user or program;
- corrections are made by new entries.
The field for initials for user or program is the one that becomes interesting under automation. In manual bookkeeping it identifies a person. In automated bookkeeping it typically identifies a service account ID shared by five different processes. That satisfies the letter of the requirement and does not answer the question anyone actually asks at an inspection: what triggered this entry.
The practical consequence is that the identification has to be finer than the account. Not integration_srv, but the specific process, the specific run identifier and — where an AI agent is involved — which model and configuration were in force.
Retention
Five years from the end of the financial year the material relates to. That is an entirely different time horizon from application logs, which typically rotate after days or weeks. An automated system whose only documentation of a posting sequence lives in application logs does not meet the requirement, however thorough the logging is while it exists.
Does Denmark require B2B e-invoicing?
This is misread consistently, including in vendor material, and it is worth getting right.
The rules require the bookkeeping system to be able to send and receive e-invoices via Nemhandel (OIOUBL) and Peppol BIS. They do not require businesses actually to exchange e-invoices with one another.
Denmark has no B2B e-invoicing mandate. Only invoicing to the public sector is mandatory. The requirement is aimed at the capability of the system, not at the behaviour of the company — a distinction that separates Denmark from Poland, Slovakia, Belgium and Norway, where there are genuine exchange mandates with dates and fines attached. If you are running a European roll-out plan, Denmark belongs in a different column from Belgium's B2B obligation, which has been in force since 1 January 2026 and does compel exchange.
A related point worth knowing: OIOUBL 3 was abandoned. Denmark is moving directly on to Peppol BIS 4. Material describing an OIOUBL 3 migration as forthcoming is out of date. The current published Peppol billing specification is a Core Invoice Usage Specification of the European standard EN 16931, which is the same standard the Belgian and other European mandates build on — so the format work is largely shared even where the legal obligation is not.
Is your Danish entity on a registered system or not?
This is the question a group has to answer before any of the rest of the article applies to it, and most groups have not asked it.
Erhvervsstyrelsen distinguishes registered digital standard bookkeeping systems from systems that are not registered. A provider of a standard system must have it entered on Erhvervsstyrelsen's public register before it is marketed in Denmark; the register listed more than 120 systems when it was last updated on 18 June 2026, ranging from Microsoft Dynamics 365 and Odoo down to small Danish products. Where the system is on the register, the provider carries the assurance that it meets the legal requirements. Where it is not — an in-house build, a foreign system, or a combination of components — responsibility for meeting the requirements sits with the business.
That single sentence is the whole cross-border problem. A group ERP instance operated centrally from Frankfurt, London or New Jersey and configured for a Danish subsidiary is very unlikely to be on the Danish register as the product the entity actually posts in. The Danish entity therefore falls into the non-registered category by default, and the compliance burden that a domestic Danish company can push on to its software vendor lands instead on the group.
Erhvervsstyrelsen's guidance for non-registered systems sets out what has to be true. In summary:
- the entry records the transaction date, amount, document number, description and any exchange rates;
- the system automatically assigns a registration date, a sequential transaction identifier and user initials;
- finalised entries cannot be deleted or altered, and corrections are made by new postings;
- changes to documents are logged;
- the system meets a recognised IT security standard — the guidance names ISO 27001 and the Danish D-mærket label as examples;
- full weekly backups of all entries and documents are taken;
- those backups are held by a third party unaffiliated with the business, in an EU or EEA country, and retained for five years;
- the system can send and receive e-invoices in OIOUBL and Peppol BIS formats;
- bank account reconciliation is supported;
- data can be exported in the SAF-T standard file format.
Two of these regularly fail in a group. The backup clause is the first: a backup written into the parent company's own data centre is held by an affiliated party, and a backup region outside the EU or EEA does not answer the wording at all. Both are common defaults in a group hosting arrangement and neither is visible from Denmark until someone asks. The second is SAF-T. A general ability to export CSV or to run a report is not the same thing as producing the SAF-T standard file; the only way to know is to generate one.
When did the requirement start applying?
| Who | From |
|---|---|
| Accounting-obliged businesses using a registered digital standard system | 1 July 2024 |
| Businesses using a system that is not registered | The first financial year beginning after 1 January 2025 |
| Personally owned businesses and associations | No earlier than 2026 |
For a group entity on a central, non-registered ERP, the relevant date is therefore the start of its first financial year after 1 January 2025 — and because the retention obligation runs five years from the end of each financial year, the evidence for that first year has to survive until well into the 2030s. This is worth settling before, rather than during, a system migration: a cut-over that leaves the old instance decommissioned and the archive unreadable removes evidence the entity is still obliged to be able to produce.
Where does this meet the personal-data rules?
The bookkeeping requirement does not stand alone. Where entries and supporting documents contain personal data, Datatilsynet's requirements apply in parallel: there must be logging of all uses of personal data by users, including reading, adding, searching, changing, extracting and deleting, and the logging must be activated no later than when the IT system is put into operation. The retention period is set according to the purpose and weighed against the data minimisation principle.
The two regimes pull in opposite directions. The bookkeeping act requires five years of retention; data minimisation requires that nothing be kept longer than necessary. The answer is rarely a single retention policy for the whole system, but separate policies for the bookkeeping material and for the access logging — which is exactly the setting a group harmonisation project tends to collapse into one. Separate them deliberately, and record why they differ.
What changes when the entries are created by automation?
Three consequences worth designing for from the beginning.
Corrections become more frequent, not less
Because entries cannot be altered, every error in an automated process becomes a counter-entry. An integration that posts incorrectly for three weeks does not leave three weeks of errors behind — it leaves three weeks of errors plus three weeks of corrections, all of them visible. That is precisely the intention of the rule, but it makes early detection far more valuable than in a system where you could quietly amend.
Idempotency becomes a bookkeeping requirement
A repeated call after a timeout that creates a duplicate entry cannot be tidied up by deleting it. It has to be reversed by a counter-entry, and both appear in the accounts. Idempotency control — a durable operation identifier assigned before the first attempt — is therefore not merely a technical nicety here. It determines how untidy the annual accounts look.
The control trail has to be written before the action
If the documentation of what triggered an entry is only written after a successful call, there is no trace of the attempts that never came back — and those are exactly what the questions are about when something has gone wrong. The same ordering argument, applied to AI agents specifically, sits under AI agent audit trails.
What must a foreign parent do differently?
The obligation stays with the Danish entity even when the system is run elsewhere. Where the ERP is operated centrally in another country and the integrations were built by a group team, the Danish entity still owes the transaktionsspor and the kontrolspor for its own books. Decide explicitly who produces that evidence and how quickly. It is an intercompany control question before it is a technical one.
Assume the non-registered branch of the rules until you have checked. The register is public and the check takes minutes; the assumption that a well-known international product must be covered is what leaves the backup and SAF-T requirements unexamined for years.
The shared service account problem is specifically a group problem. Centralised operations are what produce one integration user under which many processes post — and a group with a shared service centre hits it in every entity at once, including the Danish one, where the field is a statutory field rather than a convention.
Do not read the e-invoicing capability requirement as a mandate. A group compliance calendar that lists Denmark alongside Belgium and Poland as an e-invoicing country will trigger a project that the Danish rules do not require, and will still leave the actual Danish requirement — the properties of the system and the two trails — unaddressed. Approval controls in front of the automated postings are a separate question again, dealt with under approval thresholds for AI actions in Denmark.
How do you establish where your entity stands?
- Look up the exact product your Danish entity posts in on Erhvervsstyrelsen's public register.
- If it is not there, apply the requirements for non-registered systems and accept that the business, not the vendor, carries them.
- Establish which financial year the requirement first bit for this entity.
- Try to alter a posted entry in a test company, and confirm that you cannot.
- Read the initials for user or program field on a sample of automated postings.
- Establish where the weekly backup is held, who holds it, and for how long.
- Generate an actual SAF-T export and open it.
- Separate the retention policies for the bookkeeping material and the personal-data logging.
In practice
BarzelVault writes the record before the action executes and enforces idempotency at the level of the operation, so a retry after a timeout does not become a second entry. Each record identifies the specific process — or the agent, with its model and policy version — behind the posting.
Frequently asked questions
What is the difference between transaktionsspor and kontrolspor?
Transaktionsspor, the transaction trail, is the connection between the posted entries and the annual accounts. Kontrolspor, the control trail, is the information documenting the correctness of those entries. They are different requirements met by different documentation.
Can a posted entry be corrected?
Not by alteration. Posted transactions cannot be changed, backdated or deleted. Corrections are made by new entries, so the original sequence stays visible.
Is e-invoicing mandatory between Danish businesses?
No. The system must be able to send and receive via Nemhandel and Peppol BIS. There is no B2B requirement to use it; only invoicing to the public sector is mandatory.
What applies if our group ERP is not on the register?
The requirements for non-registered systems, and the business carries them rather than the provider — including full weekly backups held by an unaffiliated third party in an EU or EEA country for five years, and SAF-T export.
How long must the material be kept?
Five years from the end of the financial year the material relates to.
Do application logs satisfy the requirement?
Rarely. They rotate, they can be altered, and their completeness depends on a log level that is adjusted in production without a formal procedure.
Related reading
- AI audit trails in Denmark: three requirements, not one
- Approval thresholds for AI actions in Denmark
- NIS 2-loven § 7: the management body's personal duty
- Belgium: the structured B2B e-invoicing obligation
- AI agent audit trails — the general case
- Workflow automation
- Glossary of Danish and EU terms
- Corrections
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
In forceDigital bookkeeping duty phased in since 1 July 2024
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Sources
- Lov om bogføring (bogføringsloven), LOV nr 700 af 24/05/2022 — retsinformation.dk.
- Erhvervsstyrelsen, Vejledning om bogføringsloven — definitions of transaktionsspor and kontrolspor and the five-year retention period.
- Erhvervsstyrelsen, Krav til digitale standard bogføringssystemer — requirements for registered standard systems.
- Erhvervsstyrelsen, Ikke-registrerede digitale bogføringssystemer — requirements where the system is not registered.
- Erhvervsstyrelsen, Fortegnelse over registrerede bogføringssystemer — the public register, last updated 18 June 2026.
- Erhvervsstyrelsen, Krav til digital bogføring træder i kraft — commencement dates.
- Datatilsynet, Katalog over foranstaltninger: logning af brugernes anvendelser af personoplysninger.
- OpenPeppol, Peppol BIS Billing 3.0 — a Core Invoice Usage Specification of EN 16931.
This article is for information and does not constitute legal or audit advice. The Danish text of the instruments cited is the binding one. Position as at 3 September 2026.