What a credit limit actually drives in BigLedger
This page explains which parts of BigLedger act on the credit limit you attached in setting up credit limits and payment terms, and which merely display it. It is the part that stops you relying on something that was never going to protect you. Read it after Step 4, where you set the Default pointers it refers to.
What the numbers actually drive
This is the section to read twice. Five different parts of BigLedger answer the question “what is this customer’s credit limit?”, and they do not all read the same row. Deciding on Credit, Step 3, puts the two available-credit calculations side by side.
| Who is asking | Where it looks | Consequence |
|---|---|---|
| The credit sweep (Blacklist Overdue Customer) | A company-level limit for that company if there is one (Company Linking > the company > Credit Limits), otherwise the single row that Default Credit Limit points at | A customer with an empty Default picker and no company-level limit is skipped entirely — no limit, no flag, ever |
| The optional credit check at FINAL on the Sales Order and Sales Invoice screens, and the invoice’s Outstanding Balance Alert | The company-level limit if there is one, otherwise the limit row the document carries | Counts one company, and adds balances in different currencies together without converting them |
| The debtor and outstanding reports, and the Statement of Account | The most recently updated active credit-limit row for that customer, ignoring the Default pointer | With one assignment these agree. With two they can disagree |
| Your online store, for customers who sign in and buy on account (a store with Restrict View/Access by Entity ticked) | The company-level limit for the store’s company if there is one, otherwise the customer’s smallest active limit in the store’s currency. The figure is the FINAL check’s calculation | Shown to the customer in the store as Available Credit Limit, and a basket bigger than it is refused at checkout or sent to online payment. A customer with no active limit in the store’s currency counts as zero, so none of their on-account orders gets through |
| The “available out of” credit bar your staff see on a store account in the back office (the online-store admin’s Website > Account), and one of the API’s available-credit figures | An older credit-limit store on the customer record that the Credit Term and Limit tab does not write to | If nothing has been written there, the limit is zero and the page shows no credit bar. It refuses nothing, and no sales order or invoice screen shows it |
The Statement of Account also shows the term as a plain “N DAYS” string built from Add Day alone. A customer on a term expressed in months will see a misleading number there; a customer on a “net N days” term will see exactly what you set.
What the sweep does, precisely — and when
There is a background processor called Blacklist Overdue Customer (ENTITY_BLACKLIST_CUSTOMER_PROCESSOR). Somebody has to put it on the tenant’s job schedule or run it on demand; nothing runs it by default, and nothing in the product makes it nightly — “overnight” is a choice your administrator makes, not a fact about BigLedger.
And nothing puts it on that schedule for you. It is not one of the default clocks BigLedger inserts when a tenant is created, and nothing adds it afterwards — so unless somebody deliberately scheduled it, or runs Blacklist Overdue Customer by hand, the safe assumption is that the sweep has never run on your tenant: every credit limit you set below is a number on a screen and nothing more. You can check: the Scheduler applet lists your tenant’s clocks, and the sweep is scheduled only if there is an ACTIVE row whose Scheduler Code is ENTITY_BLACKLIST_CUSTOMER_PROCESSOR. Its Last Run Date proves only that the clock fired, not that the sweep worked — look for the effect: blacklist flags on customers who are over their limit. Plan for that, then ask your administrator to schedule it if you want the behaviour this section describes.
Each time it does run, it:
- Clears every existing blacklist flag in the tenant — both the credit-limit and the credit-term flag, on every customer. It blanks them rather than setting them back to
OK, so a customer the sweep has cleared shows an empty status dropdown; that is normal. - Adds up each customer’s outstanding balance, company by company, and compares it against that company’s company-level limit if the customer has one, otherwise against the limit their Default Credit Limit points at.
- Sets the credit-limit flag to
BLACKLISTEDon anyone over their limit.
A customer carrying that flag is then refused when somebody presses FINAL on a sales order, sales invoice, cash bill or outbound delivery order, with the message “Customer is blacklisted due to credit limit. Transactions are not allowed for this customer.” Nothing else is blocked — a quotation, a credit note or a receipt goes through as normal.
Two consequences you have to design around:
- A blacklist you set by hand does not survive. Step 4’s
BLACKLISTEDdropdown is real and it works, right up until the sweep next runs and clears it as part of step 1 above. Setting the customer record toINACTIVEis not a stronger stop: it hides the customer from the pickers on the sales and receipt screens, but FINAL does not check it, so a draft that already names them, or a document arriving from an integration, still goes through. The stop that FINAL enforces is the blacklist flag. Keep it on, keep your own list of every customer you stopped, and re-apply the list the same day if the sweep is ever run; Stopping Supply to a Customer Step 4 covers it. - The overdue half does not fire. The processor also intends to blacklist customers whose documents are aged past their agreed terms. In the shipped backend that branch 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 limit. Recorded as a product defect; until it is fixed, ageing is something you chase from the debtor report, not something the system stops.
And the headline, which the Credit Sales Workflow guide covers in full: nothing on the server checks a credit limit at the moment of sale. The only check is optional, in the Sales Order and Sales Invoice screens, and counts one company at a time; see Deciding on Credit. Without that check, the order that takes a customer over their ceiling always goes through. The block, if it comes at all, arrives on the next one, after the sweep has run.
Related documentation
- Credit Limits and Payment Terms: the setup, with its success check and the common mistakes.
- Can This Customer Take More Goods? and Stopping Supply to a Customer: using these limits to decide, and to stop a customer.
- Scheduler applet: where you check whether the sweep is scheduled.