In many companies an approval still travels through the building as a folder: the document is filed, placed on a desk, marked with initials and passed on. Others have swapped the paper route for email and consider that the digital state of affairs. Both variants share the same problem: while the case is in transit, nobody can say reliably where it sits, since when, who is responsible next and what exactly was approved. This only becomes apparent when somebody is absent, when an early payment discount lapses, or when the question comes up months later on what basis a payment was released. This article describes how to map approvals so that responsibility, deputy, deadline and decision are attached to the case itself. It covers dual control, value limits, the specifics of invoice approvals and the most frequent reason why digital approvals stall as well.
Key takeaways
- Circulation folders, signature binders and approval by email produce no traceability: the timestamp is missing, so is the link to the checked version of the document and any answer to where the case currently sits.
- A digital approval consists of five parts that belong together: a named responsibility expressed as a role, a registered deputy, a deadline with reminder, an unambiguous decision with a mandatory reason on rejection, and an audit trail on the case.
- Dual control and value limits are two different rules: one separates roles so that nobody runs a case alone from order to payment, the other defines the amount above which a second approval becomes necessary.
- Invoice approvals add the split between factual and arithmetic checking, the match against order and goods receipt, the discount deadline as a second clock, and the commercial and tax retention requirements.
- Digital approvals stall too when responsibility hangs on a person rather than a role, when no deputy is registered, or when nobody owns the task of chasing cases that got stuck.
Why the circulation folder leaves no trace
The circulation folder is a well-considered procedure, and it worked for decades. Its weakness lies not in the idea but in the fact that it knows a single state: it is either here or not here. Everything in between goes unrecorded. When the document was placed on a desk, how long it sat there, whether it went to somebody else in the meantime, whether a query was running: none of that appears on the paper. Anyone who wants to know the status has to go looking, and in practice the answer to the question of its whereabouts is that somebody will check.
The signature binder makes matters worse. It collects cases until signing becomes worthwhile, and thereby creates a waiting time that nobody plans and nobody measures. If the authorised signatory is out of the office for a day, the waiting time extends for the entire stack, regardless of whether an individual case was urgent. No prioritisation takes place, because the binder knows none. The reverse is a problem as well: if the stack is signed off under time pressure, a formal approval exists while no substantive check has happened.
The third gap concerns the reference. A signature on a sheet of paper says nothing about which version of the case was checked. If a line item is later corrected, an amount adjusted or an attachment exchanged, the initials remain in place even though they referred to something else. That is precisely the question that arises months later during an audit, an internal clarification or a dispute about a delivery. Anyone unable to answer it does not have a filing problem but an evidence problem.
Checking, approving and signing are not the same thing
Approval by email is not a digital approval
The most common intermediate step on the way from paper to a governed workflow is email: the document goes out as an attachment, and a short reply saying fine counts as approval. That is faster than the folder and understandable in daily work. It does not make the case traceable, however, because the decision ends up somewhere that is not the case. It sits in one person's mailbox, not on the document, and is therefore invisible to everybody else.
Four recurring effects follow from this. First, there is no overview: nobody can say how many approvals are currently open, because the information is spread across several mailboxes. Second, the reference is missing: with several attachments and a long reply chain it is hard to prove afterwards which version was approved. Third, there is no deputy: during an absence the message simply sits in the mailbox, and an automatic out-of-office reply is no substitute for forwarding to a responsible role. Fourth, there is no deadline, because an email knows no workflow.
There is also the question of evidence. Consent in text form is not worthless, but it is not an audit trail either: it can be forwarded, quoted, shortened and presented differently in a new message. Whether it demonstrates a proper approval depends on the requirements in the individual case and belongs in expert review. From a purely operational point of view, though, one thing holds: a decision that cannot be assigned unambiguously to a checked version helps little when the matter is clarified later.
| Everyday question | Folder or email | Approval mapped digitally |
|---|---|---|
| Where is the case right now? | Only answerable by asking around | Visible on the case, with the time it arrived |
| How long has it been sitting there? | Not recorded | Waiting time follows from the audit trail |
| Who is responsible during an absence? | Unregulated or agreed verbally | A registered deputy takes over after the deadline |
| Which version was approved? | Cannot be derived from the signature | The decision is bound to the checked version |
| Was dual control observed? | Only traceable through the initials | Two separated roles are required to close the case |
| How many approvals are open? | Cannot be evaluated | Evaluable by age, amount and responsibility |
What a digital approval has to deliver at minimum
A digital approval path does not need an extensive system. It needs five parts that have to work together. The first is the trigger: an unambiguous event that starts the approval, such as a document arriving, an order reaching a certain status or a purchase requisition being created. As long as the start depends on somebody remembering, the workflow stays unreliable. The second is responsibility, expressed as a role: the technical department head, the commercial manager, the project owner. A role survives staff changes; a name does not.
The third part is the decision itself, and it should know more than two outcomes. Alongside approval and rejection you need the return for clarification, because that is the most frequent case: a detail is missing, the account assignment does not fit, the service was not fully delivered. Without this third outcome the query gets handled by phone or chat, and the case leaves exactly the path you have just set up. The fourth part is the deadline with its follow-up rule, the fifth the audit trail. The following sections deal with both.
The order of work matters. These five points are organisational decisions, not technical ones. They can be settled on a single page before anybody talks about tools. In practice, agreeing on who may decide from which amount usually takes longer than the technical implementation. Skipping that clarification means mapping the existing ambiguity in digital form and then wondering why nothing improved. A preceding process analysis provides the stocktake: which approvals actually exist, how often they occur and where they stall today.
A trigger instead of a shout
The approval starts at a defined event in the system, not because somebody writes a message. That way the start is documented and waiting time is measurable from the first minute.
A role instead of a name
Responsibility belongs to a function with people assigned to it. On changes, holidays or new appointments the assignment changes, not the workflow. That avoids quiet rule changes in daily work.
Return as its own outcome
Besides approval and rejection you need the return for clarification with a mandatory reason. Otherwise the most frequent case wanders out of the governed workflow and into phone calls.
Audit trail on the case
Every decision is stored with the document, not in a separate logging system. Whoever opens the case sees without a further step who decided when and in which role.
Deputies, deadlines and reminders
The deputy arrangement decides whether an approval path holds up in daily operations. Holidays, illness, site appointments and customer visits are the normal case, not the exception. A deputy should therefore not be set up only when needed but registered permanently: every role has a named deputy, and the handover follows rules that are fixed in advance. A combination of two triggers has proved useful: an active absence notice switches over immediately, and independently of that the deputy takes over once a deadline expires, because not every absence gets reported.
Deadlines should follow actual need rather than being uniform everywhere. A purchase requisition in daily business tolerates a short deadline; a capital expenditure request with several quotations needs longer. As a starting point, a first deadline of roughly two working days has worked well (project experience), after which a reminder goes to the responsible role. If the second deadline passes as well, the deputy is brought in, then the next level up. What matters is that these stages are defined beforehand and known in the company, otherwise automatic escalation feels like a complaint.
Reminders work as long as they stay rare. A daily digest listing every open case gets clicked away unread after a few weeks and damages the whole workflow. What works is one reminder per case when the deadline is exceeded, plus a short overview at a fixed rhythm for management. That overview is at the same time the first key figure the new workflow produces: number of open approvals, average age and distribution across roles. Anyone who wants to carry such values further will find the connection in metrics and reporting.
Case type: Incoming invoice for trade services
Trigger: document captured and supplier assigned
Stage 1 Factual check Role: order owner
2 working days reminder to the role
afterwards deputy takes over
Stage 2 Arithmetic check Role: accounting
1 working day discount deadline takes priority
Stage 3 Payment approval depends on the amount
up to EUR 1,000 net Role: commercial manager alone
above EUR 1,000 net plus management
Outcomes per stage: approved | returned for clarification (reason required) | rejected (reason required)
Audit trail: person, time, role, decision, document version, deputy flagDual control and value limits
Dual control and value limits are often mentioned in the same breath but govern different things. Dual control separates roles: whoever orders a service should not decide alone on paying for it; whoever changes master data should not approve the change themselves. It is about separating functions within a case, regardless of the amount. A value limit, by contrast, defines the level above which an additional decision becomes necessary. The two rules interlock but do not replace each other: an invoice for a small amount may require dual control without touching any value limit.
In companies with ten to fifty employees, separating roles runs into practical limits, because the same person fills several functions. What helps then is the distinction between separation as the rule and a documented exception. If during a holiday the same person orders and approves, that should be recognisable in the audit trail and reviewed afterwards. That is more honest than a rule that exists formally and gets bypassed in daily work. Assessing which separations are binding in a specific case belongs in expert review, for instance with your tax adviser.
With value limits, less is more. Three stages are enough for most companies (project experience): a band in which the responsible role decides alone, a band with an additional second approval, and a band that involves management. What matters is the question of what the limit refers to. Does it apply per document, per order or per case across the year? Without that definition the obvious workaround through partial amounts appears. It should equally be settled whether the limit refers to net or gross amounts and how foreign currencies and call-off orders are handled.
A value limit without a reference base is not a rule but an invitation to split amounts. Only defining what the figure refers to makes it verifiable.
Invoice approvals: what to consider in addition
The invoice approval is the approval path with the most additional requirements, and at the same time the most frequent entry point, because its benefit becomes visible immediately. To begin with, it splits into two separate checks. The factual check answers whether the service was delivered and whether it matches what was ordered; it belongs to the role that owns the order. The arithmetic check answers whether amount, tax rate, payment terms and account assignment are correct; it belongs in accounting. If the two are merged, the case regularly arises in which an invoice is signed off factually although nobody was able to confirm the service itself.
Then there is the match against the upstream documents. Where an order and a goods receipt exist, the invoice should be checked against both before it enters the approval path at all. If quantity, price and line item agree, part of the volume can run through without manual approval; deviations above a defined tolerance go into the check. This pre-sorting relieves the workflow far more than any acceleration of the approval itself. It requires the systems involved to exchange data, which is usually solved through an interface between the inventory system and the accounting system.
The third specific is time. With invoices a second clock runs alongside your own deadline: the early payment discount period. It follows the invoice or receipt date and cannot be moved. An approval path that does not know about the discount period regularly leads to a case being processed within the internal deadline while the company loses the deduction anyway. It therefore makes sense to show the remaining time until the discount date and to tie the reminder to it, not solely to the internal deadline.
- Rule out duplicate capture. Before starting the approval path, check for existing documents with the same invoice number and supplier. Duplicates arise particularly easily when the same invoice arrives by post and electronically.
- Record the date of receipt. The moment the document arrives in the company is the reference point for deadlines and should be set automatically, not by hand.
- Use structured invoice formats. Where invoices arrive in a structured electronic format, capture is unnecessary and the values needed for matching are available straight away.
- Keep the approved version unchanged. The version that was approved has to be retained unaltered; later corrections become a new case with their own audit trail entry.
- Plan for retention. Document, audit trail and check notes belong in the archive together; the commercial and tax requirements in a specific case belong in expert review.
- Cover paper arrivals too. As long as invoices also arrive on paper, a defined capture point is needed, otherwise two parallel paths emerge. The groundwork for this is covered by document digitisation.
The audit trail: what is recorded and what for
An audit trail is not an end in itself, nor is it a monitoring device aimed at your own staff. Its practical value shows the moment a question from the past has to be answered: why was this item paid, who accepted the deviation, on what basis was the decision taken. For that to work, an entry needs four details. The person acting, the point in time, the decision, and the version of the case it referred to. In addition it should record in which role the person acted and whether they were acting as a deputy.
The last point is frequently overlooked and the most valuable. An entry that contains only a name and a timestamp does not answer the later question about authorisation. Only the reference to the role shows that the person was actually responsible at the time of the decision. This matters especially when responsibilities change over time: whoever looks at the permission list today sees the current state, not the one from two years ago. An audit trail that stores only the name documents an action but no authority.
What is not recorded matters just as much. An approval trail serves the case, not the evaluation of working behaviour. Evaluations should relate to cases rather than people: open approvals by age, by area, by amount. As soon as a system is capable of capturing behaviour or performance, the involvement of the works council has to be clarified where one exists, and the data protection assessment belongs in expert hands. Raising these points early costs little time and prevents a sensible workflow from later being perceived as a surveillance instrument.
The audit trail belongs on the case, not in a system of its own
Why approvals stall in digital form as well
The expectation that a digital workflow will be faster by itself is regularly disappointed. The reason rarely lies in the technology. It lies in the fact that the question of responsibility was never answered and the rollout now makes that visible. As long as the folder went round the building, it could sit on a pile without anybody being asked about it. In the digital workflow the case appears in an overview with a name, a date and a waiting time. That causes discomfort at first but is the actual gain: a bottleneck that is visible can be worked on.
The second cause is assignment to people instead of roles. If a case goes to a name, it goes on holiday with that person. If it goes to a role with several people assigned, the deputy arrangement takes effect without intervention. The third cause is too many approval stages. Every additional stage extends the throughput time and at the same time reduces care, because each person involved assumes the next one will check anyway. Two to three stages with a substantive purpose are usually more effective than five formal ones.
The fourth cause concerns ownership of the workflow itself. It needs a named position that looks at the list of open cases regularly and follows up on anything unusual. Without that role, cases accumulate that fail to move on for a single reason: a missing permission, a departed employee still in the assignment, an invoice with no matching order. Such cases do not resolve themselves. Leaving them for weeks endangers acceptance of the whole workflow, because the shortcut by phone then looks like the faster route again.
Step 1: List the approvals you have
Which case types genuinely require an approval today, how often do they occur and who signs them at present? The list is usually shorter than expected, and some approvals turn out to be habit without a substantive reason.
Step 2: Define roles and value limits
Responsibilities are described as roles and staffed with people. Value limits are kept to a few stages, each stated together with what the amount refers to.
Step 3: Settle deputies and deadlines
Every role gets a named deputy. Deadlines are set per case type, as is the sequence of reminders and the point from which the deputy takes over.
Step 4: Start with one case type
Begin with a single, frequent case type, often the incoming invoice below a value limit. The workflow runs in parallel with the previous route for a few weeks until it holds.
Step 5: Review and adjust
After roughly four weeks (project experience) open cases, waiting times and returns show which stage is sticking. Deadlines and responsibilities get adjusted first, technology only afterwards.
Which case types genuinely require an approval today, how often do they occur and who signs them at present? The list is usually shorter than expected, and some approvals turn out to be habit without a substantive reason.
Responsibilities are described as roles and staffed with people. Value limits are kept to a few stages, each stated together with what the amount refers to.
Every role gets a named deputy. Deadlines are set per case type, as is the sequence of reminders and the point from which the deputy takes over.
Begin with a single, frequent case type, often the incoming invoice below a value limit. The workflow runs in parallel with the previous route for a few weeks until it holds.
After roughly four weeks (project experience) open cases, waiting times and returns show which stage is sticking. Deadlines and responsibilities get adjusted first, technology only afterwards.
A rollout in manageable steps
The mistake that most often derails a rollout is taking on too much at once. Converting every approval path simultaneously ties up the attention of the same people who carry the daily business for weeks, and meets resistance in several places at the same time. It works better to start with a single case type that occurs frequently and whose rules are uncontroversial. Incoming invoices below a value limit are a good fit, because they arise regularly, because the checking steps can be named clearly and because the benefit becomes measurable at the discount deadlines straight away.
The parallel run should be limited in time and have an end date. If the old route continues indefinitely, it gets used at the first bottleneck and the new workflow never takes hold. What works is a period of a few weeks with a fixed switchover date by which open cases from the old procedure have been completed. Training on real cases rather than on a manual belongs to the rollout as well: anyone who sees their own documents in the new workflow understands it within minutes. Part of this rollout work is the training and onboarding of the roles involved.
Write down the decisions you have taken, and keep it brief. One rule sheet per case type with trigger, stages, roles, value limits, deadlines and audit trail content is enough and actually gets read. These sheets are at the same time the core of the process documentation that will be needed anyway for onboarding, deputising and evidence requirements. Plan a review after roughly six months: value limits age, roles change, and a stage that has proved to be a mere formality can be dropped. An approval path is a working component, not a finished project.
A first step without any investment
Related Articles
Monitoring interfaces properly: beyond the server being up
Monitoring interfaces beyond availability: business-level checks, thresholds without false alarms, escalation to a named owner and logs with defined retention.
Automating file imports: six failure modes and their fixes
Daily file transfers between two systems: six typical failure modes from delimiters to duplicate deliveries, and how to check, log and report every one of them.
Shortening lead times: find the waiting, not the working
How to measure and shorten lead times: why waiting dominates, how to reconstruct it from existing timestamps and which three levers work in mid-sized companies.