A new official interpretation makes the moment of posting—not the intelligence of the software—the critical question for accountability. For retailers and software vendors, it also exposes a missing layer between machine-readable rules and autonomous action.
A purchase invoice arrives electronically at a Danish company, where an AI assistant reads the document, selects accounts and VAT codes, and prepares the journal entry in seconds. The company has already supplied the instructions governing the process, so the remaining decision might appear to be a minor technical detail: whether the software should also press the final button. In guidance issued by Denmark’s Business Authority in October, that detail becomes the boundary between an automated tool and a provider acting as a bookkeeper. [1]
The distinction deserves attention far beyond accounting software because it addresses a challenge that retailers, POS vendors and enterprise software companies are approaching from different directions. AI is rapidly acquiring permission to make operational changes, but conventional software architecture is much better at proving that an action occurred than explaining whether an autonomous agent was entitled to perform it, under whose authority it acted and what evidence justifies the result. Denmark has not solved that engineering problem, but its guidance makes the problem unusually concrete.
The decisive moment is the posting
The Danish Business Authority, Erhvervsstyrelsen, published a consolidated guide for providers of registered standard digital bookkeeping systems on 5 October 2026 and updated it on 19 October. Section 3.2 discusses external bookkeepers and AI agents, including an example of an agent integrated into a registered bookkeeping system that imports electronic purchase invoices and fills a draft journal using rules previously specified by the customer. Preparing the entry is treated as useful digitalisation. If the agent subsequently posts it without a user reviewing and approving the content, the authority says the system provider acts as a bookkeeper and takes responsibility for the posted transactions in the same way as an external party performing bookkeeping for a customer. [1][2]
The guide offers providers an explicit alternative: if they do not wish to assume that role, the customer must perform a final review and approval before posting. Elsewhere, it states that the booking of purchase invoices must be approved by a user and describes extensive automation as desirable around that approval boundary. It therefore would be misleading to report the guidance as a broad prohibition on accounting automation, or as a general law newly transferring all liability from the customer to an AI company. It is an official interpretation directed at registered bookkeeping-system providers, with a particularly important example involving their built-in agents. [1]
A second passage is essential to a fair reading. Section 7.8 continues to assign end customers responsibility for correct bookkeeping under the Bookkeeping Act, while providers are responsible for their systems’ applicable statutory requirements. The additional bookkeeper responsibility described in the autonomous-posting example does not erase the customer’s underlying duties. Nor does the example settle the position of an independent third-party agent operating through an API supplied by another vendor. Those distinctions matter because responsibility can be shared, layered or disputed across a modern software supply chain. [1][3]
The economics of autonomy now include responsibility
For software companies, the commercial incentive behind autonomous posting is obvious. Removing manual approval from repetitive workflows can reduce processing time, improve throughput and allow finance teams to concentrate on exceptions. Yet the Danish interpretation suggests that removing the human approval step may also change what service the provider is understood to deliver. The vendor is no longer simply selling functionality that a customer operates; in the authority’s example, it is performing an accounting task on the customer’s behalf. That potential shift should influence product design, contracts, controls, insurance discussions and the price of the service, although the guidance itself does not prescribe a particular commercial model. [1]
There is a temptation to respond by inserting an approval button everywhere and declaring the risk solved. Such a design may satisfy a narrow workflow requirement while destroying much of the efficiency that made automation attractive, and an approval is meaningful only when the approver can understand the proposed action and its consequences. Providers should distinguish routine preparation from legally consequential execution, identify what information must be shown at approval, preserve the approver’s identity and ensure that rejections, corrections and later audits remain traceable. This is a design recommendation derived from the guidance rather than a list of technical controls mandated by Denmark.
Why retailers and POS vendors should pay attention
The direct legal scope is accounting, not retail checkout. Nothing in this guidance establishes that a cashier must approve each receipt, that autonomous POS transactions are forbidden or that fiscal software providers automatically become bookkeepers. The relevant lesson for retail is architectural: once an agent moves from recommending a decision to executing a regulated transaction, the system must know whose authority is being exercised and which jurisdiction-specific conditions must be satisfied. [1]
Consider an international retailer using AI to reconcile daily store sales, classify exceptions, propose corrections to tax-related postings and transmit information from a POS platform to an ERP ledger. A wrong VAT classification, duplicated correction or unapproved adjustment could originate in an agent, a third-party integration or the retailer’s own instructions. The resulting accounting entry may have a completely different legal status depending on whether it remained a draft, was approved by an authorised employee or was posted by software operating without that approval. The Danish example makes this sequence tangible, but the treatment of any actual retail scenario must still be assessed under the applicable national law. [1][3]
For POS vendors and fiscal middleware suppliers, this argues for interfaces that preserve not merely amounts, tax categories and transaction identifiers, but also the provenance and authorisation of an action. If AI-generated corrections flow into regulated records, a vendor should be able to distinguish a suggested change from a committed one, show who or what initiated it, record the policy version used, and recover an auditable chain of approvals and execution results. Retailers should ask their suppliers where autonomous changes can occur, whether permissions are confined to specific actions and how an audit would reconstruct a disputed posting. These are operationally useful questions even where no Danish rule applies.
The case for a compliance execution layer
This is precisely the gap I am exploring in my research on a Compliance Compiler and machine-readable law. The research proposes translating authoritative legal sources into structured regulatory requirements, resolving applicable context and conflicts, and finally producing machine-enforceable execution conditions. My related concept of a Compliance Execution Contract would sit at the moment an agent requests permission to perform a consequential operation, binding the proposed action to the applicable rule, authorised actor, necessary approval and evidence that must be retained. It is a proposed architecture, not a capability that the Danish authority has endorsed or required.
Applied to the Danish example, a system would distinguish an instruction to extract invoice details from an instruction to post an accounting entry. Before the latter operation, the execution layer could evaluate the jurisdiction, the registered system’s role, whether a human has approved the specific draft and whether the service provider has consciously accepted the responsibilities associated with an autonomous bookkeeping service. If the necessary authorisation cannot be established, the system could hold the entry for review rather than allowing the agent to improvise a compliance conclusion. The resulting decision record could identify the governing interpretation, its effective version, the transaction, the approver or executing service, and the final outcome.
The technical ambition is not to ask a language model to remember thousands of regulations and to hope that its next answer is correct. It is to separate interpretation from permission to execute, with deterministic controls wherever the law admits clear conditions and explicit abstention or escalation when interpretation remains uncertain. A human approval can then be a substantive control linked to a particular action, rather than a decorative confirmation added after an opaque AI recommendation. This distinction also protects useful automation: extraction, classification and draft preparation can proceed at scale while the legally sensitive transition into an authoritative record receives the appropriate scrutiny.
A broader European context, with a necessary limit
The EU AI Act likewise contains provisions for human oversight of systems classified as high risk. Article 14 requires that such systems be designed for effective human oversight and specifies capabilities including monitoring, interpretation, intervention and stopping operation; Article 26 describes corresponding duties for deployers. Those provisions are not a universal rule requiring human approval of every AI accounting entry, and ordinary bookkeeping agents cannot simply be presumed high-risk under the Act. They nonetheless demonstrate that the relationship between autonomy, supervision and responsibility is a prominent regulatory design concern. [4][5]
The unresolved problem is interoperability between legal instructions and technical systems. A cross-border retailer can change an AI model or an ERP integration much faster than it can redesign every approval workflow for a new national interpretation. Regulatory requirements are also expressed in prose, exceptions, definitions and institutional responsibilities that software teams cannot safely convert into a universal boolean rule without careful legal analysis. The most defensible route is a governed translation process in which the source, interpretation, machine-executable rule and evidence of execution remain linked and versioned. This is the research hypothesis that the Danish example supports as a practical need, not proof that one proposed implementation has already been scientifically validated.
The next competitive advantage will be verifiable autonomy
Denmark’s guidance is a warning against equating technological capability with permission. The fact that an AI agent can correctly fill a journal, reconcile a payment or update an enterprise system does not by itself answer whether it is authorised to commit the result. The difference between assistance and execution can alter responsibility, and companies that ignore the distinction may discover it only after a costly failure.
For retailers, the immediate priority is to inventory autonomous actions across finance, POS and back-office systems and demand transparent approval and audit mechanisms from vendors. For software suppliers, the opportunity is to make compliance part of the transaction architecture instead of treating it as a paragraph in a contract or a warning in a user interface. For my research, the Danish case offers a valuable regulatory test: whether a machine-readable control layer can preserve the efficiency of AI while making the authority, limits and evidence of each consequential action independently verifiable. The future of agentic commerce will depend not only on how much software can do, but on how reliably it can demonstrate that it was allowed to do it.
Sources and further reading
[1] Danish Business Authority, Guidance on Digital Standard Bookkeeping Systems, version 2 updated 19 October 2026, especially sections 3.2, 6 and 7.8. https://erhvervsstyrelsen.dk/vejledning-vejledning-til-udbydere-af-digitale-standard-bogfoeringssystemer
[2] Danish Business Authority, New Consolidated Guidance for Providers of Digital Standard Bookkeeping Systems, 9 October 2026 (states original publication on 5 October). https://erhvervsstyrelsen.dk/ny-samlet-vejledning-til-udbydere-af-digitale-standard-bogfoeringssystemer
[3] Danish Business Authority, Guidance on the Bookkeeping Act, including responsibilities of businesses using registered and non-registered systems and external bookkeepers. https://erhvervsstyrelsen.dk/vejledning-bogfoeringsloven
[4] European Union, Regulation (EU) 2024/1689 (AI Act), Article 14, Human oversight. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14
[5] European Union, Regulation (EU) 2024/1689 (AI Act), Article 26, Obligations of deployers of high-risk AI systems. https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26
