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 below 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 the last section, 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.

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.

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

Master Data > Customer Maintenance > Customer Listing > (the customer) > Credit Term and Limit

The outcome: this customer’s invoices date themselves, and the customer appears on the credit-control screens with a ceiling beside their name.

The tab shows the terms and limits already attached to this customer. The + button opens a picker with a Select Mode / Create Mode toggle:

• Select Mode — choose one of the definitions you built in Steps 1 and 2. This is what you want almost every time.
• Create Mode — define a brand-new term or limit inline, without leaving the customer. Convenient, and the reason tenants end up with 180 credit terms. Use it only when you genuinely have a one-off.

Attach one term and one limit. For our IT reseller: NET30 and LIMIT-150K.

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

Master Data > Customer Maintenance > Customer Listing > (the customer) > Main

The outcome: the pointers that the credit sweep actually reads.

Scroll the Main tab to the credit block. There are four controls:

• Default Credit Limit — a picker listing the limits attached to this customer.
• Default Credit Term — the same for terms.
• Credit Limit Status — two values, OK and BLACKLISTED.
• Credit Term Status — the same two values.

Set both pickers. This is the step people skip, because Step 3 already looks like it finished the job, and it is the step that matters most: the credit sweep described below finds a customer’s limit through the Default Credit Limit pointer, unless the customer has a company-level limit for that company (Company Linking > the company > Credit Limits). A customer with a limit on the Credit Term and Limit tab, an empty Default picker and no company-level limit is invisible to it.

A customer created through this applet can fill these in for you: if your administrator has set Settings > Default Selection > Default Credit Term and Default Credit Limit, a brand-new customer gets the assignment made and both pointers set automatically. That only happens while the record is still being created — it will never retro-fit a customer who already exists, and it does not happen at all to customers created in the Entity Maintenance applet or through the API.

Leave both status dropdowns at OK. New customers are created that way. What they are for is covered next.

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

Master Data > Supplier > Credit Term Listing / Credit Limit Listing, then the supplier’s Credit Term and Limit tab

The purchase side is a mirror image: the same two listings, the same assignment tab, the same six numbers. A purchase invoice offers the supplier’s terms to pick, but it keeps no due date: the purchase invoice applet works the date out and has nowhere to put it, so you age payables from the invoice date and the terms yourself.

The difference is that on the purchase side nothing acts on the credit limit at all. There is no sweep, no flag and no check. A supplier credit limit in BigLedger is a note to yourself about what the supplier agreed to give you. That is still worth recording — it is what your buyers look at — but do not build a process on the assumption that BigLedger will stop a purchase order.

The supplier form has one field the customer form does not: Credit Term Logic, offering None or End of Month. Choosing End of Month pre-fills Set Day 1, Add Month 2 and Add Day −1. Read the warning in Step 1 before relying on it, and work one example by hand, because no purchase invoice will show you the date it produces. The word you pick is copied onto the supplier’s assignment row when you assign the term, and is then carried for reference only — no due-date arithmetic anywhere reads it. What produces the date is the six numbers it pre-filled.

See Supplier for the full field reference.

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

Master Data > Customer Maintenance > Upload Credit Terms and Upload Credit Limits (the Supplier applet has the same two entries)

The outcome: every customer on your agreed-terms list carries the right term and the right limit, without anyone opening 180 records one by one.

These two screens attach definitions to customers. They do not build the definitions. Neither the customer nor the supplier applet has a screen that uploads the term list or the limit list itself, so Steps 1 and 2 stay a job done by hand. With four terms and six limits, that is the right size of job anyway.

Each screen takes one CSV file, has a Sample Format download beside the file picker, and processes the file in the background. The listing shows each file’s Process Status and Error Message. Open a file to see its rows: the reason a row failed is in the row’s Error Message column, and Short Error Message is often empty.

The term file carries, per row, the customer code, the term code, the three Set numbers, the three Add numbers and a status. The limit file carries the customer code, the limit code, a currency, an amount and a status. The supplier files are the same with the supplier code first. Build yours from the sample, in the sample’s column order, and read these before you upload:

• The numbers come from your file, not from the definition. On screen, attaching NET30 copies NET30’s numbers (Step 3). The upload uses the code only to look up the name. The six numbers, or the currency and amount, are whatever your row says. A row reading NET30 with an Add Day of 45 gives the customer a term called Net 30 days that dates their invoices 45 days out, and a row reading LIMIT-150K with an amount of 50000 gives them a limit of 50,000 with a 150K label. A code that is not in your list is not refused either: the customer gets an assignment carrying that code and a blank name. So copy the numbers into the file from the definitions you built in Steps 1 and 2, never from memory.
• Rows are matched on customer and code, so uploading again corrects rather than duplicates. If the customer already has an assignment with that code, the row overwrites its numbers (or its currency and amount) and its status. A row with a different code adds a second assignment beside the first, which is exactly the two-active-limits trap from Step 3. To move 40 resellers from LIMIT-50K to LIMIT-150K in one file, give each of them two rows: the old code with INACTIVE and the new code with ACTIVE.
• An amount that is not a plain number becomes zero, and the row still reports success. 150,000.00, RM150000 or an empty cell all load as a limit of zero. A day, month or year cell that is empty or not a whole number loads as 0 in the same way, so a blank Add Day turns a thirty-day term into “due on the invoice date”. A zero limit is a limit, not the absence of one: your online store, for example, takes the customer’s smallest active limit, so a zero there means nothing can be bought on account. Before saving from a spreadsheet, format the amount column as a plain number with no thousands separator.
• The term upload refuses an Add Day above 31, an Add Month above 12, and an Add Year that is not 0 or four digits. It checks the Add numbers as if they were a date. So NET60, written as Add Day 60, fails with Add Day Must Be One Or Two Digits And 31st Is Largest Date, 60 Is Not Valid. The screen in Steps 1 and 3 has no such limit. Add Month 2 is not a way round it, because two calendar months is not sixty days. Upload the thirty-day customers and attach the sixty-day ones on screen.
• Headings: capitals on the customer term upload, position on the other three. The customer Upload Credit Terms screen reads your heading row by name and fails the whole file with Wrong Columns or Mandatory Columns Missing if it does not recognise a heading. Its check expects the headings in capitals (CUSTOMER_CODE), and the sample downloads with lowercase headings. If a file built from that sample fails with Mandatory Columns Missing, retype the heading row in capitals and upload it again. The customer limit upload and both supplier uploads do not read the heading row at all. They take the columns by position, so a file with two columns swapped loads the wrong values into the wrong fields and says nothing.
• The status must be ACTIVE or INACTIVE, in capitals. Anything else, including active or an empty cell, stops the file at that row and marks it failed. Fix the row and upload the whole file again. Rows that did load are matched and overwritten, not doubled.
• The customer code must exist, or the row fails with Customer Code Does Not Exist (Supplier Code Does Not Exist on the supplier screens).

Most of this was read from the code and has not been tried on a live tenant: the zero amount, the Add Day ceiling, the capitals check on the heading row and the column-by-position reading. Test it before you rely on it. Upload a three-row file: one customer on NET30, one on NET60 and one limit with 150,000.00 typed in the amount. Then open those three customers’ Credit Term and Limit tab and read what landed.

A bulk load does not set the Default Credit Limit and Default Credit Term pointers from Step 4. Nothing sets them in bulk, and a customer whose pointer is empty is invisible to the credit sweep described below. So this checking stays with a person:

• Whoever prepares the file checks ten rows against the signed credit applications before it is uploaded.
• After the upload, somebody other than the preparer opens five customers from the file and compares their Credit Term and Limit tab and their Main tab pointers with the file.
• They also compare the file’s row count with the rows the upload listing shows as loaded.

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.

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:

1. 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.
2. 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.
3. Sets the credit-limit flag to BLACKLISTED on 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 BLACKLISTED dropdown 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 to INACTIVE is 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.

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

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.

Uploading limits straight from a formatted spreadsheet. An amount saved as 150,000.00 loads as a limit of zero, and the upload still reports the row as loaded. Save the amount column as plain digits, then open a few of the customers afterwards.

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 sweep, if anyone runs it, clears it. Keep a stop list 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