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, nothing before the sale posts to your ledger, and the only stock that moves before it is stock you send to a customer on consignment — still yours, at their location. A quotation, a sales order, a goods delivery note, an outbound delivery order and a Sales GIN 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 wait for one of three documents to be finalised. Stock leaves on a Sales Invoice, a POS Cash Bill or a Sales GIN Stock Out. The third has no screen — it is created through the API, typically by an integration — and it takes stock out and posts like a sale by itself, so read its page before an invoice is raised for the same goods.

After the sale the numbers move again, on purpose: a sales return or refund note brings the stock back and reverses the sale, a credit note or debit note changes what the customer owes without touching stock, and the API-only Sales Invoice No Stock Out bills and posts with no stock movement at all. The exception before the sale is a Customer Consignment Transfer Out: it moves the units from your store to the customer’s consignment location and posts nothing, and when they sell you bill them on an ordinary sales invoice whose line carries that location. Trade-ins carry their own rules, stated on their applet page.

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. (There is a second pair — Purchase GRN Stock In / Purchase Invoice No Stock In — that books stock on receipt instead, and your company may be set up with that one. Whichever pair you have, you run 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 in the posting that runs after you finalise, not when you create the document and not as part of FINAL itself.

So a missing mapping never stops FINAL. The document goes FINAL and one of two things happens behind it. When the receivable or payable account is missing (or the company has no default GL codes at all), the posting fails with MISSING_DEFAULT_GL_CODE or COMPANY_DEFAULT_GL_CODE_NOT_EXIST, naming what it could not find, and the document sits FINAL with no journal — its Posting tab shows no journal status, and nobody is told. When a sales, purchase or tax account is missing, nothing fails at all: that line is left out and the customer’s or supplier’s line absorbs it, so the ledger is quietly short. The salesperson at 5pm on the last day of the month sees nothing; you find it at month-end.

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 invoices go FINAL for three weeks with no journal behind them, and the first anyone hears of it is a receivables ledger that does not agree with the ageing.

→ 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 first clears every blacklist flag in the tenant, then totals each customer’s outstanding documents in each company, compares that to their credit limit, and flags the ones over it as blacklisted. It has a second part meant to flag customers for lateness, but that part only finds credit terms set per company on the customer’s company tab. With none set there, it flags nobody for being late. 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.”

Four consequences follow, and all four 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.
• No screen shows the credit left while you key an order, and the only limit check is optional. With the credit check switched on in the Sales Order or Sales Invoice settings, FINAL is refused once the customer’s credit in that company is used up. With it off, nothing refuses a document for going over the limit.
• 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: decide, with whoever runs credit control, which of two practices you follow, because each costs something:

• Schedule the job. Customers over their limit are flagged automatically, as fresh as the schedule. The cost: every stop set by hand is wiped at each run. A credit limit of zero is the stop that comes back after a run, but only while the customer owes you something; a customer with nothing outstanding is left unflagged and can trade until the next run after they do.
• Leave it unscheduled (nothing in the product schedules it for you, and Stopping a customer assumes this). Hand-set stops stay put. The cost: nothing flags a customer for going over their limit, so the stop list is yours to keep, and anyone who runs the job by hand must tell you first so you can re-apply it.

Either way, know whether the job is scheduled. A clock you did not know about is how stops disappear.

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.

→ Document approvals

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:

1. 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.
2. 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.
3. 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

Related documentation