Credit Sales Workflow

A corporate customer wants to buy on account: goods now, payment in thirty days. By the end of this guide you will have set that customer up, invoiced them, and put yourself in a position to know — on any given morning — exactly who owes you what and for how long. Setting up a customer takes five minutes. Knowing what BigLedger will and will not do to protect you takes the ten minutes it takes to read this page, and it is the more valuable half.

Meet GadgetSphere

GadgetSphere Sdn Bhd’s distribution arm sells to corporate buyers on account. Today’s customer is an IT reseller who orders in batches of twenty to forty units, several times a month. Their terms are Net 30 and their credit limit is RM 150,000. This month’s order is 24 flagship smartphones at RM 3,800: RM 91,200 net, RM 5,472 SST at 6%, RM 96,672.

Read this first: what credit control in BigLedger actually is

This is the part every previous version of this page got wrong, and getting it wrong is expensive.

BigLedger does not check a credit limit when you save or finalise a sale, unless you have switched on the one optional check. Not on the quotation, not on the cash bill, not on the delivery order, and not on the order or the invoice with that check off (it is off unless somebody turned it on). With it on, the Sales Order and Sales Invoice screens refuse FINAL when the customer has no credit left in that company. Deciding on Credit explains what that check counts, and the group exposure it misses. If this customer already owes you RM 140,000 against a RM 150,000 limit, the RM 96,672 order above will save, finalise, post and ship without a single warning.

What exists instead is a blacklist flag on the customer record — two of them, in fact: one for credit limit and one for credit terms. When either is set to blacklisted, the customer is refused at FINAL on sales orders, sales invoices, cash bills and outbound delivery orders, with the message “Customer is blacklisted due to credit limit. Transactions are not allowed for this customer.”

And that flag is set by a job that has to be run. The Blacklist Overdue Customer processor sweeps every customer: it clears every existing blacklist flag in the tenant, then re-applies it to anyone whose total outstanding exceeds their limit.

So credit control here has four properties you have to design around:

Property	What it means for you
It is retrospective, not preventive	Unless the optional screen check is on, the order that takes a customer over their limit always goes through. The block arrives on the next one, after the job has run
It is all-or-nothing	A blacklisted customer cannot transact at all — not for RM 96,672, not for a RM 39 cable. There is no “approve this one” override short of clearing the flag
It only exists if the job runs	If nobody schedules or runs the sweep, no customer is ever blacklisted and the limit field is decoration
It only ever fires on the limit, never on lateness	The processor is meant to blacklist customers whose documents are aged past their agreed terms as well. In the shipped backend that half resolves the customer’s terms through the wrong pointer and finds nothing, so no customer is ever blacklisted for being late — only for being over their ceiling

A blacklist you set by hand does not survive the sweep. The Credit Limit Status and Credit Term Status dropdowns on the customer record really do stop that customer at FINAL — until the next run of the processor, whose first act is to clear every blacklist flag in the tenant before recalculating. If you need a customer stopped for good, setting the customer record to INACTIVE does not do it: it takes the customer out of the customer lists on the order, invoice, delivery order, till and receipt screens, but nothing refuses a document for an inactive customer at FINAL, so a draft that already names them, or an order arriving from an integration, still goes through. Keep the blacklist flag on, keep your own stop list, and re-apply every stop the same day if the sweep is ever run. Stopping Supply to a Customer walks through it.

And one more thing that decides whether any of this touches a given customer at all: the sweep finds a customer’s limit through the Default Credit Limit picker on the customer’s Main tab, unless the customer has a company-level limit for that company (Customer Maintenance > the customer > Company Linking > the company > Credit Limits), which it uses instead. A customer with a limit sitting on the Credit Term and Limit tab, an empty Default picker and no company-level limit is invisible to it. Credit Limits and Payment Terms walks through setting both.

Find out, before you rely on any of this, when that sweep runs — and start from the assumption that it does not. Nothing in the product schedules it: it runs as the ENTITY_BLACKLIST_CUSTOMER_PROCESSOR job when your tenant’s job schedule includes it, or when an administrator runs Blacklist Overdue Customer on demand. Nothing in the product puts that schedule there, so treat it as absent until you have seen the crontab row with your own eyes. A daily run is a sensible choice and makes the system behave roughly the way people expect; if it never runs, your credit limits do nothing at all. Ask whoever administers your tenant to add the clock, or to tell you who runs it by hand — until then, every check in this section is your sales team’s job, not BigLedger’s.

There is also no document approval workflow for sales documents. BigLedger’s approval engine covers Purchase Orders, Purchase Requisitions and Stock Requisitions only (the sales order applet’s Approval menu is for sell-below-minimum-price line approvals and does not gate FINAL). If your business wants a large credit sale signed off before it ships, that control lives in who holds the FINAL permission on the invoice — not in a routing rule you can configure.

Step 1: Set the customer up for credit

Master Data > Customer Maintenance > (the customer) > credit fields

The outcome: a customer record that tells everyone what the agreed deal is.

Three things to set:

Credit terms — Net 30 here. This is what the invoice uses to work out the due date. Attach the term on the Credit Term and Limit tab, then point Default Credit Term at it on the Main tab.
Credit limit — RM 150,000. Same two steps: attach it, then set Default Credit Limit. Remember what this does: it feeds the sweep, and it does not block anything by itself. Setting up terms and limits properly, once, for every customer is its own job — see Credit Limits and Payment Terms.
AR type — trade or non-trade. This decides which receivable account the invoice posts to: DEBTOR-TRADE-RETAIL for an ordinary customer, a non-trade account for staff advances, intercompany balances and the like. Get it wrong and the balance lands in the wrong place on the balance sheet.

While you are here, set the billing and delivery addresses properly. The invoice copies them, and on an e-Invoice the buyer details have to be right before submission.

Step 2: Check the exposure yourself, before you commit

Sales > Sales Order (Internal) > Create > Main Details

The outcome: a decision made by a person, because the system is not going to make it for you.

When you create the order, the header shows the customer’s credit terms and which credit limit the order carries. It does not show how much of that limit is left. No sales order or sales invoice screen shows an available-credit figure while you key the document. The invoice screen shows an Outstanding Balance Alert banner once a customer is already past their limit. If customers sign in to your online store and buy on account, the Available Credit Limit their store shows is the same figure the FINAL check uses, for the store’s company, and the store will not take an order bigger than it on account. The “… available out of …” bar your staff see on a store account in the back office, and what an integration may be given, are calculated a different way and cannot stop anything. Deciding on Credit, Step 3, sets the two calculations side by side and says which to trust.

So the decision is yours, made from the Debtor Report before the order is finalised. You know it was made when the order’s Remarks say who checked the customer’s position, and on what date. If the customer’s room is thin, this is the moment to ask for a deposit, shorten the terms, or split the order. Once you press FINAL nothing else is going to ask the question.

For a broader view before a big order, open the Debtor Report Applet and look at the customer’s ageing — RM 140,000 spread across thirty days is a different conversation from RM 140,000 that is ninety days old.

Step 3: Raise the order

Sales > Sales Order (Internal) > Sales Order > Create

Standard order entry — the same as the Standard Sales Workflow. The two things that matter for a credit sale:

Credit terms and due date on Main Details. These carry to the invoice. Check them rather than assuming; a customer whose terms changed last quarter will still show the old ones if nobody updated the record.
The customer’s purchase order number in Reference. On a credit sale this is not optional housekeeping. It is what their accounts payable department will match against, and a missing reference is the commonest reason an invoice sits unpaid for an extra month.

SAVE, then FINAL. No deposit is collected — that is the point of a credit sale.

Step 4: Invoice

Finance > Sales Invoice (Internal) > Sales Invoice > Create > KO For > Sales Order

The outcome: the receivable exists and the clock starts.

Knock off the sales order, check the date and the branch, check the E-Invoice tab if you are registered with LHDN, and press FINAL.

Dr  Debtor — trade retail                RM 96,672.00
    Cr  Sales — smartphones                       RM 91,200.00
    Cr  SST output tax                            RM  5,472.00

Twenty-four handsets leave the location at their moving-average cost, and the customer now owes RM 96,672, due in thirty days. No cost-of-sales line posts with the invoice — that is a month-end journal from the Financial Report applet, as the Standard Sales Workflow explains.

If FINAL is refused with “Customer is blacklisted…”, either the sweep has flagged them or somebody set the flag by hand. In practice the sweep only ever flags for being over the limit, so that is where to look first, and the right next step is a conversation with the customer, not with the system. Once the debt is settled, clear the flag on the customer record (or run the sweep again, which will clear it automatically if the arrears are gone).

Step 5: Know what you are owed

Finance > Debtor Report Applet, and Finance > Statement of Account Applet

The outcome: a list you can act on, every Monday morning.

Debtor Report Applet — the ageing. Who owes what, in which bucket. This is the working list for collections.
Statement of Account Applet — one customer’s full history: every invoice, credit note, receipt and contra. This is what you send a customer who disputes the balance.

Chase from the ageing, not from memory. A customer whose invoice is eight days past terms is a phone call; the same customer at sixty days is a different conversation and possibly a stop on further sales.

Step 6: Take the payment and apply it

Finance > Receipt Voucher (Internal) > Internal RCT Voucher > Create

The outcome: the invoice cleared, not just the money banked.

Create the voucher, pick the customer, add a Settlement line for the amount and the method, then — and this is the step people skip — open the Contra tab and tick the invoices this payment settles.

A receipt with no contra is an unapplied credit. The cash is in the bank and the invoice is still sitting on the ageing report as overdue. Press FINAL and check the invoice’s open amount has gone to zero.

Which invoices the payment settles is your choice. BigLedger does not decide it. For a receipt keyed on this screen, nothing matches it to invoices by itself, not at FINAL and not afterwards. (A receipt created by a file import or an integration carries whatever matching that route supplies.) The Contra tab lists this customer’s open documents in this company, oldest transaction date first. When you tick one, BigLedger proposes the smaller of its balance and what is left of the receipt. You can change the amount before you add it.

If your administrator has switched on AUTO_SETTLE_CONTRA (the screen shows that name) in the receipt applet’s Application Settings, the list also has a Total Amount box and an AUTO SETTLE button. Type the amount received and it fills the list from the top down: oldest transaction date first, until the money runs out. Three things it does not do:

It does not read the customer’s remittance advice. If the customer says “this RM 38,000 is for invoices 1041 and 1052”, auto-settle may put it against 1017 instead. On the ageing, 1041 and 1052 still look unpaid, and the customer says they paid them. Match by hand whenever the customer names the invoices.
It goes by invoice date, not due date. For a customer on mixed terms, the oldest invoice is not always the most overdue.
It only looks at this company. A payment meant to cover a customer’s invoices at two companies is two receipts, one at each company.

The job belongs to whoever keys receipts. They do it on the day the money is keyed, with the remittance advice in front of them, and send a payment with no remittance to the credit controller rather than guessing. They know they got it right when the receipt’s own open amount is zero and every invoice the customer named shows a zero open amount. Once a week, before the Monday collections list, the credit controller runs the Outstanding Document Report for every company. A receipt that was never fully applied appears there as its own row with a negative balance. Each one is either money waiting to be matched or a customer’s credit to be agreed. Nothing on that report should be a receipt older than a week.

Part payments work the same way: contra the amount received against the invoice, and the remainder stays open with the original due date.

Bank charges taken out of the transfer go on the Expenses tab of the voucher, so that the amount you contra matches the invoice and the shortfall is booked as a cost rather than leaving a stubborn RM 15 balance on the customer’s account forever.

Step 7: When the amount owed needs to change

Two situations, two different documents, and picking the wrong one is how stock records drift.

Situation	Document	What it does
You overbilled, agreed a retrospective discount, or need to write a balance off — nothing comes back	Sales Credit Note (Internal)	Reduces the receivable. Quantity signum 0 — it never touches stock
The customer is sending goods back	Sales Return (Internal)	Reduces the receivable and brings the stock back in

A credit note sits on the customer’s account until you either contra it against an open invoice or pay it out. Contra is the usual answer for a credit customer: it lands on the latest of the two document dates, and the ageing report reflects it immediately.

For a full walk-through of both, see Returns and Exchanges.

What success looks like

Open the invoice’s ARAP tab. Doc Open Amount is zero once the receipt is contra’d, and the settlement and contra columns add up to the invoice total.
Run the Debtor Report for this customer. The invoice has left the ageing.
Open the customer’s Statement of Account. Invoice, receipt and any credit note are all there, in order, and the closing balance is what you believe it to be.
Ask one question out loud: when did the blacklist sweep last run? If nobody knows, that is your real credit-control gap, and it is a five-minute conversation to close.

Common mistakes

Believing the credit limit stops anything. It does not, at the moment of sale, unless the optional check on the order and invoice screens is on, and even then it counts one company only. The number of businesses that have discovered this the month after a customer went under is the reason this guide leads with it.

Treating a blacklist as a system error. It is the system doing the one thing it does. Clear the arrears, then clear the flag — do not sell to the customer under a second entity record.

Raising a credit note for returned goods. The money comes off and the stock never comes back. Weeks later the physical count is short and nobody can explain it. Goods coming back always means a Sales Return.

Finalising receipts without contra. Money banked, invoice still overdue, customer chased anyway. Check the open amount every time.

Leaving the AR type wrong. A staff advance posted to trade debtors inflates your receivables and distorts the ageing. Set it on the customer record once, properly.

Waiting for an approval that is never coming. There is no sales approval engine. If a large credit sale needs a second pair of eyes, build that into who can press FINAL, and into a habit of checking the ageing first — not into a configuration screen that does not exist for this document type.