ERP Business Analyst in Denmark

Digital bookkeeping rules as system requirements

Danish bookkeeping legislation has shifted part of the compliance burden onto the software itself. Many businesses are expected to use a digital bookkeeping system that meets defined standards, store vouchers digitally, keep records retrievable and have them backed up appropriately. Which rules apply depends on the type and size of your business, so your accountant confirms the position; my job is to turn that confirmation into requirements a vendor must evidence.

In the BRD, this section typically includes:

• How each voucher, such as a supplier invoice, receipt or expense claim, is captured, linked to its posting and stored.
• Audit trail expectations: who changed what and when, and what cannot be changed after posting.
• Backup and retention requirements, including what happens if you leave the platform.
• Where the system is not on a list of registered standard systems, what documentation the vendor or implementer must provide instead.
• How the accountant accesses records for review.

I never assume a product qualifies. During selection, each vendor is asked for current evidence for the exact product and setup, and your accountant reviews it. The platform view is on my Dynamics 365 in Denmark and Odoo in Denmark pages.

E-invoices to public customers and payment matching

Danish public institutions generally require suppliers to send structured electronic invoices rather than PDFs, delivered through the national infrastructure or the Peppol network. Each invoice usually needs the receiving institution's location number and the reference the buyer gave you. If either is missing, the invoice can be rejected and payment waits.

For businesses with public customers, I document:

• Which customers require e-invoices and which identifiers and references each one supplies.
• Where those references are captured, at order entry or contract setup, so the invoice is complete automatically.
• Which format and connector the platform uses to send, and how rejections come back to the user.
• How credit notes are sent and linked to the original invoice.
• How inbound e-invoices from suppliers are received and routed for approval.

On the receiving side of cash, Danish invoices often carry a payment code that lets the bank match incoming payments to the right invoice. Requirements cover how codes are generated, how statements are imported and how exceptions are cleared. Each item becomes a UAT case in a test environment. Current rules should be confirmed with your accountant or the receiving institution. The wider decision is covered on my ERP consultant page for Denmark.

Batch records and quality approvals in life sciences

Medtech, pharmaceutical, biotech and specialist food companies in Denmark need an ERP that supports traceability and quality control, not just stock quantities. A generic template might track lots, but the questions that decide fit are more precise: can a batch be blocked until quality releases it, can you trace every component to every shipment in both directions, and can an auditor see who approved what.

In workshops with quality, production, warehouse and regulatory staff, I document requirements such as:

• Batch or lot and expiry capture at receipt, during production and at dispatch.
• Quarantine, release and rejection statuses, and who may change them.
• Forward and backward trace reports for recall exercises.
• Deviations, complaints and corrective actions, and whether they live in the ERP or a separate quality system.
• Electronic records and approvals, where your quality team confirms which regulatory expectations apply.

I do not interpret GxP or medical device regulations. Your quality and regulatory specialists confirm what applies, and I make sure their decisions become requirements, interfaces and test scripts. In the fit-gap analysis, these items often show the clearest differences between platforms.

Freight, voyages and cost allocation for shipping businesses

Shipping, freight forwarding and logistics companies in Denmark face a different costing problem. Revenue and costs relate to a shipment, a voyage, a vessel or a customer contract, and they often arrive at different times, from different agents, in different currencies. If the ERP cannot allocate costs to the right object, profitability is only known after a manual reconciliation weeks later.

During process mapping with operations and finance, I document how a job is opened, which costs are estimated and accrued, how agent and supplier invoices are matched to it and when it is closed. Requirements then define the dimensions the ERP must hold, such as shipment, voyage, vessel, route or customer, along with accrual rules and the reports management needs.

Integration is central here. Freight management systems, port and agent portals and customs filing tools often sit beside the ERP. The BRD describes each interface in business language: what data moves, how often, who owns errors and which system holds the master record. That level of detail lets implementers estimate the integration work honestly instead of discovering it after contract.

Working in English with Danish review and GDPR in mind

All workshops and deliverables are in English. Items that must be in Danish, such as invoice texts, reminder letters, labels and short procedures for warehouse or production staff, are written or proofed by Danish speakers on your staff or a local partner. The BRD lists each item with an owner, so translation work is planned rather than squeezed into the last week.

Data protection also shapes the requirements. Under GDPR, the ERP should hold only the personal data it needs, with access limited to the right roles and retention defined. Personal identity numbers used for payroll normally stay with your payroll provider, and the requirements describe the journal interface rather than duplicating employee data.

Remote delivery suits this work. Interviews and reviews are held in the Danish morning and early afternoon, which sits inside my working day in India. Drafts are shared for comments between sessions, and each process area is signed off in writing. For other ways I support Danish companies, see the Denmark overview, and for the document structure, my guide to creating an ERP BRD.