Can I set a credit limit that actually stops an order? Credit limits and payment terms

“Can I set a credit limit that actually stops an order?” Only with a setting switched on: the optional check on the Sales Order and Sales Invoice screens refuses FINAL once the customer’s available credit in that company is used up, nothing on the server checks a limit at the moment of sale, and the blacklist sweep that stops a customer’s next order after they go over runs only if somebody schedules it or runs it by hand — What the numbers actually drive says which parts of BigLedger read the number you type.

You are the person who agrees payment terms — thirty days for this reseller, sixty for that one, cash up front for the rest — and somebody has asked you to get those agreements into BigLedger. By the end of this guide you will have built a small library of payment terms and credit limits, attached them to a customer so that invoices date themselves correctly, and you will know exactly which screens act on the numbers and which merely display them. Building the library takes about fifteen minutes. Reading What the numbers actually drive takes five, and it is the part that stops you relying on something that was never going to protect you.

Credit limits and payment terms, at a glance

1. Build your payment terms.
2. Build your credit limits.
3. Attach a term and a limit to a customer.
4. Set the defaults on the customer’s Main tab.
5. Do the same for suppliers, knowing it is a record and not a control.
6. Load them in bulk, if you have hundreds.

The setup runs across three pages: Steps 1 and 2 here, Steps 3 to 5 on Attach terms and limits, and Step 6 on Load them in bulk. What the numbers actually drive has a page of its own.

Meet GadgetSphere

GadgetSphere Sdn Bhd’s distribution arm, GadgetSphere Distribution Sdn Bhd (GSD), sells to about 180 corporate buyers on account: IT resellers, corporate IT departments, a handful of system integrators. Almost all of them are on thirty days. A dozen large ones negotiated sixty. Two are on end-of-month-plus-sixty because that is how their accounts payable runs work. Limits range from RM 20,000 for a new reseller to RM 500,000 for the two biggest accounts.

That is four payment terms and perhaps six credit limits — not 180 of each. This is the first thing to get right.

Two things, and they are not the same thing

A payment term is when the money is due. You define it once, name it something a human recognises (NET30), and attach it to every customer who is on those terms. BigLedger stores it as six numbers, which we will get to.

A credit limit is how much you are willing to be owed at once. Same idea: define LIMIT-150K once, attach it to everyone who has that ceiling.

Both live in the same two places:

The assignment is a copy, not a pointer. When the assignment is made, BigLedger copies the code, name, currency, amount and the six date numbers onto the customer’s own row. Changing a definition later does not update customers who were already assigned it. If you shorten NET30 to twenty-five days next year, existing customers keep thirty until you re-assign them.

Before you start

• You can open Customer Maintenance (and Supplier, if you are doing the purchase side too). Both applets hide the credit menus and the credit tab behind settings, so if Credit Term Listing is not in your left menu, your administrator has hidden it — see Customer Maintenance for the switch names.
• You know the terms you actually use. Write them on paper first. Four or five is normal; one per customer is a mistake you will spend a year undoing.
• You know your currencies. A credit limit carries a currency and there is no conversion — an RM 150,000 limit and a USD 150,000 limit are two different definitions.

Step 1: Build your payment terms

Master Data > Customer Maintenance > Credit Term Listing > + (add)

The outcome: four reusable terms that cover every customer you have.

The form is short: Credit Term Code, Credit Term Name, Status, and then six numbers in two groups — Set Year / Set Month / Set Day and Add Year / Add Month / Add Day. Code and name are both required; status fills itself in as ACTIVE.

Here is the arithmetic, which nothing on the screen explains:

1. BigLedger first tries to build a base date out of the three Set numbers, read literally as a year, a month and a day.
2. If that base date is not a real date, it falls back to the document’s transaction date.
3. It then adds the three Add numbers to whatever base it ended up with.

So for NET30 you leave all three Set boxes at zero and put 30 in Add Day. Zero-zero-zero is not a real date, the base falls back to the invoice date, and the due date lands thirty days later. That is exactly what you want, and it is why the Set boxes look pointless — for ordinary “net N days” terms, they are.

GadgetSphere’s four:

The commonest failure here is a duplicate code. The screen checks as you type and shows Code already exist under the Code box; the Save will not go through until you change it.

Step 2: Build your credit limits

Master Data > Customer Maintenance > Credit Limit Listing > + (add)

The outcome: a handful of named ceilings.

Five fields: Credit Limit Code, Credit Limit Name, Status, Currency and Credit Limit Amount. Code, name and currency are required.

Amount takes whole numbers only. The field is validated against digits and nothing else — no decimal point, no comma, no RM. Type 150,000.00 and the form simply refuses to become valid, with no message telling you why. Type 150000.

GadgetSphere’s set:

Name them for what they are. A limit called L3 tells the next person nothing, and this list is read far more often than it is edited.

LIMIT-STOP is the one limit here that is not a ceiling. Attached as a customer’s Default Credit Limit, it makes every run of the credit sweep re-flag them while their net balance is above zero, which is the stop that lasts until they pay (What the numbers actually drive). Never attach it by default to a new customer: they would be stopped at the first run after their first credit sale.

Next: Steps 3 to 5, attach a term and a limit to each customer and supplier.

Steps 3 to 6, in brief

Step 3: Attach a term and a limit to a customer

On the customer’s Credit Term and Limit tab, use + in Select Mode to attach one term and one limit you built in Steps 1 and 2, and keep any old assignment out of the way: when a customer has two active credit limits, different screens pick different ones (Step 3).

Step 4: Set the defaults on the customer’s Main tab

Set both pickers, Default Credit Limit and Default Credit Term: the credit sweep finds a customer’s limit through the Default Credit Limit pointer unless the customer has a company-level limit for that company. Leave both status dropdowns at OK (Step 4).

Step 5: Do the same for suppliers, knowing it is a record and not a control

The purchase side is a mirror image, but on the purchase side nothing acts on the credit limit at all (Step 5).

Step 6: Load them in bulk, if you have hundreds

Upload Credit Terms and Upload Credit Limits, on the customer and the supplier applets alike, attach definitions to customers or suppliers from one CSV file each. They do not build the definitions (Step 6).

What success looks like

Three checks, half a minute:

1. Open the customer’s Main tab. Default Credit Limit and Default Credit Term both show a value, and both status dropdowns read OK.
2. Open their Credit Term and Limit tab. Exactly one active term and one active limit. If there are two of either, deal with it now.
3. Start a sales invoice for that customer and pick the credit term. The Due Date field moves to the transaction date plus your Add Day count. If it does not move at all, the term’s numbers are all zeros; if it moves to somewhere unexpected, re-read Step 1’s warning about the Set boxes.

Common mistakes

The bulk-upload mistake (a formatted amount loading as zero) is with Step 6.

Filling in some of the Set boxes but not all three. The base date silently becomes invalid, BigLedger falls back to the transaction date, and your carefully configured end-of-month term behaves like a plain “net N days”. Always test a new term on a real document before it goes anywhere near a customer.

Typing a formatted amount into the credit limit. 150,000.00 is rejected by a pattern that allows digits and nothing else, and the screen does not tell you that is why Save is doing nothing. Whole numbers, no separators.

Leaving two credit limits on one customer. The reports read the most recent one, the sweep reads the one the Default picker names (or a company-level limit, where there is one), and the online store takes the smallest. They drift apart and the mismatch is invisible until somebody is blacklisted for a limit they did not think they had.

Editing a definition and expecting it to propagate. Assignments are copies taken at the moment of assignment. Changing NET30 changes it for customers assigned it afterwards. Everyone already on it keeps the old numbers until you re-assign them.

Setting a blacklist by hand and walking away. The next run of the sweep, which we recommend scheduling, clears it. For a customer who stays stopped until they pay, attach LIMIT-STOP instead; keep a stop list, re-apply any hand-set stop after each run and check it monthly. Do not reach for INACTIVE instead: nothing refuses a document for an inactive customer at FINAL, and an inactive customer cannot be picked on the receipt screen either, so the payment you are chasing becomes harder to record.

Treating a credit limit as a control. It is a number that a background job compares balances against each time somebody runs it. Nothing in the sale path asks the question, except an optional check on the order and invoice screens that is off unless somebody turned it on. Plan your credit control around the debtor report and a person, not around this field.

Related documentation

• Can This Customer Take More Goods? and Stopping Supply to a Customer — using these limits to decide, and to stop a customer
• Customer Maintenance — the full field and settings reference for the customer side
• Supplier — the same for the purchase side, including Credit Term Logic
• Credit Sales Workflow — selling on terms, chasing what is owed, and what the blacklist does at FINAL
• Debtor Report Applet and Statement of Account Applet — where the terms and limits are displayed back to you
• Sales Invoice (Internal) — the document that turns a payment term into a due date