Business Automation Consultant, Denmark

Closing the voucher gap on card spend

Company cards make buying easy and documenting hard. Every card line needs a receipt, and under Danish bookkeeping rules the voucher has to be kept in a way your accountant can confirm is acceptable. In many companies, finance spends the end of each month chasing colleagues for receipts from purchases made weeks earlier.

This is a strong first automation because the rules are simple and the frustration is shared. The flow I design works like this:

1. Staff photograph or forward the receipt at the time of purchase, using the app or inbox your expense or accounting tool provides.
2. The receipt is read and matched automatically to the card line by amount, date and merchant.
3. Lines without a receipt trigger a friendly reminder to the cardholder after an agreed interval, then a second one to their manager.
4. Suggested account, VAT treatment and department are proposed from previous purchases at the same merchant and confirmed by the cardholder or approver.
5. At month-end, finance sees a short list of what is still missing instead of a full statement to work through.

The original receipt stays attached to the posting, which keeps the audit trail intact. Choosing which tool captures receipts is part of the design, and the answer depends on what your accounting system already offers. The routine behind it, including deadlines and approvers, comes from the process work for Denmark.

Supplier bills: suggested coding and approval routing

Danish companies receive a growing share of supplier invoices electronically, and the rest as PDFs. Either way, someone decides which account, VAT code and department a bill belongs to and who should approve it. For recurring suppliers, that decision is the same every month, which makes it a good automation candidate.

The automation I specify uses information that already exists:

• Supplier history: the account and department used on previous bills from the same supplier become the default suggestion.
• References: a purchase order or contract reference on the bill routes it to the person who placed the order.
• Decision rights: amount limits from your approval matrix decide whether one approver is enough or a second is needed.
• Stand-ins: when an approver is away, the bill moves to their named deputy instead of waiting.
• Exceptions: new suppliers, changed bank details and bills without a reference stop for a person.

The approver always sees the suggested coding and can change it before approval. Over time the suggestions improve as corrections are learned or rules are refined. How e-invoices physically arrive in your system, and how they connect to banks or other platforms, is integration work, covered on my system integration page for Denmark. This page is about the human steps after arrival.

Customers: notices, reminders and payment follow-up

Automation is not only for internal finance work. Several customer-facing steps in Danish companies follow clear rules and are often done late or not at all because they depend on someone remembering.

Typical candidates include:

• Order confirmations and delivery updates for wholesale and webshop customers, sent when an order is accepted, packed or shipped.
• Invoice delivery status for public customers, with an alert to the account owner when an electronic invoice is rejected so the missing reference can be obtained quickly.
• Payment reminders following the routine finance has agreed, with the right tone for long-standing accounts and any legal wording confirmed by your advisor.
• Returned direct debits collected into a follow-up list with a prepared message, so the customer hears from you before the next collection.
• Payments without a valid FIK code grouped with suggested matches for finance to confirm.

The automation prepares and sends what is routine and leaves anything sensitive, such as disputes, credit holds or a customer in difficulty, to the person who owns the relationship. Danish wording is drafted or proofread by colleagues on your side. Internally, scheduled reports can deliver order intake, overdue receivables and margin by customer to managers before their weekly meeting. The finance automation page describes how this looks inside an ERP.

AI steps and data protection

AI earns a place in a Danish back office when it handles a specific, well-defined task and a person checks the result. The tasks I consider are practical:

• Reading receipts and supplier invoices with unusual layouts, including foreign ones, and proposing the fields to capture.
• Sorting mail that lands in the joint finance or service mailbox and preparing draft answers that a colleague edits.
• Summarizing a customer's history before a credit or collection decision, for the person who makes it.
• Answering staff questions about internal procedures from an approved set of documents.

For each task, the design records what data the AI sees, which service processes it, what it produces, the confidence level below which it hands over to a person and who confirms the output. Decisions on credit, payment release, write-offs and VAT treatment of unusual transactions stay with people.

Data protection is part of the same design. Receipts and invoices can include personal data, and GDPR applies, so which AI services are used, where they process data and under which agreement are decisions for the person who owns GDPR in your company, or your lawyer. I prepare the facts they need to decide. Vouchers must also remain stored and retrievable as your accountant confirms, which means AI may read originals but never replace or alter them. The wider method is described under AI business automation.

Limits, builders and maintenance

Some steps should not be automated, and I list them explicitly. For Danish companies, the list usually includes changes to supplier bank details, release of payment batches, credit limits and write-offs, settlement of customer disputes and any process that is about to be redesigned. Keeping these manual protects the company against fraud and silent errors and keeps accountability with people.

Building is split clearly. My share is the rule set, the exception paths and the test list, plus building the workflow-level automations that your platforms support natively or through integration tools. When a flow needs programming, a new connector or a change in how the ledger posts, that part belongs to a developer or the implementer; they work from my document and I join the tests before launch.

After go-live, each automation has a business owner and a technical owner, a runbook, failure alerts to a named person and a simple way to pause it. Automations that depend on one employee's personal account or an undocumented script are moved into a supported setup.

I judge the results with the teams themselves: are receipts in before month-end, do bills reach approvers without chasing, do customers get updates without asking, is the exception list getting shorter? Automations that no longer help are retired. The Denmark overview and my ERP consultant page for Denmark describe the rest of my remote support.