Customer Credit Limits: Should Your Order Portal Accept Another Sale on Account?

A customer may be within the payment deadline on every invoice and still have no room for another sale on account. Before commissioning a B2B order portal, decide which unpaid and committed amounts use the customer's approved credit limit and where the application must stop a new commitment. Payment terms answer when money is due; a credit limit answers how much exposure the business is prepared to accept.

This is a software-briefing guide, not advice on lending, creditworthiness or accounting. Finance must approve the policy and its calculation. The developer should make that decision visible and enforce the agreed control rather than interpreting a green customer badge as permission to sell without restriction.

Define the customer and company covered

A useful limit belongs to an identified trading relationship. If your business has several legal entities, specify which company is extending credit and which customer account uses it. A contact person, delivery address or group name should not accidentally combine unrelated balances.

The official ERPNext credit-limit guide documents company-specific customer limits, with customer-group and company fallbacks. Its current page explicitly says a group limit is a default evaluated for each customer, not a pool shared by the whole group. That is a product example, not a required structure for your business.

Ask for a plain explanation of the limit actually selected. If the customer's individual field is empty or zero, does your approved rule fall back to another policy, mean no credit is allowed, or require review? Do not let staff infer the answer. ERPNext documents that zero is not an effective limit at that level and the check continues to the next applicable level; other implementations need their own explicit rule.

Decide whether accepted orders use the facility

Imagine a hypothetical customer with several accepted orders that have not been invoiced. A portal looking only at unpaid invoices may accept another order even though finance intended those existing commitments to use the available facility.

ERPNext documents that open order value can use available credit by default. It also has a customer setting to bypass the sales-order check, leaving later invoice control in place. The same source warns that an accepted order can therefore still encounter a blocked invoice. Your policy must choose which promise the order portal makes.

For a custom implementation, identify the exact point at which an order becomes a credit commitment. A saved basket is not necessarily an accepted order. Show how a partially invoiced order moves between contributing amounts without counting the same exposure twice. Have finance approve the calculation and the developer demonstrate it; the documentation does not certify your implementation's total.

Do not restore room from a payment promise

A customer's message saying “we have paid” is useful information, but it is not automatically an updated ledger balance. ERPNext describes submitted payments or sales returns reducing outstanding amounts after ledgers update, and advises checking posting, allocation and the resulting balance when credit has not been restored.

Agree which authoritative records feed your own check and how staff see their freshness. An unallocated transfer, disputed amount or pending adjustment needs a defined review route. Do not invent an accounting correction simply to release an urgent order.

Likewise, make clear that an overdue-payment follow-up and a credit hold are different controls. A polite reminder does not authorise more exposure. An account with nothing overdue may still reach its approved maximum. Let finance decide whether overdue status introduces an additional restriction.

Separate an exception from a permanent increase

The source documents an authorised role for approving an exception after validation triggers. Its current field is called Credit Manager, while older documentation used Credit Controller. Verify the installed product and permissions instead of relying on an old screenshot or a search snippet.

In your brief, distinguish approval of this transaction from a lasting change to the account's limit. Record the decision maker, reason and transaction covered. Giving every salesperson an override role would undermine a hard control. A customer-facing refusal should offer an appropriate next step without exposing internal risk notes.

If a check cannot obtain the required current balance, choose an explicit pending or manual-review outcome. A timeout should not quietly become unrestricted credit. Also demonstrate two orders arriving close together so both cannot rely on the same stale headroom when a hard shared limit has been commissioned.

Accept a complete credit decision

Use synthetic accounts in your acceptance criteria. Include an individual limit, a fallback, zero, an uninvoiced order, a partial invoice, a posted payment and a one-transaction exception. Inspect the contributing records and authorised next action, not only the remaining-credit number.

Bring the approved credit policy to an ordering-app discussion. The useful deliverable explains why this order may proceed, must wait or needs a named exception. It does not promise that software predicts whether a customer will pay or that configuring a limit guarantees collection.