Approvals by value limits: the four-eyes principle in the ERP

A purchasing employee orders software licenses, materials or a service. The order goes out, the invoice arrives, and only in accounting does anyone notice that nobody else ever saw it. The result: follow-up questions, retroactive approvals by email, and invoices that sit unpaid because it is unclear who agreed to them. The opposite extreme costs time as well: if management has to sign off on every small order, requests pile up and employees start ordering outside the system.

Approval thresholds solve both problems. Small amounts go through without a hurdle, while larger ones need a second person. That is control without the brake.

First, clarify: What should the four-eyes principle protect?

The principle says: whoever initiates a transaction does not approve it alone. In purchasing, this usually involves three risks: orders without a budget, orders from unvetted suppliers, and orders that someone places for their own benefit.

Before any configuration, write down which risk you want to cover. That determines which levels you need. If you only want to prevent budget overruns, a few levels will be enough.

Check question: for every level you plan, can you say in one sentence which risk it covers? If not, remove the level.

Setting thresholds: The case of the order placed in between

Take a typical situation: purchasing orders consumables for warehouse operations. The amount is small and the supplier is known. An approval would be pure delay. The next day, the same employee orders a machine. Here a second person needs to take a look.

Here is how to proceed:

1. Pull the orders from recent months out of the system and sort them by amount.
2. Look for the points where the amounts jump noticeably. Natural thresholds lie there.
3. Set the first threshold so that most routine orders stay below it.
4. Set a second threshold where you want to involve management or the head of finance.
5. Record the amounts in writing, with the date and the person responsible for setting them.

Decision rule: if more than just the occasional order is waiting for approval, the threshold is too low. If you find orders during audits that you would rather have seen, it is too high.

The specific amounts depend on your size and your risk. A figure from another company will not help you.

Defining approvers: Roles instead of individuals

An order is waiting because the department head is on vacation. This happens when approval depends on a name.

Assign approvals to roles, such as department head, head of finance and management, and designate at least two people per role. That way, the process keeps working during vacations or sick leave.

Keep three principles in mind:

• The person placing an order never approves their own order, even if they hold the higher role. In that case, the next higher level must step in.
• Approval is based on the total amount of the order, not on the individual line item. Otherwise, amounts can be split into partial orders.
• The approver must be able to judge, on the merits, what they are approving. An approval that is merely waved through is not a control.

How this is implemented in the ERP

In Odoo, and therefore also in Simplify-ERP, approvals by value threshold are part of the purchasing module. The process is, in principle, the same as in other ERP systems: the order remains a draft, or in a "to approve" status, as long as the amount is above the threshold. Only the authorized person confirms it, and then it goes to the supplier. Below the threshold, the system confirms automatically.

The setup determines whether the process holds up. Clarify beforehand how roles, master data and users relate to each other in your company. If you only discover later, during requirements analysis, that roles are unclear, you end up configuring twice. So define thresholds, roles and substitutes on paper before anyone changes a setting in the system.

Check question: can someone from the business department understand, from your documentation alone, who approves at which amount?

Approval in daily work: What the approver needs to see

An approver receives a request. If they first have to ask five follow-up questions, the process loses its purpose. At a glance, they need:

• Supplier and total amount
• Purpose, cost center or project
• Comparison quotes, if available
• A note on whether a framework agreement exists

Define the maximum time an approval may wait, and who sends a reminder or escalates once that time has passed. Escalating to the substitute is better than having the requester work around the process.

Decision rule: if approvers regularly come back with questions, the order is missing information. Add a mandatory field, not an email.

Traceability: Who approved, and when?

In an audit by tax advisors or auditors, what counts is that you can prove who gave approval. The approval should be recorded on the transaction itself, not in an email in a personal inbox. If you also keep an audit log that records changes to amounts and suppliers, you can also see whether someone changed an order after it was approved.

Set a rule: if the amount changes after approval, the approval becomes invalid and runs again. Otherwise, the value threshold can be circumvented with a trick.

Handle exceptions with rules instead of tolerating them

Urgent orders do occur: a breakdown that needs a replacement. If you provide no path for these, you will see workarounds.

Define a fast-track route: a named person may approve outside the usual level, the justification is recorded on the transaction, and the head of finance reviews such cases regularly. What often appears as an exception is usually a threshold that is too low or a missing framework agreement.

Your next step

Today, pull the orders from recent months out of your system, sorted by amount. Mark the orders where, in hindsight, you would have wanted a second person involved. Next to each, note the lowest amount. That is your candidate for the first threshold. In addition, write down, for each level, one role and two people who may approve.