Can This Customer Take More Goods? Deciding on Credit

A good customer who is already near their limit has just sent another order, and somebody on the order desk has asked you, can we ship this? By the end of this guide you will be able to work out what that customer really owes the group, say why the available-credit figure the credit check uses is usually smaller than the truth, and make the call — release, hold, part-ship or refuse — in a way the order desk can act on and your finance manager can check later. The first time takes about twenty minutes. After that, about five.

This page is for the person who says no. It covers the judgement that stays yours with or without BigLedger. For the setup underneath (building terms and limits and attaching them to customers), see Credit Limits and Payment Terms.

Meet GadgetSphere

GadgetSphere is a group of three companies: the retail company (GS), the online store (GSO) and the distribution arm (GSD). One of GadgetSphere Distribution’s resellers, an IT dealer in Penang, has a RM 150,000 limit on Net 30 terms. The same dealer also buys accessories on account from the retail company for walk-in top-ups.

Today the dealer’s buyer sends an order to GSD for ten ultraportable laptops at RM 4,200: RM 42,000 plus RM 2,520 SST, RM 44,520.

Here is what the dealer owes this morning, which nobody has added up yet:

What	Company	Amount
Invoices finalised, not yet paid	GSD	RM 112,400 (RM 38,000 of it is 45 days old)
Orders finalised, not yet invoiced	GSD	RM 21,600
Invoices finalised, not yet paid	GS	RM 31,500
A quotation they have accepted by e-mail, not yet raised as an order	GSD	RM 60,000

The idea that makes this page make sense: exposure has three layers

Your exposure to a customer is everything that can turn into money they owe you. It has three layers, and BigLedger can see them to different degrees:

Invoiced and unpaid. A finalised invoice has an open balance, and the balance goes down as receipts, credit notes and contras are applied to it. BigLedger knows this exactly. It is what the ageing reports show.
Ordered and not yet invoiced. A finalised sales order is a promise to deliver. BigLedger knows it exists, but as you will see below, the credit check at FINAL counts it only in some workflows.
Promised and not yet ordered. A quotation the customer has accepted, a deal agreed on the phone, a framework contract. A quotation posts nothing and reserves nothing, so BigLedger has no idea this layer exists.

The credit decision is about all three. The screen shows you part of the first two.

If your last system stopped the invoice at save

Many accounting systems check the limit the moment you save an order or invoice. If the customer is over, the document is blocked, the overdue invoices are listed on the screen, and a supervisor types a password to let it through. If that is what you are used to, BigLedger will surprise you. It does not work that way, and nothing you switch on will make it work that way.

What BigLedger does instead:

Nothing at save. A draft saves whatever the customer owes.
An optional check at FINAL, on two back-office screens only, the Sales Order and the Sales Invoice. It is off until somebody switches it on (Step 3). If you run an online store where customers sign in to buy on account, the store makes the same check at checkout (Step 3).
One company at a time. What the customer owes your other companies is not counted.
The invoice that crosses the limit goes through. The invoice screen refuses only a customer who had no room left before this invoice, so the invoice that takes them over posts. The next one is refused.
No list of overdue invoices at the limit. The invoice screen lists a customer’s overdue invoices only after you have put them on stop for late payment (Stopping Supply to a Customer, Step 1). A new invoice for a customer already past their limit shows a warning banner, and the banner blocks nothing.
No override password. To let an order through, somebody who can edit the customer raises the limit. Step 5 explains how to make sure it comes back down.

So the parts of credit control your old system did at save are now people’s jobs:

The job your old system did	Who does it now	When	How they know it is done
Refusing the order that goes over	The credit controller decides (Step 4). The check on the Sales Order screen refuses some of these for you, one company at a time	Before the order is finalised, whenever the order desk asks. Anything over an amount you agree goes to you first	Every order over the limit that was finalised has a decision recorded in the customer’s Alert Message (Step 5)
Catching the invoice that crossed the limit	The credit controller	Every morning, before the day’s deliveries leave: run the Aging Report for all companies for each customer’s total, and compare it with the Credit Limit the Outstanding Document Report shows beside that customer’s documents	Every customer over their limit on that report has either an Alert Message with today’s decision or a stop
Showing the overdue invoices to whoever is selling	The order desk, from the Outstanding Document Report (overdue rows are shown in red). For a customer who must be stopped for lateness, the credit controller sets the stop, and then the invoice screen shows the list	Before releasing any order for a customer on your watch list	The desk can name the oldest overdue invoice when you ask
The supervisor’s password	The credit controller raises the limit. The finance manager approves anything above the amount you agreed (see Who does what)	Only after the decision in Step 4	Every raised limit has a reset date on the customer and in your calendar
Counting the whole group	The credit controller, by hand (Steps 1 and 2)	For every decision on a customer who buys from more than one company	You can say one group figure for the customer
Making sure the check is really on	Your administrator, with you	Once, and again after anyone changes the Sales Order or Sales Invoice settings	A draft order for a test customer with a RM 1 limit is refused at FINAL

Before you start

You can open the Debtor Report and run its reports for every company in the group, not just the one you work in. If your permissions only cover one company, ask for read access to the others. You cannot judge group exposure from inside one company.
You can see the customer’s record in Customer Maintenance, including the credit limit and the two status dropdowns.
You know whether the credit check on the order and invoice screens is switched on in your tenant (Step 3 explains it). If you do not know, ask your administrator, or test it: raise a draft order for a test customer with a RM 1 limit and press FINAL.

Step 1: Add up what the customer owes across the whole group

The outcome: one number for layer 1, covering every company.

Finance > Debtor Report > Outstanding Document Report

Leave the Company filter empty (or select all your companies), search for the customer, and read the ARAP Balance column for each row. Each company’s documents are listed separately, with the company on every row. Add them up.

For the dealer: RM 112,400 at GSD + RM 31,500 at GS = RM 143,900 invoiced and unpaid.

Then open the Aging Report for the same customer and read how old that money is. RM 143,900 that is all under thirty days old is a customer who is buying a lot. RM 143,900 with RM 38,000 at 45 days is a customer who is buying a lot and paying late, which is a different conversation.

Why you have to do this by hand. Every figure BigLedger computes for credit is computed one company at a time. The customer record is shared across the group, and so is the limit on it, but no screen adds up what the customer owes the group as a whole. Adding the companies together is your job, and this report is where you do it.

If the customer is billed in two currencies, convert it yourself. A credit limit carries one currency, and nothing converts. If the dealer also has USD invoices with GSD, turn them into ringgit at today’s rate on paper before you add them in. Do not trust any single figure on screen to have done it for you. The FINAL check in Step 3 adds the currencies together without converting them. You know you have it right when your working has one line per currency, each converted at a rate you wrote down, before any total.

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.

Layer	Dealer	Running total
Invoiced and unpaid, all companies	RM 143,900	RM 143,900
Ordered, not invoiced	RM 21,600	RM 165,500
Promised, not ordered	RM 60,000	RM 225,500
Today’s order	RM 44,520	RM 270,020

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:

	The FINAL check, the invoice banner and the online store	The back-office store-account bar
Can it stop a document?	Yes: at FINAL on the Sales Order and Sales Invoice screens when the check is on, and at checkout in a store restricted to customer accounts	No. Nothing reads it before posting
Which limit	The company-level limit, else the limit on the document. The store uses the customer’s smallest active limit in the store’s currency	An older limit store on the customer record, the smallest amount in it. The limits you attach on the Credit Term and Limit tab are not written there. If it is empty, the limit is zero and the back-office page shows no credit bar at all
What is owed	This company, all currencies added together	This company, one currency only. Balances in other currencies are left out
Open orders	Order → delivery order, and delivery order → invoice	Order → invoice only, at the line price. Orders going through a delivery order are left out
Company-level limit	Used when it exists	Ignored

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 above catches what came through the unchecked routes.

If FINAL does nothing at all. From inside an order, with the check switched on, an order for a customer who has no credit limit attached can neither post nor show a message. Nothing happens. This is a known product defect. Attach a limit to the customer, or finalise the order from the listing, where a customer without a limit is not checked. You know it worked when the order shows as FINAL in the listing.

Step 4: Decide, and name what each choice costs

The outcome: a decision you can defend, with its consequence stated.

This is the job, and it is the same job it was before any software. There are four answers:

Decision	What happens commercially	How you make it happen in BigLedger
Release	You take on the extra risk to keep the customer and the sale. Right when the customer pays reliably and late money is a timing issue, not a solvency one	The order is finalised. If the credit check refuses it, somebody who can change the customer’s credit limit raises it, and a date is written down for putting it back (Step 5)
Hold	The goods wait until money arrives. The customer is told why, and when it will ship. You risk losing the order to a competitor	Leave the order in draft. A draft order posts nothing and is not a promise. Whoever holds the FINAL permission on sales orders is the person who releases it, so make sure that is not the salesperson who wants it shipped
Part-ship	You ship what the current headroom covers, and the rest waits for a payment. Often the best answer for a good customer who is temporarily stretched	Finalise the order, then invoice only part of it, as in Partial Delivery Workflow. The rest stays open on the order
Refuse	You protect the receivable and may lose the customer. Right when the money you already have at risk is doubtful	Do not raise the order. If the refusal must also stop the rest of the business selling to them, that is the blacklist (Stopping Supply to a Customer)

For the dealer, a sensible call is hold, with an offer to part-ship. They are over on invoiced-plus-ordered alone, and RM 38,000 of the invoiced money is fifteen days late. Tell them that five laptops (RM 22,260) ship the day the RM 38,000 arrives, and the other five ship when the next invoice is paid.

Two questions to ask before any release:

Is the late money disputed, or just late? A disputed invoice is a customer who does not think they owe it. Releasing more stock does not help you collect it. See Chasing Overdue Accounts.
Who else in the group is selling to them this week? Your decision at GSD does nothing to stop GS’s counter selling to the same customer. If the risk is group-wide, so is the conversation.

Step 5: Record the decision where the next person will see it

The outcome: the order desk, the counter and your successor all know what was decided without asking you.

Master Data > Customer Maintenance > (the customer) > Main > Alert Message

The customer record has an Alert Message of up to 255 characters. It appears in a banner at the top of the account panel whenever somebody picks this customer on a new sales order or sales invoice. Use it for exactly this:

Credit hold 24 Sep: RM 38,000 overdue. Part-ship only after payment. Refer to credit control.

Then write the same reason in the Remarks on the held order, so that the order carries the reason.

If you released an order by raising the limit, write the date you will put it back in the alert message too. Nothing in BigLedger will remind you. A temporary limit that nobody lowers becomes the new limit. Put the reminder in your own calendar for the day after the invoice is due.

Who does what

Credit control works when the person who wants the sale is not the person who approves the risk. BigLedger has no approval step on any sales document, so this separation comes from who holds which permission:

The salesperson raises the order and knows about the promises (layer 3). They should not hold FINAL on sales orders for credit customers, or the right to edit a customer’s credit limit.
The credit controller (you) works out the exposure, makes the decision, holds the right to change credit limits and the two status dropdowns in Customer Maintenance, and writes the alert message.
The finance manager approves any release above an amount you agree in advance (for GadgetSphere, anything that takes a customer more than 20% over), and reviews the list of temporary limit increases once a month.

Anyone who can edit a customer in Customer Maintenance can change its limit and its status. There is no separate permission for the credit fields. If you want those fields to be credit control’s alone, limit who can edit customers. Your administrator does it once, and you check it every quarter: you know it holds when the list of users who can edit customers in Customer Maintenance’s permission screens names only credit control and the people who set customers up.

What success looks like

Run this for any customer, in under a minute:

You can say one number for their exposure across the group (invoiced plus ordered plus promised), and name which of the three layers the credit check would have missed.
Pick the customer on a new sales invoice. If you placed them on hold, the alert message is in the banner at the top.
Every limit you raised this month has a date to reset it, written on the customer and in your calendar.
Somebody quotes you an available-credit figure. You can say which of the two calculations in Step 3 it came from, and whether it can refuse anything. A figure from the customer’s store account can refuse their next checkout.

Common mistakes

Trusting either available-credit figure as the customer’s position. The FINAL check’s figure is one company’s receivable, minus open delivery-queue amounts that exist only in some workflows. The online store shows the FINAL check’s figure for the store’s company only. The back-office store-account bar is one currency and an older limit. Each is a floor, not the answer. Always add the other companies.

Assuming the check is on. It is a setting. Many businesses have never turned it on, and then FINAL checks nothing but the blacklist. Test it with a test customer before you tell the sales team “the system will stop it”.

Expecting the system to stop the invoice that goes over. The invoice screen refuses only when there is no room before the invoice. The order screen is the one that counts the new document.

Expecting a salesperson’s own credit limit to be checked. Some systems let you give each salesperson a ceiling of their own. BigLedger checks only the customer. If a salesperson’s authority to extend credit stops at an amount, that is a rule you enforce through who can finalise, not something the software will test. You know it holds when no salesperson appears among the users who can press FINAL on sales orders, which you check in the Sales Order screen’s permission settings each quarter.

Raising a limit to release one order and never lowering it. Every temporary limit needs a reset date, written on the customer. Without one, a RM 20,000 exception becomes the new normal.

Confusing an invoice that cannot be edited with a credit block. A finalised invoice cannot be edited because it is FINAL, not because of the customer’s credit. BigLedger has no credit lock on drafts. If a draft will not finalise, read the message: “Customer is blacklisted…” is the blacklist, a toast naming an available credit limit is the optional check, and anything else is not credit.