Credit Limits and Payment Terms

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:

Layer	What it is	Where you edit it
The definition	The reusable master record — `NET30`, `LIMIT-150K`. One row, used by hundreds of customers	Credit Term Listing and Credit Limit Listing in the left menu
The assignment	A copy of that definition attached to one customer or one supplier	The Credit Term and Limit tab on the customer or supplier record

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.

Every BigLedger tenant ships with seven definitions already in the list — one credit limit called EMP_CREDIT_LIMITS and six credit terms called EMP_CREDIT_TERMS_0 through EMP_CREDIT_TERMS_5. They are platform seed rows for employee accounts, they are all zeros, and they are not examples to copy. Leave them alone and build your own.

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:

BigLedger first tries to build a base date out of the three Set numbers, read literally as a year, a month and a day.
If that base date is not a real date, it falls back to the document’s transaction date.
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:

Code	Name	Set Y / M / D	Add Y / M / D	Due date on a 15 March invoice
`NET30`	Net 30 days	0 / 0 / 0	0 / 0 / 30	14 April
`NET60`	Net 60 days	0 / 0 / 0	0 / 0 / 60	14 May
`NET14`	Net 14 days	0 / 0 / 0	0 / 0 / 14	29 March
`COD`	Cash on delivery	0 / 0 / 0	0 / 0 / 0	15 March

Do not fill in only some of the Set boxes. A term with Set Day = 1 and Set Month and Set Year left empty does not mean “the first of the invoice’s month”. It produces a base date that is not a real date, so BigLedger quietly falls back to the transaction date and adds your Add numbers to that instead. You get a due date, it looks plausible, and it is not the rule you thought you configured. If you need end-of-month terms, set the term up, raise one test invoice, and read the due date it produces before you attach it to anybody.

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:

Code	Name	Currency	Amount
`LIMIT-20K`	Limit RM 20,000 — new account	MYR	20000
`LIMIT-50K`	Limit RM 50,000	MYR	50000
`LIMIT-150K`	Limit RM 150,000	MYR	150000
`LIMIT-500K`	Limit RM 500,000 — key account	MYR	500000
`LIMIT-USD-50K`	Limit USD 50,000	USD	50000

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.

Attach exactly one of each, and keep the old ones out of the way. When a customer has two active credit limits, different screens pick different ones — the reports take whichever row was saved most recently, and the overnight credit sweep takes the one the Default Credit Limit picker points at (Step 4). They will disagree, silently, and the disagreement surfaces months later as “why is this customer blacklisted when the report says they are inside their limit”. If you are changing a customer’s limit, set the old assignment to INACTIVE or remove it rather than leaving both.

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 overnight credit check 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 nightly credit sweep described below finds a customer’s limit through the Default Credit Limit pointer and nowhere else. A customer with a limit on the Credit Term and Limit tab but an empty Default picker 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. Supplier terms are read the same way on a purchase invoice — pick the term, the due date fills in.

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 check the due date a real purchase invoice produces. The stored value itself is never read by the backend; it only drives that pre-fill.

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

Each screen takes a CSV, has a Sample Format download beside the file picker, and reports back per row.

There are two shapes of file and they are not interchangeable, despite sitting behind similar-looking menu entries:

What you are loading	Columns
Term definitions	`CREDIT_TERM_CODE, CREDIT_TERM_NAME, STATUS, YEAR_SETTING, MONTH_SETTING, DAY_SETTING, ADD_YEAR, ADD_MONTH, ADD_DAY`
Limit definitions	`CREDIT_LIMIT_CODE, CREDIT_LIMIT_NAME, STATUS, CURRENCY_CODE, CREDIT_LIMIT_AMOUNT`
Term assignments to customers	`customer_code, credit_term_code, credit_terms_set_year, credit_terms_set_month, credit_terms_set_day, credit_terms_add_year, credit_terms_add_month, credit_terms_add_day, status`
Limit assignments to customers	`customer_code, credit_limit_code, currency, amount, status`
Term assignments to suppliers	`supplier_code, credit_term_code, credit_terms_set_year, credit_terms_set_month, credit_terms_set_day, credit_terms_add_year, credit_terms_add_month, credit_terms_add_day, status`
Limit assignments to suppliers	`supplier_code, credit_limit_code, currency, amount, status`

Always download the sample from the screen you are about to upload into rather than reusing yesterday’s file — the definition templates use UPPERCASE_HEADINGS and the assignment templates use lowercase_column_names, and a file with the wrong headings fails the whole batch.

A bulk assignment load does not set the Default Credit Limit and Default Credit Term pointers from Step 4. After a big import, spot-check a few customers’ Main tabs.

What the numbers actually drive

This is the section to read twice. Three different parts of BigLedger answer the question “what is this customer’s credit limit?”, and they do not all read the same row.

Who is asking	Where it looks	Consequence
The nightly credit sweep (Blacklist Overdue Customer)	The single row that Default Credit Limit points at	A customer whose Default picker is empty is skipped entirely — no limit, no flag, ever
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
The available-credit display on the sales order and invoice header	A separate credit-limit store on the customer record, unrelated to either of the above	If nothing has been written there, it reads the limit as zero, so available credit shows as a negative number the size of the customer’s balance

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 nightly sweep does, precisely

There is a background processor called Blacklist Overdue Customer. Somebody has to schedule or run it; nothing runs it by default. Each time it runs, it:

Clears every existing blacklist flag in the tenant — both the credit-limit and the credit-term flag, on every customer.
Adds up each customer’s outstanding balance and compares it against the limit their Default Credit Limit points at.
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. If you want a customer stopped permanently, set their customer record to INACTIVE instead.
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 checks a credit limit at the moment of sale. 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:

Open the customer’s Main tab. Default Credit Limit and Default Credit Term both show a value, and both status dropdowns read OK.
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.
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. 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 sweep clears it. Use INACTIVE on the customer record if you want a customer stopped for good.

Treating a credit limit as a control. It is a number that a background job compares balances against once a night, if somebody runs it. Nothing in the sale path asks the question. Plan your credit control around the debtor report and a person, not around this field.