Document Approvals

By the end of this guide, a purchase order raised by your buying team will go to a manager for approval by e-mail, level by level — and you will know exactly what to check when it doesn’t. Know one thing from the start: the approval does not hold the order back. It turns FINAL at the first approval, and nothing locks it while it waits. Setting it up takes about 30 minutes the first time.

Before you start, the single most important thing to understand: approvals in BigLedger are optional and switched off until you build them. A fresh tenant has no approval settings at all. Purchase orders save, finalise and turn into goods received notes with nobody signing anything. Nothing breaks, nothing is queued, nothing is waiting. If your business is happy with that, you can close this page. Approvals are here for the day you want a paper trail, not because BigLedger insists on one.

Meet GadgetSphere

GadgetSphere Sdn Bhd runs 22 consumer electronics branches across Malaysia. Branch managers raise purchase orders for stock all day long, and until now nobody looked at them before they went to the distributor. After a RM 180,000 order for the wrong laptop model went out from GS-KV-03, the finance director asked for a rule: anything a branch orders gets a second pair of eyes, and anything big gets a third. This guide sets that up.

Setting up approvals, at a glance

Build the approval setting: its levels, a quorum per level, and a Min Approval Amount that rises with the level (Step 1).
Create the submitter designation and link it to the setting, with a code that matches the setting’s Submitter Designation Code exactly (Step 2).
Put the approvers under that designation, each with an approval level and an e-mail address on their employee record (Step 3).
Add the Approval Monitor row Purchase Requisition → Purchase Order, with Document Conversion Required unticked unless every purchase order must come from an approved requisition; without the row, the Add button on the purchase order’s approval tab stays greyed out (Step 4).
Submit a purchase order for approval, choosing the submitter first and the setting second. The order is set to FINAL as soon as the first approver approves, not when the last level does, and nothing locks it while it waits (Step 5).

Step 1 is on this page. Steps 2 to 5 are on Designations, approvers and submitting, and the other approval mechanisms in BigLedger are on Approvals elsewhere.

What can and cannot be approved

This is the shortest section and the one people get wrong most often.

Three document types can have approvals:

Purchase Requisition
Purchase Order
Stock Requisition

Everything else cannot. There is no approval engine for sales orders, sales invoices, sales quotations, delivery orders, goods received notes, purchase invoices, payment vouchers, receipt vouchers, journals, stock adjustments or stock transfers. If a colleague tells you they need a sales invoice routed to a manager before it posts, BigLedger will not do that for you — that has to be a company rule enforced by who you give the permission to, not a queue the system manages.

One thing will look like a counter-example: the Sales Order applet has an Approval menu and a per-line Approval Status. That is a price-floor override, not a sign-off. When a line is blocked for selling below the minimum price or cost, a supervisor types their own login on the line to release it; the release is recorded against that line and nothing else happens — no e-mail, no routing, and the order is not finalised by it.

Approvals are not the Workflow Design Applet. The Workflow Design Applet looks like an approval builder — it has statuses, transitions and roles — but it only puts a label on a document and filters who may change that label. It sends no e-mail and runs no approval. The nearest it comes to a gate is an applet setting (Final Status) that hides the FINAL button inside a document until the document is saved at a chosen status — and only on the screens that read it: the sales order, sales return, sales refund note, packing order and Shopee order. The purchase order, sales invoice and sales credit note ignore it, so on the purchase documents this guide is about it holds nothing back. Where it does work, it holds the open document only: the listings of the first four have a FINAL button for ticked rows that never reads it, and the backend never checks it, so an API client can still finalise (which screens read it). Approvals live in each applet’s own Settings → Approval Settings. The two systems never talk to each other.

Today, only the Purchase Order and Purchase Requisition applets give you the whole loop — settings, a submit button on the document, an approver’s queue and a history. The Stock Requisition applet has the Approval Settings screen but no way to submit a requisition against it yet, so treat that screen as configuration for later.

The three things you have to set up

Approvals need three separate pieces, in this order (a purchase order needs a fourth, below). Miss one and submission fails with an error that names a database table, so it is worth doing them in order.

An approval setting — the levels themselves (Settings → Approval Settings).
A submitter designation, linked to that setting — the group of people whose documents the rule catches (Settings → Branch → Designation). The designation form asks you to pick an approval setting, which is why the setting comes first.
Designation employees — the approvers for that designation, each at an approval level (Settings → Branch → Designation → Designation Employee).

For a purchase order there is a fourth, and it fails quietly: the Approval Monitor row Purchase Requisition → Purchase Order. Without it the Add button on the order’s approval tab stays greyed out (Step 4).

The one idea that makes the rest make sense: the approvers are listed under the designation of the person submitting, not under a designation of their own. BigLedger never goes looking for “the branch managers”; it asks whoever you placed under the submitter’s designation, level by level.

Step 1: Build the approval setting

Purchase Order Applet → Settings → Approval Settings → Add

This is the rule itself. For GadgetSphere’s Klang Valley branch 03, the header reads: Approval Setting Code PO-KV03, Approval Setting Name PO approval – GS-KV-03 staff, Branch GS-KV-03 (the Company, GS, fills itself in from the branch), Server Doc Type INTERNAL_PURCHASE_ORDER, Submitter Designation Code Staff, and Total Required Approval Levels 2. What the screen does not tell you about those fields:

The name is what people choose by. When someone adds an approval to a purchase order, the Approval Setting list shows every setting for that document type — from every branch and company — by name alone. Nothing makes the code or the name unique, so two settings both called PO approval are indistinguishable in that list. Put the branch in the name.
Branch and Company do not route anything. The approval engine never reads them: the route is whichever setting the person adding the approval picks on the document. They are stored with the setting, and an API caller can filter the settings list by them, but no step of submission or routing looks at them. So if GadgetSphere wants different approvers in Penang and the Klang Valley, that is one setting per branch — and choosing the right one is the submitter’s job, because BigLedger will not stop a Penang buyer choosing PO-KV03. The check is the first e-mail: if it reaches another branch’s manager, the wrong setting was picked.
Submitter Designation Code is the link to the approvers. Picking a setting on the document copies this code onto the approval. BigLedger then looks for the designation with exactly this code (Staff and STAFF are different) that is linked to this setting, and asks the people under it — that is Steps 2 and 3.
Total Required Approval Levels is the most levels a document can need, not the number every document gets. The screen keeps one level panel per level, on Add and on Edit, so the rows always match the number you type. At submission BigLedger checks that the designation’s approvers cover at least this many different levels. How many levels a particular document actually needs is set by Min Approval Amount, below.

Then fill in one panel per level. GadgetSphere’s two:

Approval Level	Approval Quorum	Min Approval Amount	Approver Designation
1	1	0	`BRANCH-MGR`
2	1	10000	`FIN-DIR`

Read that as: every purchase order needs one of the two branch managers to approve it, and orders of RM 10,000 or more additionally need the finance director.

Four fields on these panels deserve a warning:

Approval Quorum is how many approvers at that level must act. Set it to 1 and either branch manager can clear the level. Set it to 2 and both must. If you set a quorum higher than the number of people you actually assigned at that level, BigLedger quietly lowers it to the number of people available — it will not deadlock, but it also will not be the rule you thought you wrote.
Min Approval Amount does not choose a different approver. It decides how many levels apply to this document. BigLedger counts the levels whose Min Approval Amount is less than or equal to the document total and requires that many — starting from level 1. A RM 4,000 order at GadgetSphere needs one approval; a RM 45,000 order needs two. This is the only place a money figure changes anything, and it is why the amounts must rise with the level: put RM 10,000 on level 1 and RM 0 on level 2, and a RM 4,000 order still counts one level — level 1 — so it goes to the person you meant only for big orders.
Approver Designation is a label. It is copied onto each approval request, but it does not decide who is asked — the people under the submitter’s designation do (Step 3).
Approval Logic (Any to Approve / All to Approve) and Max Approval Amount are collected by the screen and stored, but nothing reads them — neither appears anywhere in the backend outside the table and query-criteria classes, and in the applet layer only on the settings form that writes them. Whether one approver is enough is decided purely by the quorum, and Max Approval Amount has no effect at all. Leave them alone rather than relying on them.

If you get this wrong: you cannot, on this screen — the level panels follow the number. The backend also rejects a new setting whose level rows do not match Total Required Approval Levels, but it does not repeat that check on an edit, so a setting changed through the API can end up with more rows than the number says. The number then only sets the approver check at submission; the rows are what route.

Next: Step 2, create the submitter designation.

What success looks like

Thirty seconds, on a test purchase order:

Raise a purchase order for about RM 500. Open its Generic Doc Approval tab. The Add button should be clickable — if it is greyed out with a tooltip about requisitions, Step 4 is missing.
Add an approval (submitter first, then the setting), select it, click Submit For Approval. The row’s Approval Status should read PENDING_APPROVAL, Processor Posting Status should read PROCESSOR_SUCCEED, and Email Notification Status should read EMAIL_SENT_TO_APPROVER.
The level 1 approver should have an e-mail. Click through, approve, add a remark.
Go back to the purchase order. Because RM 500 is below RM 10,000 only one level applied, so the approval status should now be APPROVED and the purchase order’s posting status should have moved to FINAL on its own.

If all four hold, you are done. Repeat once with an amount over RM 10,000: the finance director should get the second e-mail, and the purchase order should already read FINAL before they answer it. That is expected — see the warning in Step 5.

Common mistakes

The error messages and symptoms that belong to Steps 2 to 5 — Submitter designation_code is not created, There is no approver assigned, Resigned submitter cannot submit document, EmployeeBranchDesignationLink_IS_NOT_FULLY_CONFIGURED, the approver who never got an e-mail, the approver whose Approval Request list is empty, and the purchase order finalised while it was waiting — are on Designations, approvers and submitting, beside the steps that cause them. This one belongs to the whole task:

Expecting features that are not there There is no approver delegation or stand-in for these documents, no escalation when an approval goes stale, no reminder e-mails, no approval SLA, no mobile approval app and no rule that sends a big document to a different person. Approvers act from the link in their e-mail or from the applet.