ERP Requirements Consultant, Denmark

How I lay out a Danish ERP specification

Partners and auditors both read the specification, and they look for different things. A clear layout lets each find what they need without reading everything.

• Company context: entities, any foreign parent, users, locations, volumes and systems that stay.
• Process chapters: sales and invoicing, purchasing with approval of incoming documents, employee expenses, inventory with batch or serial needs, projects or service, and the financial close.
• Danish obligations chapter: bookkeeping and voucher storage, public e-invoicing, payment codes, VAT, payroll journals and document language.
• Operational chapter: hosting, backups, access, logging, load and offline use.
• Integration and migration chapters: one entry per interface and per data object.
• Word list: terms such as EAN number, FIK or bilag explained once for international bidders.

Each line holds an identifier, owner, priority, source and the reason it exists. The discovery that feeds this, including the workshops and process maps, is the subject of my ERP business analyst page for Denmark. This engagement focuses on the controlled document that partners price and testers rely on. The underlying method is explained under ERP requirements gathering.

Bookkeeping, e-invoicing and payment lines a partner must prove

Most Danish specifications already mention the bookkeeping rules. Few say what evidence would show a system meets them. I rewrite those headings as outcomes that can be checked during a demo or a test:

• The partner states whether the proposed system relies on registration under the Danish digital bookkeeping rules or on meeting the requirements another way, and provides the evidence your auditor asks for.
• Every posted entry links to its digital voucher, and vouchers remain retrievable for the period your auditor confirms, including after the old system is retired.
• Invoices to public customers leave in the format your customers require, OIOUBL or Peppol, carrying the EAN number and any order reference, and rejections reach a named person.
• Incoming electronic invoices enter the approval flow with the original document stored.
• Customer invoices carry a FIK payment code that the system matches when bank transactions are imported.
• The VAT settlement is built from posted tax codes in a mapping your advisor has approved.
• The payroll provider delivers a journal that posts by department or cost center.

I do not interpret Danish law. Your auditor or tax advisor confirms each obligation, and the document records who confirmed it.

Operational requirements: hosting, backups and access

Process chapters fill up quickly. Operational requirements tend to be left as one sentence about security, even though Danish bookkeeping rules and GDPR both touch them. I treat them as a full chapter.

• Data location and backups: where the production database and its backups are held, whether an EU region can be chosen, how backups are protected and how subprocessor changes are notified. Your data protection owner and auditor judge the answers.
• Access design: roles that keep supplier master data and payment release apart, approval limits matched to a flat organization and how deputies cover holidays.
• Logging: a trail of edits to posted entries, bank details and prices that the auditor can receive as a file.
• Load: how the system should respond while month-end jobs, big invoicing batches or payment files run, written as points to agree with the partner, never as made-up targets.
• Offline needs: what crew on a vessel, technicians at a wind service base or staff at a rural depot must still record without a stable connection.
• Leaving: what a complete export of data and vouchers looks like and how it is delivered.

Written early, these lines give partners something concrete to price instead of assumptions buried in a proposal.

Interfaces, archived history and the path from line to test

A Danish ERP rarely stands alone. A payroll provider, banks, a webshop, a logistics or freight system and sometimes a parent company's consolidation tool stay connected. Each interface entry states direction, frequency, trigger, data carried, error handling and the owner on your side.

Migration lines follow the same discipline. They define which balances, open items, batches, projects and attachments move from e-conomic, Dinero, C5, NAV or spreadsheets, which history stays behind in an archive and how every object will be agreed back to the old ledger. Because vouchers must stay accessible, the archive decision is a requirement in its own right, not a detail left to cutover week.

Process owners decide the priority of their own lines. A must is something you would refuse to sign without. Should and could separate the valuable from the merely nice, and will-not keeps a record of what was deliberately left out, so nobody reopens it later. Every line also names its demo scenario and its acceptance test. Those references lets anyone follow a Danish obligation from the document into the ERP gap analysis and through to testing and UAT without reconstructing decisions from email threads.

Releasing the document to partners, and gaps worth catching

A released specification becomes the annex partners answer line by line, and the scenarios used in vendor demos, described on my Danish ERP selection page, come straight from it. Publicly owned companies follow the tender format their procurement advisor prescribes, with the specification placed inside it. Before signing, the agreement and statement of work name the released version, so acceptance is measured against what everyone approved. The ERP RFP consulting page covers the wider bidder pack.

Each release carries a number, an approval record and a log of changed lines with the reason. Later changes follow the same path, which stops a contract from quietly pointing at an earlier draft.

Gaps that put Danish projects at risk include:

• Digital bookkeeping mentioned without any line on evidence, backups or voucher retention.
• Public e-invoicing covered for sending, with EAN capture at customer setup and inbound invoices missing.
• FIK codes treated as a print detail rather than a matching requirement.
• No decision on where old vouchers will live after leaving e-conomic or C5.
• Batch, quality approval or voyage costing needs left implicit in sectors that depend on them.

Other remote services for Danish companies are listed on the Denmark hub.