Denmark Digital Bookkeeping for Foreign VAT-Registered Firms

A foreign business registered for Danish VAT falls under the Danish Bookkeeping Act (Bogføringsloven) from 1 January 2026 once its Danish-source net turnover exceeds DKK 300,000 in two consecutive years. That date and that threshold are what put you in scope. If that describes your company, digital bookkeeping in Denmark for a foreign VAT-registered business is now a legal obligation rather than good practice, and the first practical consequence is uncomfortable: your global accounting platform is almost certainly not a registered Danish bookkeeping system. That leaves you a choice between three compliance paths, which the rest of this article walks through in detail.

The scope rule is specific. According to Auxadi's overview of Denmark's January 2026 digital bookkeeping rules for foreign VAT-registered businesses, foreign entities only registered for VAT in Denmark with relevant economic activity must comply with the Bookkeeping Act's digital bookkeeping requirements from 1 January 2026 once net turnover exceeds DKK 300,000 for two consecutive years, with fines for serious or repeated violations reaching DKK 1.5 million (approximately €200,000).

Read the threshold precisely, because it is easy to misapply. It is measured on actual net Danish-source turnover, not expected turnover, not gross, and not your parent company's group revenue. And it has to be exceeded in two consecutive financial years, not just one good year. The two-year test is where most foreign businesses get their status wrong, so it helps to run your own figures against the boundary cases below. Use your own financial years, which may not be the calendar year:

• DKK 350,000 in 2024 and DKK 280,000 in 2025. One year above, one year below. The two consecutive years above DKK 300,000 are not there, so this business is not yet caught on this pair of years alone.
• DKK 400,000 in 2024 and DKK 450,000 in 2025. Both years above. This business is in scope from 1 January 2026.
• DKK 250,000 in 2024 and DKK 600,000 in 2025. Only the second year is above, so the 2024 to 2025 pair does not catch them. But if 2026 turnover also holds above DKK 300,000, the 2025 to 2026 pair meets the two-consecutive-year test, and the obligation lands for the 2027 financial year.

There is a second distinction that the general advisory coverage tends to blur, and getting it wrong sends you down the wrong path. A foreign company operating through a Danish branch (a filial registered with Erhvervsstyrelsen) is caught on its Danish activities for financial years beginning in 2026 regardless of the DKK 300,000 threshold. A non-establishment foreign business that is merely VAT-registered (momsregistreret) with no branch is caught only on crossing the threshold for two consecutive years. Before you read on, settle which of the two you are: a filial is in scope by virtue of being a branch, while a bare VAT registration depends entirely on the turnover test.

Where the specifics get genuinely fiddly, such as how to convert a foreign-currency turnover figure into DKK, how to treat a partial first year, or how mixed Danish and non-Danish activity is split, confirm the treatment with a Danish revisor or directly with Erhvervsstyrelsen for your own situation. The boundary cases above show how the test resolves; they are not a substitute for advice on your specific books.

Why Your Xero, QuickBooks Online, or Sage Intacct Stack Does Not Satisfy Bogføringsloven

The Bookkeeping Act does not just require you to keep good records. It requires you to keep them in a digital bookkeeping system that is registered with Erhvervsstyrelsen, or in a non-registered system that you can demonstrate meets the same standards. Xero, QuickBooks Online, Sage Intacct, NetSuite, and the international localisation of Dynamics 365 Business Central are not on that register. They were never built to the Danish specification, so registration was never on the table for them.

This is the answer to the question most foreign finance teams arrive with: does Xero comply with the Danish Bookkeeping Act? Does QuickBooks Online? Does Sage Intacct? On their own, no. They are perfectly capable accounting platforms, but they are not registered Danish bookkeeping systems, and the obligation is defined against that register, not against general accounting quality. The question of Xero, QuickBooks, and Sage compliance with the Danish Bookkeeping Act is really a question about Danish-specific capabilities your global stack was never designed to carry.

Those capabilities are concrete, and it is worth naming them so you can see the size of the gap:

• Registration with Erhvervsstyrelsen. A registered system has been declared to the authority and committed to the Act's technical requirements. A global platform has not.
• The Danish standardkontoplan. The standard chart of accounts uses Danish account structures and vocabulary that a globally configured ledger does not map to natively.
• Native OIOUBL receipt over NemHandel. Danish suppliers send structured e-invoices in OIOUBL across the NemHandel transport. A registered Danish system receives these directly; a global stack has no native NemHandel endpoint.
• Danish SAF-T generation. The system must be able to produce a Danish Standard Audit File for Tax on demand. A global platform exports its own formats, not the Danish SAF-T schema.
• The Danish audit-trail standard. Erhvervsstyrelsen distinguishes the kontrolspor (the control trail linking each posting back to its source document) from the transaktionsspor (the transaction trail running entries through to the financial statements). Both must be intact and demonstrable.

There is also a retention and integrity expectation underneath all of this. Postings have to be held with a secure, tamper-evident trail, and source documents (bilag) stored for five years with continuous access. A ledger configured for another country's rules does not guarantee that immutability or that retention period by default. For the full statutory detail of what the Act demands, see Denmark's Digital Bookkeeping Act (Bogføringsloven) explained in full; this article assumes that ground and concentrates on what to do about it.

None of this disqualifies your global stack outright. It can still be part of a compliant arrangement. The point is that the Danish requirements have to be satisfied somewhere in your setup, and your global platform does not satisfy them by itself. That is the gap the three paths below are designed to close.

---

Path A: Run a Registered Danish System Alongside Your Global Stack

This is the path most foreign businesses end up on, and for good reason. You keep your global stack for group accounting and run a registered Danish system in parallel that owns the Danish-source bookkeeping (bogføring). The Danish system captures Danish bilag, posts to the standardkontoplan, and receives OIOUBL natively; your group ledger keeps doing what it already does. A parallel Danish bookkeeping system for a foreign business is the cleanest way to put the Danish-specific obligations on a tool that was actually built for them.

The realistic options, with the factors that matter to a non-resident user, are:

• e-conomic (from roughly DKK 145 per month). The most widely used SME platform in Denmark, with broad revisor familiarity and native OIOUBL and SAF-T handling. The interface is primarily Danish, which is the main friction for a foreign team.
• Dinero (free tier through to roughly DKK 149 per month). The lightest-weight option, well suited to a small Danish footprint where you mainly need compliant capture and posting rather than deep functionality. Danish-language interface.
• Billy (from roughly DKK 199 per month). Comparable in spirit to Dinero, aimed at small businesses, with straightforward OIOUBL and bilag handling.
• Uniconta (mid-market). The option to look at if your Danish activity is substantial enough to need more than entry-level bookkeeping, with stronger multi-entity and reporting depth.

English-interface availability is the recurring catch. Most of these systems are built first for a Danish-speaking user, so factor in either some Danish-language comfort on your team or a revisor who operates the system on your behalf. Confirm current pricing and English support directly with each vendor, as plans change.

The data flow is what keeps this from doubling your work. Danish invoices and bilag are captured and posted in the Danish system; on a periodic basis you export from it (Excel, CSV, or SAF-T) and consolidate the Danish figures into your group accounting. You are not re-keying every Danish transaction into two ledgers; you are running one compliant Danish book and feeding its output upward. Reconcile monthly at a minimum. The Danish VAT (moms) reporting rhythm sets that floor, and a monthly cadence keeps the Danish ledger and the group books from drifting apart.

The recurring friction on this path is getting Danish supplier documents into the Danish system in the first place. OIOUBL invoices arrive as structured XML and the registered system ingests them directly, but the long tail of PDF invoices, scanned receipts, and emailed bilag still has to be turned into postable data. Re-keying that by hand is exactly the manual work the whole exercise is supposed to avoid. This is where AI invoice data extraction that handles Danish bilag and OIOUBL alongside your global stack earns its place: you upload the PDFs and scanned bilag, describe the fields you need in plain language, and get back structured Excel, CSV, or JSON ready to post, including line-item detail when you need it, without keying each document by hand.

On the revisor question, be clear-eyed. Erhvervsstyrelsen does not require a foreign business to engage a Danish accountant. In practice many do, because the system selection is local, the standardkontoplan vocabulary is Danish, and a revisor who runs the chosen platform daily removes most of the language friction. Treat it as a cost-versus-control trade-off rather than a rule: a revisor buys you local fluency and a working setup, at the cost of a monthly fee. One quiet advantage worth noting now is that the registered vendor, not you, carries the SAF-T export obligation arriving in 2027.

Path B: Operate a Non-Registered System with Documented Self-Certification

The Act does not force you onto a registered system. It also allows a non-registered system, provided you can demonstrate that it meets every requirement a registered system would. In practice this means keeping your existing platform (often the global one) and self-certifying it: maintaining the documentation that proves compliance and holding it ready for Erhvervsstyrelsen on request. A non-registered bookkeeping system run under self-certification is legal. It is also where the burden of proof shifts onto you.

What you have to be able to prove, on demand, is a specific list:

• An audit trail between source document and entry that is immutable, timestamped, and retrievable. This is the kontrolspor and transaktionsspor in practice: every posting traceable back to its bilag, and every entry traceable forward into the financial statements.
• The ability to receive and issue e-invoices in OIOUBL or Peppol BIS format.
• The ability to generate a Danish SAF-T file, and from 2027 a full transaction-level SAF-T 2.0 export.
• Five-year secure digital storage of records and bilag, with continuous access throughout.
• IT-security controls, including access management and automatic backup.
• Documented internal control routines describing how bookkeeping is actually performed and checked.

The part foreign businesses underestimate is that self-certification is not a one-time form. It is an ongoing obligation to keep technical descriptions, evidence, and control documentation current enough to survive a review at any point. Your system can change, your processes can drift, and the documentation has to keep pace. If Erhvervsstyrelsen asks, the gap between what you do and what you can prove is your exposure, not the regulator's problem to interpret charitably.

That is why most foreign businesses, having looked closely at Path B, still choose Path A. Path B is fully legal and can be the right call for an organisation with genuine in-house capability and the appetite to maintain the evidence. But on a registered system the vendor carries the technical compliance and updates it as the rules move; on Path B you carry all of it. For a business whose Danish activity is a side concern rather than its core, that maintenance load rarely pays for itself.

Path C: The Informal Hybrid, and Where Its Defensibility Breaks Down

There is a third arrangement that exists whether or not anyone designed it deliberately, and pretending otherwise would be dishonest. Group accounting stays in Xero, QuickBooks Online, or Sage Intacct. Danish-compliant document storage and OIOUBL receipt run through a specialised tool or a separate repository. Danish activity is then reconciled into the global system by hand. No single registered system sits at the centre; compliance is assembled from parts.

The weakness is precise. With Path C, the compliance risk sits entirely on your ability to prove that the global system and the document repository, taken together, satisfy each Bogføringsloven requirement. Erhvervsstyrelsen review precedent for this exact shape is thin, so you are relying on an arrangement that has not been tested against the regulator's expectations. You may well be compliant in substance; the problem is that you are betting on it without a clear precedent to point to.

It is worth separating this honestly from Path B, because they can look similar from a distance. Path B is a deliberate, documented self-certification of a single system, with one coherent audit trail. Path C is a looser combination of tools that very often lacks exactly that: a unified kontrolspor and transaktionsspor running cleanly from bilag to financial statements. When the trail is split across a global ledger and a separate document store, demonstrating that the two reconcile to the regulator's standard is the part that tends to fall down.

Realistically, Path C fits a very small Danish footprint, where the cost of standing up a registered Danish system is genuinely hard to justify and the volume of Danish transactions is low enough to reconcile by hand. If you run it, run it with eyes open: you are accepting the documentation burden of defending the arrangement if you are ever reviewed, and you should be honest with yourself about whether your trail would actually hold up. This is a real option with a real risk profile, not a shortcut that makes the obligation go away.

---

Receiving Danish E-Invoices: OIOUBL Today, Peppol BIS 4 Tomorrow

Today, Danish suppliers send invoices as OIOUBL across the NemHandel transport. If you receive invoices from Danish suppliers, you need to be able to receive and store OIOUBL now, whichever path you are on. For a foreign company, receiving OIOUBL is the immediate, production-format requirement, and it is the part that a registered Danish system handles for you while a non-registered setup has to arrange it through a Peppol access point or a specialised tool.

The format is changing, and the timeline matters for a decision you make today:

• OIOUBL 3.0 was cancelled in January 2026. The planned next major version is not coming, so do not build toward it.
• NemHandel migrates to a localised Peppol BIS 4 (NemHandel BIS 4) between January 2028 and July 2029. OIOUBL 2.1, the current production format, is phased out in July 2029.
• The EU's VAT in the Digital Age (ViDA) framework sets a 1 July 2030 deadline that drives the Danish migration plan, the same EU timetable behind Ireland's 2028 e-invoicing mandate under the EU ViDA framework.

Translated into your implementation choice, that is three horizons. Short term, you handle OIOUBL. Medium term, through the 2028 to 2029 migration window, you need to support both OIOUBL and Peppol BIS 4 at once, because suppliers will not all switch on the same day. Long term, you align to Peppol BIS 4. The path you pick changes who carries this: on Path A the registered Danish vendor absorbs each format change as a product update, while on Path B and Path C you manage the transition yourself.

The accounts-payable reality is the concrete version of the same point. The same Danish supplier may send you an OIOUBL invoice today and a Peppol BIS 4 invoice in 2028, and you have to keep receiving, parsing, and storing both throughout the overlap. If you are pulling structured data out of those files rather than just archiving them, the mechanics of extracting fields, line items, and VAT from OIOUBL invoice XML are worth understanding before you commit to how your AP process reads them.

SAF-T 2.0 from January 2027: A Burden on Path B, an Inheritance on Path A

The Danish SAF-T 2.0 standard was published in mid-February 2026, and from January 2027 every registered system must be able to generate a full transaction-level SAF-T file. For a foreign business, SAF-T 2.0 is less a separate project than a property your bookkeeping setup either has or does not, and which path you chose decides which.

The consequence splits cleanly. On Path A, the registered Danish vendor builds and maintains SAF-T 2.0 generation as part of the product, so you inherit the capability the same way you inherit the OIOUBL format changes. On Path B, and on the hybrid Path C, you have to build and maintain your own Danish SAF-T export pipeline. That is not a checkbox. It means mapping your ledger data to the Danish schema precisely and keeping that mapping correct as the standard and your own system evolve, which is a real engineering and compliance commitment rather than a periodic export.

It helps to be clear on what SAF-T 2.0 actually is without re-teaching the format from scratch: a standardised, transaction-level file that the tax authority can ingest directly, covering your bookkeeping at the level of individual entries rather than summary totals. That granularity is the reason a non-registered system cannot just approximate it; the data has to line up with the Danish schema field by field. The pattern is familiar from elsewhere in the region, and how SAF-T compliance works for foreign companies in neighbouring Norway is a useful reference for the shape of the obligation if you have not dealt with a SAF-T regime before.

For a business genuinely weighing Path A against Path B, the SAF-T 2.0 build burden is often the factor that settles it. Inheriting a maintained export from a registered vendor is a small recurring cost; building and re-validating your own against an evolving schema is not.

---

What Non-Compliance Costs, and How to Choose Your Path

Violations of the Bookkeeping Act carry fines from DKK 10,000 to DKK 1,500,000 (approximately €200,000), scaling with the size of the business and the severity or repetition of the breach. That is the exposure that makes the path choice worth getting right rather than muddling through; a foreign business should pick a defensible path deliberately, not back into one.

With the three paths and the two transition obligations on the table, the decision usually resolves along clear lines:

• Path A fits most. If your Danish turnover is meaningful and growing, or you simply want to minimise your own compliance burden, a parallel registered Danish system is the lowest-effort route. You inherit OIOUBL format changes and SAF-T 2.0 generation from the vendor instead of building them.
• Path B fits the capable and committed. If you have genuine in-house capability and the appetite to document and maintain self-certification, keeping a non-registered system is legal and can work. You take on the proof burden in exchange for not changing systems.
• Path C fits a small, accepted-risk footprint. A very small Danish presence, where standing up a registered system is hard to justify, might run the informal hybrid, provided you accept the defensibility risk and keep the documentation to defend it.

Let the transition obligations weigh on the choice rather than sit beside it: the less appetite you have for maintaining moving compliance targets like OIOUBL-to-Peppol BIS 4 and SAF-T 2.0 yourself, the more strongly Path A is indicated.

The branch question is a decision input too. If you are a filial, you are caught on your Danish activities regardless of the DKK 300,000 threshold, which generally argues for a registered system from the outset rather than a minimal arrangement that you may quickly outgrow.

For the typical reader here, a non-resident business with a modest but real Danish footprint running a global accounting stack, Path A is usually the lowest-risk and lowest-effort answer. That is why it dominates the market, and unless you have a specific reason to take on the self-certification burden, it is the default worth starting from.

What to Do This Quarter

Turn the decision into a short sequence of actions you can start this quarter:

1. Confirm whether you are caught. Re-run the two-year threshold test on your actual Danish-source net turnover, and separately check whether you are a filial, which is caught regardless of the threshold. Settle your status before you spend money on a system.
2. Choose a path using the framework above: registered Danish system, documented self-certification, or accepted-risk hybrid.
3. If Path A, set it up properly. Select a registered Danish system, get it running, and establish the recurring routine: capture Danish bilag, post to the standardkontoplan, and reconcile into your group books monthly.
4. If Path B or C, build the evidence now. Assemble and document your self-certification, the audit trail, the storage, the IT-security controls, and the internal control routines, rather than scrambling to produce them when Erhvervsstyrelsen asks.

Treat the gap as already open. Because the phase-in took effect on 1 January 2026, a business that confirms it was caught is not preparing for a future deadline; it is closing a compliance gap that is already live for the current financial year. Prioritise accordingly, and confirm the specifics for your own books with a Danish revisor or directly with Erhvervsstyrelsen.

Whichever path you choose, the recurring work underneath it is the same: getting Danish bilag and OIOUBL invoices into the compliant record, and reconciling Danish activity into group accounting on a steady monthly cadence. Build that routine to run without heroics, and the obligation becomes a process rather than a recurring fire.