Business Central Consultant in Denmark

Danish bookkeeping requirements, tested in Business Central

Microsoft offers Business Central in a Danish country version, with localization for Danish accounting and tax needs. Denmark's bookkeeping legislation adds a further layer: it sets expectations for digital bookkeeping systems, including digital storage of vouchers, security and backup, traceable changes and the handling of e-invoices, and some standard systems are registered as meeting those expectations. Your accountant or auditor is the right person to say which of these duties fall on your company.

Rather than accepting a general assurance, I turn their reading into scenarios the partner demonstrates on your data:

• Registered status: does the exact offering you are buying, including whether it is Microsoft-hosted or hosted by the partner, carry registered status, and what does that cover?
• Vouchers: attach a supplier invoice, post it, then show where the attachment lives and how it is retrieved later from the posted entry.
• Change logging: show which changes are logged on master data and setup, and how posted entries are protected.
• Backup and restore: explain who backs up the environment and attachments, and how a restore is tested.
• Incoming e-invoices: receive a supplier e-invoice and turn it into a purchase invoice with the document attached.
• Apps: confirm that added apps do not undermine any of the above.

The results go into an evidence pack for your advisor. If gaps appear, they are resolved in the contract rather than discovered after launch. Broader Dynamics choices for Denmark are discussed on the Dynamics 365 consultant Denmark page.

VAT posting setup and dimensions for Danish trade

Danish companies are often small at home and large abroad, trading with Germany, Sweden, Norway and beyond. The VAT posting setup in Business Central has to reflect that, and the dimension design has to show which markets and activities actually earn money.

VAT posting setup. VAT business posting groups describe who you trade with, VAT product posting groups describe what is traded, and each combination defines the tax calculation and accounts. A Danish design typically separates domestic customers, EU businesses, EU consumers where distance selling applies, customers outside the EU, and domestic and foreign suppliers, combined with product groups for goods, services and exempt items. Each combination is then linked to the right line of the VAT statement, and EU sales are flagged so your accountant can complete the EU reporting. Your accountant decides the treatment; I check that every combination posts as intended with sample transactions.

Dimensions. Depending on the business, useful dimensions might include department, business line, market, shipment or voyage for logistics firms, or product family for life sciences suppliers. I keep the global dimensions for the most-used analysis, use shortcut dimensions for the rest, set defaults on customers, items and vendors, and make dimensions mandatory only where reports genuinely need them.

A test month of realistic postings shows whether the VAT statement, the market report and the general ledger agree. Fixing disagreement at this stage costs a fraction of what it costs after a year of live data.

FIK codes, Danish payment files and OIOUBL

Danish cash and invoice flows rely on a few established mechanisms, and a proposal should explain each specifically.

• FIK codes on sales invoices: how the payment code, with its type, reference and creditor number, is generated and printed, and whether the Danish localization in your version or an app provides it.
• Incoming payments: how bank data with FIK references is imported so customer entries close automatically, and how unreferenced payments are routed.
• Supplier payments: how payment journals export a file your bank accepts, carrying FIK codes or bank details from supplier invoices, and how rejections come back.
• Statements: the import format or bank connection for each Danish and foreign bank, with reconciliation rules for fees and card settlements.
• Electronic invoices: how sales invoices and credit notes reach public customers as OIOUBL or Peppol documents through the national exchange or Peppol, with the customer's location number, often called an EAN number, and buyer reference on each document.
• Inbound e-invoices: how supplier documents arrive, are matched to vendors and purchase orders, and are posted with the original attached.

Most of these involve an app or service. I record the publisher, licensing basis, support contact and fallback for each in one register. Before go-live, every bank account is tested with real files, and a public customer receives a trial invoice and credit note using a genuine location number.

Reading a Danish partner's proposal and support agreement

In Denmark the choice of partner can matter as much as the choice of product, and the documents they provide define what you are buying. The offer, the work statement and the service agreement get reviewed as one set, because the gaps between them are where cost and risk tend to hide.

Questions I raise for Danish projects:

• Bookkeeping evidence: who demonstrates and documents how the solution meets the requirements your advisor identified, and is that a deliverable?
• Scope by requirement: is each Danish item, including FIK, OIOUBL, VAT reporting and costing, named with a solution, or described only in module terms?
• Legacy migration: if you are leaving an older on-premise Microsoft ERP, which customizations are rebuilt, replaced by standard features or dropped, and who decides?
• Data: who extracts, cleans, maps, loads and reconciles balances, open entries and history?
• Testing: what the partner tests, what your users test and what acceptance means.
• Estimates and change: the pricing model, whether fixed, with a ceiling or by the hour, and the approval path for changes.
• Support: promised reaction times, the routine for checking each Microsoft release against your extensions, and cover if named consultants depart.

You receive an annotated review with questions to return to the partner and, where several are bidding, a like-for-like comparison. My vendor proposal review page outlines the approach in general terms.

When Business Central is the wrong call for a Danish business

Business Central is a natural candidate for many Danish companies, which is exactly why it should still be challenged. I advise looking elsewhere when:

• a single small entity with simple processes would be well served by a Danish accounting system and a light operational tool
• the core problem is selling and client delivery, where Zoho CRM in Denmark may address it more directly
• a webshop brand or producer wants broad operations on a modest budget, where Odoo deserves a fair comparison
• nobody inside the company can own the finance design and manage the partner after go-live

I receive nothing from Microsoft, from licenses or from partner referrals, so Business Central is measured with the same criteria as any alternative. When it is the right choice, I stay involved through contracting and acceptance. See the general Business Central consulting page, how I run selections on the ERP consultant Denmark page, and country notes on the Denmark hub. All work is remote and runs in Danish business hours; Danish document layouts and training material come from your own staff or the implementing firm.