Count a customer's full credit exposure and know which available-credit figure to trust

Steps 2 and 3 of deciding on credit: a customer near their limit has sent another order, and you need the whole picture before you answer. You add what is ordered and what is promised to what the group is already owed, then work out which “available credit” figure you are looking at and whether it can stop anything. It follows Step 1, where you added up what the customer owes across the whole group. The three layers of exposure are explained on the front page, and the common mistakes for the whole decision are there too. The running example is an IT dealer in Penang with a RM 150,000 limit on Net 30 at GadgetSphere Distribution (GSD), who also buys on account from the retail company (GS) and has just ordered RM 44,520 of laptops; Meet GadgetSphere sets out what they owe.

1. Step 2: add what is ordered and what is promised.
2. Step 3: know which “available credit” you are looking at, and which to trust.

Step 2: Add what is ordered and what is promised

The outcome: the full exposure, all three layers.

Sales > Sales Order (Internal) > listing, filtered to the customer

Look for finalised orders that have not been fully invoiced. Partial Delivery Workflow explains how to read an order’s outstanding quantity. For the dealer, that is RM 21,600 at GSD.

Then ask the salesperson one question: what have you promised this customer that is not in the system yet? Nothing on any screen can answer this, because an accepted quotation or a verbal deal leaves no trace until somebody raises the order. For the dealer, it is the RM 60,000 quotation. Write the answer, with the date, in the Remarks of the order you are deciding on. You know layer 3 is complete when every quotation the salesperson marks as accepted is either in your figure or already a finalised order.

The dealer is already RM 15,500 over a RM 150,000 limit before today’s order. Counting the promised quotation, they are RM 120,020 over.

Step 3: Know which “available credit” you are looking at, and which to trust

The outcome: when somebody quotes you a customer’s available credit, you know which calculation produced it and whether it can stop anything.

BigLedger works out available credit in two different ways, and the two do not agree. Neither one appears while the order desk is keying an order. The Sales Order screen shows which credit limit the order carries, not how much of it is left.

The first calculation is the one that can refuse a document. It acts in three places:

• At FINAL on a sales order or sales invoice, with the optional credit check switched on. The check is a setting on each of those two screens; on the invoice screen it can also be switched on for individual users through a permission.
• The Outstanding Balance Alert banner on a new sales invoice, when the customer is already past their limit. The banner shows even when the check is off, and it warns without blocking anything.
• Your online store, for a customer who signs in and buys on account. The store shows this figure as Available Credit Limit: on the customer’s orders page, where the store is set up to show it, and uses it at checkout. More on this below.

It works like this:

the limit − what this customer owes this company − what is on this customer’s open delivery queue in this company

• The limit is the customer’s company-level limit for this company, if one exists. Otherwise it is the limit the document carries (the one picked on the order). The invoice banner runs before any limit is picked, so for a customer with no company-level limit and more than one active limit it measures against whichever of them comes back first. One active limit per customer avoids that (Credit Limits and Payment Terms).
• What they owe is the open balance of every finalised document for this customer in this company: invoices, less credit notes and receipts not yet applied. Every currency is added together as if it were the same money. A USD 10,000 invoice counts as 10,000.
• The open delivery queue is orders waiting for a delivery order, and delivery orders waiting for an invoice, at the value still to go. Orders you invoice straight from the order, with no delivery order, count for nothing.

The online store uses the first calculation, and it can refuse the customer. This applies to a store where staff have ticked Restrict View/Access by Entity in the back office’s website settings. That setting is for the whole store, not for one customer: visitors must sign in to a customer account, and an order with no online payment chosen is taken on account. The store asks the first calculation for the signed-in customer’s figure, using the company-level limit for the store’s company if there is one. Otherwise it uses the customer’s smallest active limit in the store’s currency. If the basket is bigger than that figure, what happens depends on how the store’s payment is set up. Either checkout stops with “Your Credit Limit has been exceeded.” and a Show Usage button, or the customer is sent to the payment gateway to pay for the order. A basket that fits is raised as a sales order with nothing paid. In a store without that setting, credit plays no part: every customer pays at checkout.

A credit customer with no active limit in the store’s currency gets no figure. The store counts that as zero, so none of their on-account orders gets through. That is the first thing to check when a trade customer says the store will not let them order.

The second calculation refuses nothing. It is the "… available out of …" credit bar that your staff see on a store account in the back office (the online-store admin’s Website > Account page), not the customer. An integration can also ask BigLedger’s API for it. It is built differently at every step:

They disagree whenever any row of that table matters, which for a group like GadgetSphere is almost always. GSD delivers some orders on a delivery order and invoices others straight from the order. It has a USD customer or two. Its customers’ limits were attached on the Credit Term and Limit tab.

Which to trust for a decision: neither, as the customer’s position. That is Steps 1 and 2. For the narrower question “will the next document be refused?”, trust the first calculation, because it is the only one that acts.

• A customer tells you their online account says they have RM 50,000 available. That is the first calculation. It is exactly what their next store checkout is measured against, so it is real, but it covers one company (the store’s) and one limit. They can have RM 50,000 of room at the store while owing your other companies more than you would ever allow.
• Somebody in your office reads a figure off the back-office store-account page, or an integration shows your sales team one. That may be the second calculation. It stops nothing and does not reflect the limit you set. Say so before anybody plans a delivery around it.

If your group runs a store where customers sign in and buy on account, do this once as the credit controller. Pick one credit customer and write down three numbers: the Available Credit Limit their store orders page shows (sign in as a test customer if you cannot see theirs), the bar on their account in the back office, and what Step 1 gives you for the store’s company. You know the sales team is covered when they have it from you in writing which of those the store checks, which one checks nothing, and that neither is the group decision.

For the dealer, the first calculation at GSD gives RM 150,000 − RM 112,400 − RM 0 = RM 37,600 available:

• It is one company. GS’s RM 31,500 is not in it.
• GSD’s RM 21,600 of open orders counts for nothing, because GSD invoices straight from the order.
• The RM 60,000 quotation does not exist as far as it knows.

On the Sales Order screen, today’s RM 44,520 is subtracted, the result is below zero, and FINAL is refused with a message naming the customer code and the available figure. The screen gets the answer right, but for the wrong reason, and only by RM 6,920. Had the order been RM 36,000, it would have gone through, with the dealer already RM 15,500 over on the full picture.

The invoice screen is different. It does not add the invoice you are finalising to the sum. It only refuses when the customer has no room left before this invoice. So the invoice that carries a customer over their limit goes through, and the next one is refused.

Read the invoice banner carefully. It says the customer “has an outstanding balance of” an amount. That amount is how far past the limit they are, not what they owe. For a customer RM 5,000 over a RM 150,000 limit it says RM 5,000. It is always shown in ringgit, whatever the customer’s currency.

The company-level limit, and who should use it

The customer record is shared across the group, and so is the limit you attach on its Credit Term and Limit tab. You can also give a customer a separate limit for one company: Customer Maintenance > (the customer) > Company Linking > (the company) > Credit Limits.

Two things read it: the first calculation above (the FINAL check, the invoice banner and the online store’s figure), and the blacklist sweep (Stopping Supply to a Customer). Both use it instead of the ordinary limit for that company. The second calculation, the debtor reports and the statement of account do not read it.

This is how you give the dealer RM 150,000 at GSD and RM 10,000 at GS, which is a different commercial decision from one RM 150,000 limit shared by both. If you use it, you (the credit controller) own it. Review it whenever the group limit changes, because nothing keeps the two in step. How you know it is working: the refusal message shows how much credit is left, not which limit was used, so you check it with arithmetic. Give the dealer a RM 10,000 company-level limit at GS. They owe GS RM 31,500 and have no open delivery-queue amounts there, so the room left is RM 10,000 − RM 31,500 = −RM 21,500. Raise a draft order for them at GS and press FINAL. The refusal names the customer’s code, then Available Credit Limit: and a figure, and that figure should be −21,500. If it is 118,500 (the group RM 150,000 − RM 31,500), or the order posts, the company-level limit is not being read. Check that it is ACTIVE and attached to the right company, then delete the draft.

What the check does not see, and who covers it. The cash bill, the delivery order and quotations are never checked. Neither is any document that arrives through an integration or the API rather than through those two screens. If a customer must get no more goods by any route, the check is the wrong tool. Put them on stop instead: the stop is enforced by the server at FINAL on the cash bill, the sales order, the sales invoice and the delivery order, whichever route the document comes from (Stopping Supply to a Customer). That is the credit controller’s decision, made the day the customer crosses the line you set. You know it held when a draft cash bill for that customer is refused at FINAL (delete the draft afterwards). For customers who are over their limit but not stopped, the daily review in If your last system stopped the invoice at save on the front page catches what came through the unchecked routes.

Next: Steps 4 and 5, decide and record it.

Related documentation

• Deciding on Credit: the whole decision, with its success check and the common mistakes.
• Credit Limits and Terms: setting the limits themselves.