Best Practices
If you are setting BigLedger up, or you have inherited a tenant somebody else set up, this page is the short list of habits that separate a set of books that balances from one that takes three days to unpick at month end. There are five of them. Reading takes about ten minutes; acting on them takes an afternoon and saves considerably more than that.
This is not a list of general management advice. Every item here is a behaviour of BigLedger specifically, and every one of them is something we have watched go wrong.
Meet GadgetSphere
GadgetSphere Sdn Bhd is a Malaysian consumer-electronics group: 22 retail branches, an online arm and a distribution company, around 5,200 active SKUs and 28 cashbooks. The examples below use its numbers. Your business is probably smaller, and every one of these still applies.
Practice 1: Know which document is the one that counts
This is the single most valuable thing on this page, and it surprises almost everyone.
On the sales side, only two documents move stock and post to your ledger: the Sales Invoice and the POS Cash Bill. A quotation, a sales order, a goods delivery note and an outbound delivery order all record intent. They are worth raising — they close each other off, they drive picking, they give the customer paperwork — but the numbers in your accounts and the quantities in your stock balance do not move until an invoice or a cash bill is finalised.
Note the distinction between balance and available: an open sales order does reduce the available quantity BigLedger shows you, so the warehouse does not promise the same unit twice. It just does not take it out of stock.
So when a branch manager at GS-KV-01 tells you 40 flagship smartphones left the shop this morning against 40 sales orders, and the stock report still shows 40 on hand, nothing is broken. Nobody has invoiced them yet.
On the purchasing side it is the mirror image. A standard Goods Received Note records the count and knocks the purchase order down, but does not add to your stock balance; the purchase invoice does. (Some tenants are configured the other way round, with a Purchase GRN Stock In / Purchase Invoice No Stock In pair that books stock on receipt instead. Your company runs one pair or the other, never a document from each.)
What to do about it: write down, for each of your workflows, which document is the posting document — and tell everyone who reads a stock report. Then never plan inventory off order volumes.
How this goes wrong: somebody reconciles stock against sales orders, finds a gap of 400 units across the branches, and spends a week looking for theft that is actually just uninvoiced deliveries.
→ Standard sales workflow · Goods Received Note processing · Purchase invoice processing
Practice 2: Set your default GL codes before anybody raises a transaction
Chart of Account applet > Company Default GL Codes
BigLedger works out the journal for a document from your company’s default GL codes — the account to debit for sales, the account for output tax, the receivable account, and so on. It looks them up at the moment you finalise the document, not when you create it.
If one of them is missing, the finalise fails with MISSING_DEFAULT_GL_CODE or COMPANY_DEFAULT_GL_CODE_NOT_EXIST, naming the mapping it could not find. Nothing is lost — the document stays as a draft — but the person who hits it is a salesperson at 5pm on the last day of the month, not you.
What to do about it: complete the default GL code mapping for every company in the group before go-live. GadgetSphere has three — GS, GSO and GSD — and they each need their own set. Then raise one test document of each type you actually use and finalise it.
How this goes wrong: the mapping is done for the main operating company only. The distribution company’s first invoice fails three weeks later, in front of a customer.
→ Chart of accounts setup · Chart of Account applet
Practice 3: Treat credit control as a scheduled job, because that is what it is
BigLedger does not work out a customer’s exposure while you type. There is no running total that stops a sales order at the point of save because it would breach a limit.
What actually happens is a background job called Blacklist Overdue Customer. When it runs it totals each customer’s outstanding documents, compares that to their credit limit, checks for overdue credit terms, and flags the ones that fail as blacklisted. Separately, when somebody saves a Cash Bill, Sales Invoice, Sales Order or Outbound Delivery Order for a customer who already carries that flag, BigLedger refuses it with “Customer is blacklisted due to credit limit. Transactions are not allowed for this customer.”
Three consequences follow, and all three matter:
- The block is only as current as the last run of the job. If it ran last night and a customer has blown through their limit this morning, today’s orders go through.
- Nothing outside those four document types is blocked at all. A quotation, a delivery note or a credit note for a blacklisted customer saves normally.
- The available-credit figure on the order screen is information, not a gate. It is shown so the person raising the document can see the position; nothing refuses the document because of it.
- The job clears every existing blacklist flag before it recalculates. So a blacklist somebody set by hand on a customer you have decided not to trade with does not survive the next run.
What to do about it: schedule the job, know its schedule, and if you need a permanent stop on a customer, do it with something other than the blacklist flag — a credit limit of zero survives the recalculation, a hand-set flag does not.
How this goes wrong: a finance manager blacklists a disputed account on Friday, the job runs over the weekend, and the account is trading again on Monday.
Practice 4: Do not rely on a second approval level to stop anything
If you have set up document approvals on purchase orders, purchase requisitions or stock requisitions, there is one behaviour you need to know before you design the rule: the document is set to FINAL when the first approver approves it, not the last.
The approval record itself behaves correctly — level 2 is still created, the approver is still e-mailed, and the approval is not marked complete until they act. But the purchase order has already moved to FINAL and can be acted on. If the reason you built a second level was to stop a large order until a director has seen it, it does not stop it.
What to do about it: use approval levels to record sign-off, not to enforce a hold. Where a genuine hold is needed, keep the amount below the threshold that lets the document be raised at all, or keep the raising permission with the person who should be deciding.
How this goes wrong: a two-level rule is built for orders above RM 50,000, everybody believes the director is the gate, and the supplier ships on a FINAL order the director never saw.
Practice 5: Always pull the previous document in — never re-key it
Every workflow in BigLedger has a way to bring the earlier document into the later one: Search Document on a draft, the KO For tab on a new one, or the Import tab. Use it, every time, even when the document has two lines and typing looks faster.
The link it creates is what closes the earlier document off. Without it:
- the purchase order stays open forever, and your outstanding-order report is fiction;
- accounts payable has nothing to match the supplier’s bill against, so quantity disputes have to be settled from paper;
- the quantities drift, because a re-keyed line is a line somebody typed from memory.
What to do about it: make “search, don’t type” the first thing you teach a new user, and spot-check the open purchase order list monthly for orders that were received months ago and never closed.
What success looks like
Thirty seconds, and you can do it today:
- Open your stock report and your sales order list side by side. If somebody can explain the difference between them in one sentence — “those are ordered, not invoiced” — Practice 1 has landed.
- In the Chart of Account applet, open Company Default GL Codes for each company in your group. Every row you use has a code against it, with no blanks.
- Open your open purchase order list and sort by date. Nothing on it is older than your longest genuine lead time.
If all three hold, the things on this page are not going to bite you.
Common mistakes
| What happens | What it looks like | The fix |
|---|---|---|
| Stock is reconciled against sales orders | A persistent, unexplainable shortfall that moves around between branches | Reconcile against sales invoices and cash bills — the only sales documents that move stock |
| Default GL codes set for one company only | MISSING_DEFAULT_GL_CODE on the first document in the second company, weeks after go-live | Map defaults per company, then finalise one test document of each type in each |
| Credit limits are assumed to block at save | A customer well over their limit keeps ordering | Check when the Blacklist Overdue Customer job last ran; it is the thing that sets the flag the block reads |
| A manual blacklist is used as a permanent stop | The customer is trading again after the next run of the job | Set the credit limit itself; the job recalculates flags but does not rewrite limits |
| A second approval level is treated as a hold | A FINAL purchase order nobody senior approved | Treat levels as sign-off records; enforce holds with permissions |
| Documents are re-keyed instead of searched | Purchase orders that never close; invoice quantities that do not match receipts | Use Search Document / KO For / Import every time |