ERPNext Accounting in Denmark

Danish digital bookkeeping rules: questions before configuration

Danish bookkeeping law has moved towards digital systems that meet published requirements, with the Danish Business Authority overseeing them. As I understand the framework, commercial standard systems can be registered as meeting the requirements, while companies using systems that are not registered, including ones they develop or adapt themselves, carry more of the burden of showing that their setup complies. Which obligations apply depends on your company's type and size, and the rules are being introduced in stages. I am not a lawyer, and none of this is legal advice.

The honest position is this: I have not been able to confirm whether ERPNext, in any version or hosting form, is registered as a standard bookkeeping system in Denmark. Do not assume it is, and do not assume it cannot be used. Put the question directly to Frappe or the partner you are considering, and to your auditor, before you commit.

The questions I prepare for those conversations:

• Is any ERPNext distribution or hosted service registered, and does that cover the version and apps we would run?
• If not, what must we document and demonstrate as users of an unregistered system?
• How are vouchers and attachments stored and kept for the required period?
• How are changes to posted entries logged, and can that log be altered?
• How are backups made, where are they held and how is a restore tested?
• Can incoming e-invoices be received and stored as the rules expect?

The answers decide whether the project continues on ERPNext. The ERPNext Denmark page covers the broader platform fit.

Danish VAT, the chart of accounts and the accountant's view

ERPNext does not ship a maintained Danish VAT return as far as I can confirm, so the work is configuration plus a report. Start with the chart of accounts. Danish accountants generally expect accounts grouped so the annual report lines are easy to derive, and many companies already have a numbering scheme they want to keep. ERPNext imports a chart as a tree of groups and numbered ledger accounts, so you can keep what works instead of adopting a generic template.

VAT is configured through tax templates:

• Sales templates for domestic sales, goods and services to EU businesses, exports and any exempt activity your advisor identifies.
• Purchase templates for domestic purchases with deductible input VAT, reverse charge purchases from abroad and imports.
• Item tax templates where items need a different treatment, plus tax rules that choose templates by customer or supplier.
• Separate tax accounts per treatment, so each figure on the return can be traced.

Your advisor confirms each treatment and how deduction limits apply to particular costs; I make sure ERPNext posts them to the agreed accounts. A custom report then totals the figures for the return, and the accountant compares it with test transactions before the first live period. Filing usually stays with the accountant.

For the EU sales listing and Intrastat, ask the accountant what is needed and whether ERPNext's data, perhaps through a custom report, can supply it.

Payment codes, bank data and matching in ERPNext

Many Danish invoices carry a payment code, the familiar FIK line that tells the bank which creditor and which invoice a payment belongs to. ERPNext does not create these codes in a standard install as far as I know. A small custom app or server script can generate the code from the invoice number and your creditor details, using the method your bank agreement describes, and add it to the print format. I insist on testing the format with your bank before invoices reach customers, because a wrong check digit turns automatic matching into manual work.

The other half is getting payment data back into ERPNext. Depending on your bank, details arrive in statement files, dedicated payment files or through an API, sometimes via an aggregator. ERPNext's Bank Reconciliation Tool and payment matching work once the data is in; the integration is the part to design. Supplier payments go the other way, through a file your bank accepts or a payment service.

Points I specify for each bank account:

• the route for statements and how often it runs
• how the payment code or invoice reference is read and matched
• how fees and currency differences are posted
• who reviews unmatched lines and when

Many Danish companies also hold euro accounts for trade with Germany and the rest of the EU, so each currency gets its own bank account in ERPNext and its own revaluation rule, agreed with your accountant.

OIOUBL, Peppol and location numbers

Danish public customers generally require structured electronic invoices, sent through the national infrastructure in the OIOUBL format or through Peppol, depending on what your access point supports. Each public buyer is usually identified by a location number, and invoices often must carry an order reference or contact person the buyer gives you. Without those details the invoice may be rejected.

ERPNext does not join these networks on its own. The usual design calls an access point provider's API when a sales invoice is submitted, sends the invoice or credit note and receives a delivery status in return. My specification covers:

• Customer data: location number and electronic address stored on the customer, mandatory for public buyers.
• Order references: captured on the sales order and carried to the invoice.
• Mapping: lines, VAT, discounts and payment details translated into the provider's format.
• Status handling: rejected invoices returned to the person who can fix them, with the original locked.
• Incoming invoices: received from the provider as draft purchase invoices with the original file attached.

Incoming e-invoices matter for the bookkeeping rules as well, so confirm with your auditor how received invoices and their originals must be stored. Check also whether a community app for Danish e-invoicing exists for your version and who maintains it, confirming with Frappe or your partner. Whatever the route, it gets an owner, monitoring and a fallback.

Hosting, upgrades and when ERPNext accounting does not suit Denmark

Hosting is not only a technical choice in Denmark, because backups, access to records and data location feed into what your auditor assesses. Frappe Cloud gives managed hosting with backups handled by the provider; check the regions and record the choice under GDPR. Self-hosting in an EU data center hands you complete control, along with the duty to run backup tests, security patches and upgrades and to document every one of them. A partner may offer hosting bundled with support; ask what evidence of backups and logging they can provide.

Upgrades need the same discipline. FIK generation, bank imports, the e-invoice connector and VAT reports must be retested on a staging copy before every major upgrade, with the results filed as part of your evidence.

ERPNext accounting is the wrong path in Denmark when:

• your auditor prefers a registered standard system and ERPNext's status cannot be confirmed
• nobody will own custom apps, documentation and upgrade tests
• your accounting firm works only inside a Danish accounting package
• group consolidation and audit reporting are the main finance demands

Then a registered commercial system, Odoo Accounting in Denmark after checking its own status, or Business Central in Denmark may be safer. I am not a Frappe partner and take no commissions. More on ERPNext accounting, the ERP consultant Denmark page and the Denmark hub. All work is remote.