System Integration Consultant, Denmark

Mapping the integrations around a Danish ERP

The first deliverable is a map of everything connected to the ERP, including flows that run through someone's inbox. In Danish companies, especially those on Business Central with several extensions, the list is often longer than expected:

• E-invoicing: invoices to public customers through the national exchange or Peppol, and incoming supplier e-invoices.
• Banks: statement imports, FIK-referenced receipts, supplier payment files and sometimes direct debit collections.
• Supplier bill capture: scanning or interpretation services that turn PDFs into draft entries.
• Payroll: a Danish payroll provider posting salary journals, often by department or project.
• Commerce: Shopify, WooCommerce or another webshop, plus marketplaces in other countries.
• Logistics: a 3PL warehouse, carrier booking and label tools, and track-and-trace updates.
• Reporting: Power BI or another BI tool reading ERP and webshop data.

For each flow I note the tool or app used, who supplied it, who maintains it, what it costs to run and what happens when it stops. Two patterns tend to appear. Some apps overlap, with two extensions touching the same bank or webshop data. Others have no clear owner at all, because the person who installed them has left. Both become actions in the design: consolidate, document or replace. The ERP audit page for Denmark covers the wider system health check.

Keeping vouchers and audit trails intact across systems

Danish bookkeeping legislation has pushed many businesses toward digital bookkeeping systems with digital storage of vouchers. Your accountant should confirm what applies to you and how. From an integration point of view, the implication is practical: when a transaction arrives from another system, the supporting document and its history should arrive with it or remain retrievable.

I build that into every interface specification:

• Supplier invoices: the original e-invoice or PDF is attached to the posted entry, not left in the scanning tool alone.
• Webshop sales: orders and payment settlements carry identifiers that link the ERP entry back to the webshop order and the payment provider's report.
• Bank receipts: the statement line reference is stored with the allocation, so anyone can see why a payment was matched to an invoice.
• Payroll journals: the summary report from the payroll provider is attached to the journal.
• Corrections: reversals and re-sends are logged rather than overwritten, so the trail shows what changed and when.

This matters beyond compliance. When a customer disputes an invoice or an auditor asks about a transaction, finance can answer from the ERP without logging into three other tools. I review these points with your accountant during the mapping workshop, and the rules become part of acceptance testing. For the requirements side of bookkeeping rules, see the ERP business analyst page for Denmark.

E-invoices, location numbers and FIK codes as data flows

Invoices to Danish public customers and payment codes on outgoing invoices are often discussed as features. In integration terms they are data flows with specific fields, and they fail when a single field is missing.

For outgoing public invoices, the specification states:

1. Where the customer's location number, often called an EAN number, is stored, and whether one customer can have several receiving units.
2. Which buyer references are mandatory and at which step they are captured, ideally in the CRM or on the sales order.
3. Which route the invoice takes, through the ERP's own module or an external provider, and in which format.
4. How validation errors and rejections come back, who receives them and how the fix is resent.

For FIK payment codes, the design covers how the code is generated and printed on invoices, how statement data from the bank carries it back, and how the ERP treats part payments, overpayments and receipts that arrive without the code.

Supplier payment files follow the same discipline: which bank channel is used, how approvals are split between ERP and bank, and how rejected payments are reported. Banks and public buyers revise their requirements periodically, which is why each specification names the version it was written against and the contact who confirmed it. The CRM consultant page for Denmark describes where location numbers and references should first be captured.

Webshop, warehouse and carrier connections

Danish brands and wholesalers often sell through their own webshop, marketplaces abroad and retailers at the same time, with stock held in their own warehouse or at a 3PL. The integration has to keep stock, orders and returns consistent across all of them.

The design decisions I work through with operations and finance include:

• Stock ownership: whether the ERP or the 3PL holds the true stock figure, and how often available quantities are published to each sales channel.
• Order flow: when a webshop order becomes an ERP order, how it reaches the warehouse and how picking and shipping confirmations return.
• Pricing and VAT: how consumer prices including VAT, B2B prices excluding it, discounts and shipping charges map to ERP lines, with VAT treatment confirmed by your accountant.
• Payment settlements: how payouts from the payment provider, net of fees, are split into sales, fees and bank transfers.
• Returns: how a return registered at the warehouse triggers a credit note and refund, and how restocking or write-off is decided.
• Carriers: where shipping labels are created and how tracking numbers reach the customer and the ERP.

Native connectors exist for many of these combinations. I test them against your real scenarios, such as bundles, partial shipments and returns across borders, before relying on them. Gaps are specified for middleware or custom work. The e-commerce industry page describes the wider operating model.

Choosing methods, testing and owning the result

With the flows mapped, I decide the method for each one. Business Central and Odoo both have marketplaces full of apps, and an app is often the right answer for a standard Danish flow. Before accepting one, I check who publishes it, how it handled past changes in formats or ERP versions, how errors are reported and whether its data can be retrieved if it is withdrawn. Where several systems share the same data, a middleware layer with central logging can replace a cluster of single-purpose apps. Custom APIs are reserved for unusual logic or volumes.

Construction of each flow is handled by in-house programmers, the ERP partner or a dedicated integration company, and I check what they deliver line by line against the agreed design before joining the test cycle.

Test scenarios mirror what goes wrong in Danish operations:

• A public customer rejects an invoice for a missing reference.
• A receipt arrives without its FIK code or covers two invoices.
• A webshop order is partly shipped, then partly returned.
• A payroll journal references a closed department.
• An app update changes a field format overnight.

Acceptance waits until finance has matched totals across the connected systems. Once live, every interface writes a log, raises alerts to a named person and has its own runbook entry. The ownership matrix names who handles each failure type and who retests flows after app or ERP updates. The Denmark page lists my other remote services for Danish companies.