Approval
The Approval add-on puts a sign-off step in front of transactions. Nothing posts to the ledger until the right people have agreed to it, which gives you consistent control across every module, a visible history of who approved what, and no premature accounting entries.
Overview
Approvals run on levels. A transaction is created, works its way up through the approvers you have defined, and only becomes final when the top-level approver signs it off. Until then it exists but does nothing to your books.
Supported Transaction Types
| Module | Transactions covered |
|---|---|
| Sales | Sales Quotation, Sales Order, Delivery Note, Sales Invoice, Customer Payment, Customer Credit Note. |
| Purchase | Purchase Order, GRN, Purchase Invoice, Supplier Payment, Supplier Debit Note, Expense. |
| Manufacturing | Work Order, Work Order Issue, Work Order Production. |
| Inventory | Inventory Adjustment, Inventory Disposal, Location Transfer. |
| General Ledger | Journal Entry. |
More types are added over time.
Transaction Statuses
| Status | Meaning |
|---|---|
| Waiting | Awaiting action from an approver. |
| Pending | Under review by the approver it reached. |
| Approved | Signed off at that level. |
A user creates a transaction, it becomes Waiting for the next approver, and that approver sees it as Pending.
A one-line example
On a three-level purchase order chain, a buyer raises order 071/2026; the purchasing manager approves it; the finance head approves it and the order is live. Had the manager rejected it instead, it would have gone straight back to the buyer and finance would never have seen it.
Worked examples follows that order, a rejected one, and one that bypassed approval altogether — with the setup behind each and the log it produced.
Approval Actions
| Action | What it does |
|---|---|
| Approve | Sends it to the next level, or finalises it if you are the top-level approver. |
| Reject | Returns it to the creator with your comments. |
| Edit | Modify and approve in one step, where your permissions allow it. |
Only the top-level approver can finalise, and only after every prior level has approved. That is what stops a transaction reaching the ledger through a shortcut in the middle of the chain.
Notifications
| Event | Who is notified |
|---|---|
| Transaction created | The immediate upper-level user or users. |
| Rejected | The creator and all previous approvers, with the reasons included. |
| Approved | The next level up, until the chain completes. |
| Final approval | Everyone involved, confirming the transaction is now live. |
Linked Transactions and Financial Controls
Transactions that depend on one another — an order and its deliveries, a delivery and its invoice — are handled as parent and child, and the approval state of one governs what can happen to the other.
| Control | Effect |
|---|---|
| Direct invoices | Parent transactions cannot be created until the invoice is approved. |
| GL entries | Not generated until top-level approval. Nothing touches the ledger early. |
| Child blocking | Further children are blocked while an existing one is still unapproved. |
| No auto-generation | Parent transactions are not created automatically for standalone documents. |
For example: a delivery is completed but not yet approved, so the order stays unapproved, which prevents any further delivery against it.
Benefits
| Benefit | What it gives you |
|---|---|
| Consistency | One control mechanism across every module. |
| Transparency | The status history of any transaction is visible. |
| Financial accuracy | Nothing posts before it is authorised. |
| Flexibility | Different order types can carry different approval chains. |
Where to go next
- Approval Setup — defining levels and transaction types
- Approval Inquiry — approving and tracking transactions
- Worked examples — three transactions followed end to end, with sample logs
- Designation Group — what approval levels are assigned to