ERP Audit Consultant, Denmark

Why audit a system that technically works?

An ERP review is not only for Danish companies in crisis. Often the system runs, invoices go out and the accountant gets what they need, eventually. The problem is the cost hidden in that word eventually: hours spent matching payments, re-keying data between apps, correcting VAT before the return is filed and rebuilding reports in Excel.

Common triggers for a review include:

• A new CFO or finance manager who wants to understand what they have inherited.
• Rising subscription costs for apps and licenses without a clear view of their value.
• An upcoming upgrade, new entity or new sales channel that will stress the current setup.
• A question from the accountant or auditor about controls or document storage.
• A sense that the business is working around the system more than with it.

It helps to be precise about terms. Danish companies know the audit as the work their revisor does on the annual accounts. An ERP audit is different: it examines the system that produces the numbers, not the numbers themselves, and it gives no opinion on the financial statements. Findings that touch VAT, bookkeeping duties or the annual accounts are described factually and handed to your accountant or tax advisor to judge. The general method is set out on my ERP health check page.

Bookkeeping-rule evidence, gathered for your accountant

Denmark's bookkeeping rules increasingly assume a digital system that keeps vouchers electronically, logs changes, is backed up and can receive e-invoices. Whether those expectations bind your company, and whether today's setup meets them, is for your accountant or auditor to decide. What I can do is collect the evidence they need in one place, so the question does not stay open for months.

The evidence pack typically describes:

• Whether the system, or the way it is delivered to you, appears on the authorities' list of registered bookkeeping systems, and what that covers.
• How purchase and sales vouchers are attached to entries, and whether any are stored only in email or a shared drive.
• What the audit trail records when entries are changed or reversed.
• How and where backups are made, and who can restore them.
• How supplier invoices arrive: e-invoice, scanned PDF or paper.
• How custom apps or a self-hosted setup affect the picture.

I do not state whether you comply. I describe what the system does, with screenshots and examples, and list the open questions. Your accountant then decides what, if anything, must change. The ERP business analyst page for Denmark covers how such rules become requirements when a new system is being specified.

FIK codes, OIOUBL invoices and EAN numbers in daily use

Danish payment and invoicing conventions create small details that either work smoothly or generate daily manual effort. The audit follows them with real documents from a recent period.

Customer payments. I check that invoices carry a correctly built FIK payment code, that bank statements arrive in the ERP through a bank app or file import, and how matching rules handle part payments, combined payments and payments without a reference. A sample of the unmatched list is traced back to its cause, which is often a setting rather than a customer mistake.

Public customers. Danish public bodies generally require structured electronic invoices, and the receiving unit is identified by an EAN location number. I check where that number lives on the customer record or order, whether it is mandatory, which route invoices leave by and how rejections are reported back. A rejected invoice that nobody sees is simply an unpaid invoice.

Supplier invoices. Inbound OIOUBL or Peppol invoices, scanned documents and email PDFs are followed from arrival to posting and payment. I look at how they are matched to purchase orders, who approves them and whether bank details on suppliers can be changed without review.

Many fixes in this area are configuration and rules rather than new software, which is the territory of ERP optimization.

Apps, extensions and integrations that grew without a plan

Danish ERP setups, particularly on Business Central and Odoo, often depend on a collection of apps from different publishers: bank connection, payment files, e-invoicing, document capture, expense handling, shipping labels and webshop sync. Each solves a real problem. The risk is in the collection as a whole.

I build an inventory of every app, extension and integration, recording for each one:

1. What it does and which process depends on it.
2. Who publishes and maintains it, and who inside your company owns it.
3. What it costs and how the subscription is billed.
4. Whether another app or standard feature does the same job.
5. How it behaves on upgrades and what happens when it fails.

Integrations with the webshop, logistics provider, CRM and the payroll provider's posting file are tested for error handling. I look for silent failures: orders that stop syncing without an alert, shipments booked twice, or a payroll file that someone repairs by hand every month. Personal data passing between systems is noted so whoever owns GDPR in your company can check the arrangements.

The result is often a shorter, cheaper and better-understood stack. If the inventory reveals deeper problems from an implementation that never settled, the ERP rescue page for Denmark describes how recovery work runs. Platform-specific notes sit on my Business Central in Denmark page.

User rights, licenses and how the findings are delivered

The final area covers control. Over time permissions accumulate: people change roles but keep their access, an external consultant's account is never closed, and approval steps are relaxed during a busy period and not restored. I compare user rights with the authority management intended and flag combinations such as creating a supplier and approving its payment, or posting journals and closing the period with no second review. In a small finance team full separation may not be realistic, so I suggest compensating checks that fit the team's size.

Licenses are compared with real use. Some users may need only a lighter license type, and some paid features may have no active users at all. The commercial conversation stays between you and your vendor.

The findings report is written for management and is practical for the partner who will act on it. For every finding you get the observed behavior, the business consequence, a probable cause and a suggested remedy, plus ratings for impact and urgency. Items for your accountant, including the bookkeeping evidence pack and any VAT setup questions, are kept in a separate section. Results are walked through in an online session with management, and I can stay available while fixes are made.

For the broader picture of how I work with Danish companies, see the Denmark overview and the ERP consultant page for Denmark.