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. Not on the quotation, not on the order, not on the invoice, not on the cash bill. 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	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 permanently, set the customer record itself to INACTIVE.

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, and nowhere else. A customer with a limit sitting on the Credit Term and Limit tab but an empty Default picker 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. We checked all 90 production tenant databases on 2026-09-17 and not one had it scheduled, with no trace of it ever having been driven. A daily run is a sensible choice and makes the system behave roughly the way people expect; never running it means your credit limits do nothing at all, and today that is the normal case. 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, credit limit and — when the available-credit display is switched on — how much room is left, calculated as limit minus current receivables minus open documents.

Look at it, and know one thing about the third number: the available-credit calculation reads its limit from a different store on the customer record than the one the Credit Term and Limit tab writes to, and where nothing has been written there it treats the limit as zero. So available credit that shows as a large negative number the size of the customer’s balance is telling you that store is empty, not that the customer is catastrophically over their ceiling. The limit shown beside it is the real one.

That figure is the whole of BigLedger’s contribution to this decision. If it 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.

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. 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.