Business Process Consultant, Denmark

Getting order data right when the customer starts

Many invoicing problems in Danish companies are created weeks before the invoice. A public customer's EAN number and buyer reference were never recorded, a direct debit mandate was not set up, or payment terms were agreed in an email that never reached finance. The invoice then fails, and someone spends time fixing what should have been captured once.

When I map order to cash, I start at the point a customer or contract is created and ask what each later step will need:

• Public customers: the location number of the receiving unit, any order or contact reference the institution requires, and who obtains them before the first delivery.
• Wholesale and retail accounts: agreed prices, discounts and terms, and who is allowed to change them.
• Payment method: whether the customer pays by bank transfer using the FIK code on the invoice, or by direct debit, and who sets up and checks the mandate.
• Credit: who grants a credit limit and who reviews it when orders grow.

The target process places each item at the earliest step where it is known, usually with sales or contract management rather than finance. Which customers must receive electronic invoices, and in which format, is confirmed with the customer and your advisor. How a future system should validate this data is the subject of my Danish ERP business analyst page.

Voucher discipline for bills, receipts and card spend

Danish bookkeeping rules put weight on vouchers being complete, digital and retrievable, and your accountant can confirm exactly what applies to your company. Whatever the precise rules, the practical challenge is the same: making sure every cost has its document, attached, on time, without finance chasing people.

I map procure to pay and employee expenses with that in mind:

1. Purchases on account: who orders, which reference suppliers must quote, who confirms delivery and who approves the bill.
2. Company card spend: how the receipt for each card line is captured, by whom and by when, and what happens when a receipt is lost.
3. Personal outlays: how employees claim reimbursement, who approves, and how mileage or travel claims are documented, following rules your advisor confirms.
4. Subscriptions and recurring bills: who owns each one, so costs do not continue after the user has left.

For each route, the target design sets a clear deadline and owner, and a simple escalation when a voucher is missing at month-end. It also defines who may approve what, so a manager is not asked to approve their own expenses. The routine works with any system, and it makes later automation far easier because the rules already exist. Practical ideas for the automation side are on the business automation page for Denmark.

A close that the auditor can follow

Most Danish companies work with an external accountant or auditor for the year-end and often for parts of the monthly close. The record to report process therefore crosses a company boundary, and that boundary is where time is lost. Questions arrive late, evidence is collected in a hurry and the same explanations are written every year.

I map the close as one process across both sides and produce a shared calendar that lists:

• Bank reconciliations, including direct debit returns and receipts that did not match on the FIK code.
• Open supplier bills and missing vouchers at the cut-off.
• Accruals, prepayments and project or order revenue that needs judgment.
• Stock counts and valuation inputs for businesses that hold goods.
• The VAT basis and its review before filing.
• The evidence file the auditor expects for the year-end, built up month by month instead of at the end.

Each line has an owner, a due point in the close and a description of the evidence. The auditor is invited to comment on the plan before it is finalized, which avoids surprises later. Accounting treatment remains their call and your accountant's. The result is a close that depends less on memory and more on a routine anyone in finance can pick up. My ERP consultant page for Denmark explains how this links to system choices.

Decision rights in a flat organization

Flat structures make Danish companies quick to act, but they can leave decision rights vague. When anyone can approve a purchase or change a customer's terms, nobody is clearly accountable, and controls depend on trust alone. That works until the company grows, adds a second entity or faces its first serious error.

I help management write a short decision rights matrix that keeps the informal culture but removes ambiguity:

• Ordering and approving: who may commit the company to a cost, and up to which level, before a second person is involved.
• Master data: who may add or edit customer and supplier records, prices and bank details, and who reviews those changes.
• Payments: who prepares a payment batch and who releases it, kept as two different people.
• Credit and write-offs: who may extend credit, agree a settlement or write off a balance.
• Stand-ins: who covers each role during holidays and absence.

The matrix fits on one page. It is agreed in a short workshop with management, checked with the auditor for any control concerns and shared with everyone it affects. Later, it becomes the basis for user roles and approval workflows in whatever system the company uses.

Documentation, ownership and when software comes in

Process documentation in Denmark has to be light enough that people read it. I keep the deliverables short: a swimlane map for each flow in scope, the decision rights matrix, procedures of a page or two written for the role that uses them and a gap list. Everything is in English, and your team produces Danish versions where warehouse, shop or service staff prefer them.

Each flow gets an owner. The owner is responsible for keeping the procedure current, approving changes and answering questions from colleagues. Without that role, documentation tends to fall out of date within months.

The gap list is where software enters the conversation, and only then. Each gap is classified:

• Routine change: fixed by agreeing and following a better way of working.
• Current system: fixed by configuring or using today's tools differently.
• New capability: needs automation, an integration or a different system.

Often the first two categories are larger than expected, and a company that thought it needed a new ERP finds it needs a clearer routine and a few changes in the system it already has. When new software is justified, the agreed processes become the brief for selection. The Denmark overview lists all the ways I support Danish companies remotely, and the method is described in more depth under business process consulting.