Establishing an Internal Approval Process

In a company with 80 employees, a procurement request in the morning is just a simple email. By the afternoon, it needs approval from three managers, but one doesn't know exactly what framework they are deciding on, another is on vacation, and the third asks for an Excel file as a supplement. By the time the order is initiated, the supplier's offer may have expired, and production is waiting. The establishment of an internal approval process is not an administrative formality: it determines whether the company can operate in a controlled manner yet at an appropriate speed.

The problem is usually not that too few people approve. Rather, it's that no one is sure who is authorized for which issues, what information is needed for the decision, and what happens if the designated decision-maker is unavailable. In such cases, approval relies on personal memory, email chains, and informal consultations. This may seem flexible in the short term, but during growth, it leads to delays, errors, and disputes over responsibility.

When does the current approval process indicate a problem?

Not every decision requires a formal workflow. For a small-value, regular procurement or a daily operational correction, too much control can cause more harm than the risk it prevents. The problem starts when the same issue unpredictably takes a different route, or stakeholders only find out what happened afterward.

A typical situation is when finance receives an invoice without a clear order or delivery confirmation. The same happens with discounts, contract modifications, customer credits, onboarding new suppliers, and authorizing overtime. Decisions are often made, but there is no traceable record of who made them, based on what information, and under what conditions.

The human consequence of operations is also significant. Administrators repeatedly inquire about the status. Managers receive issues that should be decided by someone else. An experienced colleague becomes an invisible coordinator because they know who to contact and when an exception is acceptable. If they're not present, the process halts or continues on risky detours.

Establishing an internal approval process begins with real work

The most common mistake is that the company immediately looks for a form, workflow system, or approval button. These can be useful tools later, but first, it's essential to understand how work is done today.

Select a frequent yet business-sensitive issue type - such as procurement or customer discount - and follow through ten real cases. Don't ask how the process should work, but how it actually worked. Who initiated it? What data was provided? How many times was missing information supplemented? Who decided? Where was the decision recorded? What happened if someone didn't respond?

This examination usually reveals that some successive approvals are merely informational. It also happens that two managers check the same risk, while no one is responsible for a crucial aspect. For example, the procurement manager looks at the price, finance checks the budget, but no one verifies whether the purchased product is included in an approved request or contract.

The goal is not to incorporate as much control as possible. The aim is to ensure that every significant risk has an owner, while simple issues do not get unnecessarily stuck.

Decision categories and boundaries

In a well-functioning system, issue types are first distinguished. Different approval logic is needed for a new supplier, a stock replenishment order, a unique project expenditure, and a contractual obligation. If all follow the same route, the process will either be too slow or too loose.

Next, it's advisable to define clear decision boundaries. The amount alone is insufficient. The type of cost, contract duration, deviation from the approved budget, impact on the client or production, and whether the transaction is with a new or existing partner can all matter.

For a recurring, budgeted raw material order, for example, the approval of the area manager may suffice. However, a new, multi-year service contract may require legal, financial, and business decisions. The number of approvers is not the key, but that the appropriate role answers the appropriate question.

Without mandatory data, there is no substantive decision

The decision-maker should not have to piece together the case from emails and attachments. If this happens, the approval time will be longer, and the chance increases that two cases will receive different evaluations based on incomparable information.

For each issue type, the minimum data package required to initiate approval must be defined. For procurement, this typically includes the reason for the request, the amount, the cost center, the supplier, the offer or contract, the required deadline, and budget coverage. For discounts, other data matters: the client, usual price, requested deviation, reason, expected business impact, and validity period.

Mandatory data is not bureaucracy. Its purpose is to ensure that the information needed for the decision enters the process once, not requested separately by three different people.

Responsibility, substitution, and escalation

The approval matrix is usable if it contains roles, not just names. A name-bound process quickly becomes outdated due to reorganization, vacation, or departure. A role-based rule, however, is more sustainable: for example, area manager, financial manager, executive, or procurement officer.

Every critical approver must have a designated substitute and clear authority. Substitution should not mean that anyone can take over any decision. It must be recorded in which cases they can act, up to what amount, and whether subsequent notification or confirmation is required.

Escalation is also essential. If a decision waits for two business days, what happens? Is there an automatic reminder? Does it go to the substitute? Does the process owner receive a notification? This is especially important for production, logistics, and client deadline-bound issues, where delay poses direct revenue or service risks.

What to measure before choosing a system

Digitalizing the process only improves operations if it addresses a measurable problem. Initially, a complex dashboard is unnecessary. A few indicators can already show where there is a bottleneck: average approval time, the proportion of overdue issues, the number of requests returned for missing information, the proportion of exceptional treatments, and the number of cases modified or withdrawn after approval.

These should also be examined by issue type, organizational unit, and value threshold. It may be that the overall average is acceptable, but onboarding new suppliers regularly takes ten days. It may also happen that a managerial level handles all issues quickly, while requests are stalled at the beginning of the process due to incorrect or incomplete data.

Measurement helps avoid misleading solutions. If the main issue is poorly filled requests, a new approver won't solve it. If decision-making powers are uncertain, a faster notification won't eliminate the delay.

When is technical support justified?

If the rules are stable, the number of cases increases, or the same data needs to be managed in multiple systems, technological support may be justified. This can be a function of the existing enterprise management system, an integrated internal form, a document management process, or a custom application. The appropriate solution depends on where the demand arises, where the master data is located, and what level of auditability is required.

A discount related to a webshop, for example, cannot be well managed via separate email if the order, customer data, inventory, and billing exist in other systems. In such cases, the flow of information must be designed, not just adding electronic approval. In other cases, however, a simple, central registry and well-defined notification may be sufficient as a first step.

A good system does not make the decision invisible. On the contrary, it shows where the issue stands, who the next responsible person is, what information the decision was based on, and what exception occurred. This makes the process auditable without everyone constantly questioning each other.

The approval process is mature when a new colleague understands how to initiate an issue from it, and a manager can see in a few minutes what awaits decision and why. This is not a spectacular development, yet it is one of the prerequisites for predictable growth: the company's decisions remain in a functioning system, not in the memory of individuals.