Business Process Consultant, Germany

Where time and control leak in a German back office

Process consulting starts with the paper trail, not the org chart. I ask for a handful of real documents, such as an order confirmation, a delivery note, a supplier invoice and the booking that followed, and trace each one through the business in remote sessions with the people who touched it. The map that results shows where work waits, where it is typed twice and where a decision depends on one person's memory.

In German companies a few patterns are worth checking every time:

• Receipts collected in folders or inboxes and sent to the Steuerberater in batches, so questions about them arrive weeks later and nobody remembers the context.
• Supplier invoices approved by forwarding an email, with no record of who checked price and quantity.
• Goods receipts recorded late, which leaves invoices blocked or, worse, paid before the goods are confirmed.
• Credit notes and partial deliveries handled by individual arrangement with each customer rather than by a rule.
• Month-end reports rebuilt in spreadsheets because the figures in the system are not trusted.

None of these needs software to diagnose. Each gets a note on the map, a plain description of how often it occurs and an owner who agrees it is real. That list drives the future design. The general method sits on my business process consulting page.

Approval limits, the four-eyes principle and signing powers

Many German businesses say they apply the four-eyes principle, yet the actual rule often lives in habit. One manager signs off every purchase regardless of value, while a whole expense category needs no approval at all. Bank details for a supplier can be changed by the same person who prepares the payment run. I turn this into an explicit approval design.

For each process I record what needs approval, who approves at which limit, when a second person must confirm, and what happens if the approver is absent. Payment release, changes to supplier bank details, price overrides, write-offs and credit notes each get their own line. The matrix describes limits in bands such as routine, significant and exceptional, which management fills with its own values.

Two boundaries are worth stating. Legal representation, such as the powers of a managing director or a registered Prokura, is a legal question for management and counsel; internal approval limits are an operational decision that should be consistent with it, not a substitute for it. And segregation of duties has to fit the size of the team. In a small finance department a compensating review after the fact is sometimes the realistic answer, and the map says so openly rather than pretending a separation exists. Once agreed, the matrix becomes a requirement for any later approval workflow.

Turning process maps into procedure documentation

German bookkeeping practice, commonly summarized as GoBD, expects a company to be able to describe how its accounting-relevant processes work: how documents arrive, how they are checked, how they are recorded and where they are kept. Many companies know they should have this procedure documentation but treat it as an IT document to be written once and filed. I treat it first as a process document.

The maps from this engagement already contain most of what that description needs. For incoming invoices, for example, they show the channels through which invoices arrive, who checks them against order and receipt, who assigns the account, when the invoice is posted and where the original is stored. I write each process up in that sequence, add the controls agreed in the approval design and note which system supports each step. Where a step is manual, the description says so plainly.

What I hand over is a structured draft, not a formal attestation. Your Steuerberater or auditor decides whether it meets their expectations and what must be added, for example details about the archive system or IT access controls that your IT provider documents. Keeping the draft linked to the process maps has a practical benefit: when a process changes, its owner knows which part of the description to update, and the documentation stays current instead of aging in a folder.

Structured invoices, direct debits and the advisor in the flow

Some German process steps are shaped by outside parties, and the future design has to make room for them. Three come up in most engagements.

Structured e-invoices. Business-to-business invoicing in Germany is shifting to structured electronic formats. In process terms that changes procure to pay: an invoice arrives as data that can be checked against the order before anyone reads a PDF, and the original file has to be kept. I design the receiving step, the check, the approval and the storage as one sequence, and leave the question of which obligations apply to you, and when, to your tax advisor.

SEPA direct debits. Many German companies collect from customers by direct debit. That adds steps people forget to own: obtaining and storing the mandate, informing the customer before collection, handling a returned debit and deciding when a customer goes back to paying by invoice. Each step gets an owner and a rule.

The Steuerberater. Where an external advisor keeps the ledger or prepares returns, record to report extends outside your company. I map what you send, when, in what condition and how their questions come back, so month-end does not depend on one person chasing receipts. The technical export belongs to system integration work; the process around it belongs here.

Owners, the works council and when software comes in

A process design only holds if somebody owns it. For every cross-department flow I name an owner on your side, usually a head of department, who approves changes and keeps the work instructions current. The instructions stay brief, address the role rather than the department and live next to the files the team opens daily, not in a binder.

Process changes can affect how employees work and how their work is recorded. Where a works council exists, changes that introduce new monitoring, time recording or performance reporting may need to be discussed with it, and management and HR decide with their advisors how and when. I keep a plain list of such changes in the design so that conversation can start early rather than when a system is about to go live.

Only after the future process is agreed do I turn to software. Sometimes the right step is to configure the system you already have properly. Sometimes the maps show requirements that justify a new platform, and they become the basis for requirements work in Germany and selection. Sometimes the answer is targeted automation of a few steps, which my business automation consultant page for Germany covers. The work is remote, and an on-site day can be arranged where it helps; my Germany page gives the wider picture.