Document Approvals

By the end of this guide, a purchase order raised by your buying team will sit and wait for a manager’s e-mailed approval before it goes anywhere — and you will know exactly what to check when it doesn’t. 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.

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.

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. Miss one and submission fails with an error that names a database table, so it is worth doing them in order.

1. An approval setting — the levels themselves (Settings → Approval Settings).
2. 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.
3. Designation employees — the approvers for that designation, each at an approval level (Settings → Branch → Designation → Designation Employee).

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:

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.

Step 2: Create the submitter designation and link it to the setting

Purchase Order Applet → Settings → Branch → select your branch → Designation

A designation is a group with a code. Here you need exactly one: the designation whose code matches the setting’s Submitter Designation Code. For GadgetSphere, create it on GS-KV-03 with Code Staff, Name Branch purchasing staff, and Approval Setting PO-KV03.

Two rules the form does not show:

• One designation per code per setting, across the whole tenant. Once a Staff designation is linked to PO-KV03, a second Staff linked to the same setting is refused, even on another branch. For another branch’s approvers, build another setting (Step 1) and link a Staff designation to that one.
• You do not need designations for the approvers themselves. A BRANCH-MGR or FIN-DIR designation is harmless, but BigLedger never reads it when routing a Staff document. The approvers go under Staff, in the next step.

Most common failure here: the code does not match exactly, or the designation is linked to a different setting. Nothing complains now; it shows up at submission as the “Submitter designation_code is not created” error (the first entry in Common mistakes). That message means “no designation with this code is linked to the setting you picked”.

Step 3: Put the approvers under the designation, with a level

Purchase Order Applet → Settings → Branch → select your branch → Designation → Staff → Designation Employee

Here you add the approvers and, for each one, an Approval Level. The level is a number: 1 is the first person to see the document, 2 is the next, and so on. Each person you add takes the designation’s code and its linked setting with them — that is how BigLedger finds them.

For GadgetSphere, under Staff:

Two people at level 1 is deliberate — it means either of them can clear the first level, so a purchase order does not sit still while one of them is on leave. You control how many of them have to act with the level’s Approval Quorum (Step 1).

Every approver needs an e-mail address on their employee record. The whole approval flow is driven by e-mail. If the address is blank the approval still gets created, but the approver is never told; you will see APPROVER_EMAIL_IS_EMPTY in the Email Notification Status column and nothing will happen until someone chases it by hand.

Step 4: Tell the Approval Monitor that a PO may stand on its own

Purchase Order Applet → Settings → Approval Monitor

This one catches almost everybody, and the symptom looks nothing like the cause.

The Approval Monitor holds pairs of document types and answers one question: must the second document have been converted from the first before it can be submitted for approval? For purchase orders, BigLedger always asks that question about the pair Purchase Requisition → Purchase Order.

If there is no Approval Monitor row for that pair at all, the check errors, and on the purchase order’s Approval tab the Add button is greyed out with the tooltip “Purchase Order needs to be converted from Purchase Requisition” — even for a perfectly ordinary standalone PO.

So create the row:

GadgetSphere leaves it unticked because branches raise purchase orders directly. Tick it only if your policy is that every purchase order must come from an approved requisition — in which case BigLedger will additionally check that the source requisition exists and was approved, and will copy that requisition’s submitter onto the new approval.

Step 5: Submit a purchase order for approval

Purchase Order Applet → open a saved purchase order → Generic Doc Approval tab

Now the daily use. Open a purchase order, go to the Generic Doc Approval tab, click Add, choose the submitter (the employee raising it) and the Approval Setting (PO-KV03 for a GS-KV-03 order), and save. Then select the row in the grid and click Submit For Approval.

Choose the submitter first and the setting second. Choosing the submitter fills Submitter Designation with their Job Title from the Employee applet; choosing the setting replaces it with the setting’s Submitter Designation Code — which is what the approver lookup needs. The other order leaves the Job Title there, and unless it happens to equal the setting’s code the submission fails with the designation error in Common mistakes.

An approval that arrives with no setting at all — through the API, for example — is routed differently: BigLedger looks for a setting for this document type whose Submitter Designation Code matches the submitter’s Job Title, and falls back to the designation Staff when none does. That fallback is why Staff is the conventional code.

What happens next, in order:

1. The approval goes to Pending Approval.
2. BigLedger works out how many levels apply from the document total and the Min Approval Amounts.
3. It creates one request per approver at level 1 and e-mails each of them.
4. The e-mail contains a link. The approver clicks it and lands on a plain web page showing the document number, date, total, currency and lines, with Approve and Reject buttons and a remarks box. Remarks are compulsory. Approvers can also work from the Approval Request screen inside the applet if they prefer.
5. When level 1’s quorum is met, level 1’s outstanding requests disappear and level 2’s approvers are e-mailed.
6. When the last required level approves, the approval status becomes APPROVED and BigLedger stamps the final approval date.

If anyone rejects, the whole approval goes to Rejected, the submitter gets an e-mail with the rejection remarks, and every outstanding request is cleared. The purchase order itself is untouched — it stays exactly as it was. To try again, fix the document and click Resubmit, which starts a fresh cycle from level 1.

What success looks like

Thirty seconds, on a test purchase order:

1. 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.
2. 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.
3. The level 1 approver should have an e-mail. Click through, approve, add a remark.
4. 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

“Submitter designation_code is not created in bl_fi_mst_branch_designation” No designation with the approval’s Submitter Designation code is linked to the setting you picked — either it was never created, it is linked to another setting, or the submitter was chosen after the setting and put their Job Title there (Step 5). Go back to Step 2. The message also asks you to contact a developer — you don’t need to; it is a configuration gap, not a bug.

“There is no approver assigned in bl_fi_mst_employee_branch_designation_link” The designation exists but nobody is in it. Step 3.

“Resigned submitter cannot submit document” The employee you chose as the submitter has a resignation date on their entity record that has already passed. Pick a current employee, or clear the resignation date if it was entered by mistake.

“EmployeeBranchDesignationLink_IS_NOT_FULLY_CONFIGURED” You asked for more approval levels than you have distinct levels of people. If Total Required Approval Levels is 2, at least one person must sit at level 1 and at least one at level 2.

The approver says they never got an e-mail Check the Email Notification Status column on the approval grid. APPROVER_EMAIL_IS_EMPTY means the employee record has no e-mail address. FAILED_GENERIC_DOC_APPROVAL_PENDING_APPROVAL_NOTIFICATION means the tenant has no e-mail template configured for pending approvals — nothing was sent at all, so no amount of waiting will help.

The approver logs in but their Approval Request list is empty BigLedger matches approval requests to the signed-in user through their employee record. If the login has no matching employee in the Employee applet, the screen errors with “Cannot find your email … from Employee Applet”. The e-mail link still works in the meantime.

Someone finalised the purchase order while it was waiting That is not a fault; nothing stops it. If the sign-off matters, control who holds the permission to finalise purchase orders rather than expecting the approval to block them.

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.

Looking for approvals somewhere else?

Approvals get asked about across the whole product, so here is the complete picture in one place. Counting the purchasing engine above, BigLedger has five approval mechanisms. The other four use the same word, and none of them will give you sign-off on a sales invoice, a payment or a journal.

Expense claims — a separate engine, and it is always on. The Claim applet has its own approval settings, and unlike purchasing it is not optional: a claim goes through it. It is also the only place in BigLedger with approver delegation — a delegation period screen that hands an approver’s requests to a stand-in while they are away. If you have seen delegation working and wondered why purchase orders do not have it, that is why. See the Claim Applet.

Returns (RMA) — approve or reject, and that is the whole thing. An RMA submission carries a single status that moves between Pending Approval, Approved and Rejected, and BigLedger sends the customer an e-mail when it lands on one of the last two. There are no levels, no quorum, no amount thresholds and no settings screen. It is a decision field, not an engine. The separate RMA Staff / HQ / Supplier family has a per-item head-office approval flag of the same kind — a field, a permission on the button, and nothing behind it.

Budgets — the engine exists in the backend, but there is no screen. BigLedger’s code carries a budget-register approval engine built to the same pattern as the purchasing one. The Budgetary applet ships no approval screen to drive it, so there is nothing to switch on today. Do not plan around it.

Workflow Design — labels, not approvals. Covered in the warning near the top of this page, and worth repeating because it is the single commonest misunderstanding: it puts a status on a document and controls who may change that status. It does not e-mail anyone, and its only hold on posting is the browser-side Final Status setting described above. The status track is also enforced in the browser only, so an API client can set any status on any document. See the Workflow Design Applet.

And everything else has nothing. Sales orders, sales invoices, quotations, delivery orders, goods received notes, purchase invoices, payment vouchers, receipt vouchers, journals, stock adjustments and stock transfers have no approval mechanism of any kind. The control you have on those is who holds the permission to finalise them — set that up in the applet’s Settings → Permission screens instead.

Related documentation

• Purchase Order Applet — the field-level reference for Approval Settings, Approval Monitor, Approval Request and Approval History.
• Purchase Requisition Applet — the same approval loop on requisitions.
• Stock Requisition Applet — has the Approval Settings screen, but no way to submit against it yet.
• Workflow Design Applet — the other thing that looks like approvals, and what it actually does.
• Employee Applet — where approvers’ job titles and e-mail addresses live.