What is the approval mechanism?
In SAP Business One, approval procedures route transactions, sales, purchasing and inventory documents, payments, to one or more authorizers when defined conditions are met. Until approval completes, the document waits as a draft and does not reach its target status.
This turns who may initiate what, who approves, and which thresholds require extra control into an institutional rule.
Core components
An approval setup has three building blocks:
- Approval templates: which document types, for which users, are subject to approval?
- Approval stages: how many levels, who is authorized at each level, how many approvals suffice?
- Conditions: what triggers the approval? Amount thresholds, discount rates, payment terms or query-based custom conditions.
Conditional and query-based approvals
For simple scenarios, the built-in conditions are enough: for example, purchase orders above a total amount threshold go to approval. Subtler needs call for query-based conditions: sales quotations below a margin threshold, documents posted to an over-budget cost center, or new orders for customers with overdue balances.
Query-based conditions turn the approval mechanism into a control layer that speaks your company's own business rules.
How does approval work on a document?
When a user saves a document and a condition applies, the document lands in the approval queue as a draft. The authorizer reviews it and approves, rejects or requests changes. The originator is notified of the outcome; an approved draft is converted into the actual document. Every step remains traceable with its history.
Which documents use it, and what triggers the process?
Approval procedures make sense on documents that commit the business or create a financial effect. In practice they are most often configured on purchase requests and orders, sales quotations and orders, inventory issue and transfer documents, outgoing payments, and documents carrying discounts or price exceptions.
What triggers the process is not the document itself but the condition met at the moment it is saved. If the condition does not apply, the document proceeds normally; if it does, it lands in the approval queue as a draft. That distinction is what keeps the mechanism from slowing operations unnecessarily.
How drafts fit in
A document sent for approval is saved as a draft rather than as the actual document. That is an important design choice from an ERP perspective: an unapproved commitment does not reserve stock, does not affect the account balance and does not create an accounting entry.
Once approval completes, the draft is converted into the actual document and all of its effects occur at that moment. A rejected draft remains in the system; the record is not lost and stays traceable with its justification.
"Orders awaiting approval" and "open orders" should therefore be read separately; putting both in the same report produces misleading results on the planning side.
Approval, rejection and resubmission
An authorizer can do three things: approve, reject, or request changes. An approved document moves to the next level or completes the process. A rejected document returns to the originator together with its justification.
Resubmission is the most frequently overlooked point in process design: when a rejected document is corrected and sent again, which level it restarts from has to be decided in advance. If the amount has not changed, starting over is unnecessary; if the amount has increased, not starting over is risky.
Tracking pending approvals and reporting
The most common cause of failure in an approval setup is operational rather than technical: documents sit in the queue and nobody notices. A tracking routine is therefore part of the design.
Who is holding pending approvals, and for how long, should be monitored regularly. Simple reports built on approval history quickly show where backlogs form and which threshold has been set unnecessarily low.
That measurement is also the most reliable input for simplifying the approval design over time.
A realistic example process
In a distribution business, the purchasing process might be designed like this: the buyer enters the order. If the order total is below the threshold defined for the department, it does not go to approval and proceeds directly.
If the amount exceeds the threshold, the document goes to the department manager as a draft. Once the manager approves, and if the amount also exceeds a second threshold, it moves on to finance approval, where it is assessed for budget and cash flow.
A query-based condition runs alongside: if the supplier has an overdue balance, the document goes to finance approval regardless of amount. When approval completes, the draft becomes an order; if rejected, the justification is returned to the buyer.
Common design mistakes
These are the mistakes seen most often in practice:
- Putting every document under approval: the queue swells, approval becomes a ritual and real control is lost.
- Setting thresholds once at implementation and never reviewing them.
- Not designing for delegation, so the process stalls when an approver is on leave.
- Trying to solve an authorisation problem with approval.
- Failing to define the resubmission rule for rejected documents.
- Showing drafts awaiting approval in the same report as open documents.
- Never reporting on approval history, leaving bottlenecks invisible.
Best practices
A few principles that work in the field:
- Few but meaningful approvals: putting every document under approval slows the process and turns approval into a ritual.
- Set thresholds to business reality and review them periodically.
- Plan for delegation: the process must not stall while an approver is on leave.
- Require written justifications; rejection reasons are input for process improvement.
- Report on approval history: where do backlogs form, which step is unnecessary?