A customer places another order. Sales wants to confirm it, but finance says an earlier invoice is overdue. Someone checks a spreadsheet, calls the owner and waits for permission to proceed.

An ERPNext credit limit can help formalise part of that decision. The business still needs to decide when credit should be checked, how overdue invoices should affect further sales and who can approve an exception.

ERPNext Credit Limit

This guide explains the setup and the decisions around it, with a distributor example and practical checks for rollout.

How to Set a Customer Credit Limit in ERPNext

Enter the approved limit for the correct company

The current ERPNext credit-limit documentation describes this setup:

1. Open the Customer record and its Accounting tab.
2. Add a row in Credit & Overdue Limits.
3. Select the Company and enter the approved Credit Limit.
4. Review Bypass credit limit check at sales order.
5. Save the Customer.

For example, finance might approve ₹2,00,000 for a retailer buying from one distribution company. Keep the approval basis separately: who authorised the amount, when it should be reviewed and what conditions apply.

Test the setting before applying it widely

Start with a test customer in a staging environment. Attempt a representative transaction using an ordinary sales user’s permissions. Record the settings, starting balances and result.

A screenshot showing the entered amount proves that the record was saved. It does not establish that every transaction route follows the intended policy. Include the routes your team actually uses, such as direct invoices or orders created through an integration.

Credit Limit, Payment Terms and Overdue Amount Are Different Controls

Before changing settings, agree on what each rule should accomplish.

Concept	Business question	Illustrative policy
Credit limit	How much exposure are we prepared to accept?	Approve credit up to ₹2,00,000.
Payment terms	When should payment become due?	Payment due within 30 days.
Overdue policy	What should happen after payment becomes late?	Require finance review before further billing.

A credit limit controls exposure; payment terms determine due dates

Payment Terms can define credit periods or staged payment schedules. An invoice might require an advance followed by a balance payment, rather than one amount due on one date. Review the generated schedule before submission because the due dates affect subsequent follow-up.

Your team should also agree how it wants to treat accepted orders and goods awaiting invoicing. Do not assume the customer’s invoice outstanding is the only figure relevant to every credit check. Trace the calculation for your actual document sequence.

An overdue customer can still be below the credit limit

Consider a customer with ₹80,000 outstanding against a ₹2,00,000 facility. If ₹30,000 is overdue, finance may want a review before further sales even though the total is below the approved amount.

This example describes a business requirement. Whether the next transaction is restricted depends on the applicable overdue controls, settings and transaction path. Giving the customer a larger amount limit does not resolve the overdue-policy question.

Which Credit Limit Applies to a Customer?

Customer, Customer Group and Company precedence

The documented sequence is Customer, then Customer Group, then Company. A more specific applicable limit takes priority. A group default is evaluated for individual customers; it is not a shared facility for the whole group. Zero does not establish an effective limit at that level, so it should not be assumed to mean cash-only sales.

For policy design, distinguish a customer-specific exception from a rule that should apply to a customer segment. If a dealer receives special terms, record the reason where finance can review it instead of relying on an undocumented understanding.

Company selection needs special attention

Check that the limit row belongs to the company on the transaction. Separate legal entities may approve different facilities for the same customer.

A branch structure raises a different question: does management want one facility for the legal entity or separate internal allocations? Establish the organisation structure before deciding how to represent the policy. Turqosoft’s guide to ERPNext for multi-location businesses explains the broader company, branch and warehouse decisions.

When Does ERPNext Check Credit During the Sales Process?

An order being drafted, accepted, picked, dispatched and invoiced represents several different decisions. Your credit policy should identify which of those decisions requires a check.

Sales Order checks and the bypass setting

The documented Sales Order bypass option changes whether that stage checks credit. Later invoice checks can still apply. Treat enabling bypass as a policy choice and test the downstream effect.

If finance wants to review credit before sales commits a delivery date, a check that occurs only later may leave an operational gap. Ask sales what “confirmed” means to customers: an acknowledgement of demand, or a promise to supply? Agree on that meaning before designing approvals.

Invoicing and overdue-customer controls

Current Accounts Settings documentation describes an overdue billing threshold and a role permitted to bypass it. This is distinct from deciding the maximum credit amount.

Review the corresponding settings on your release, then test a customer whose total exposure is below the amount limit but whose overdue position breaches the intended rule. Record the precise condition that caused the restriction. A message saying a transaction cannot proceed should lead users toward the correct action, such as allocating a payment or requesting review.

Dispatch controls and authorised exceptions

Do not assume that invoice restrictions alone meet a requirement to prevent goods leaving the warehouse. Walk through the sequence your business uses, especially when delivery precedes billing.

Similarly, allowing a role to override a check is different from requiring a recorded approval. A business may need an approval reason, transaction-specific authorisation or a second approver above a threshold. Those requirements need their own design.

ERPNext Workflows supports approval states, role-based transitions and conditions. A particular credit-approval process must still be configured, and additional logic may be needed to evaluate the business rule or enforce it at the required checkpoint.

Worked Example—Five Credit-Control Scenarios for a Distributor

Imagine a Kochi distributor supplying tools to retailers. For this hypothetical example, finance approves a ₹2,00,000 credit facility for one customer. The company also wants overdue accounts reviewed before further billing.

The figures below illustrate policy decisions. They are not a universal ERPNext exposure formula or observed software results. Use each row as an acceptance test on your installation.

Scenario	Starting position and action	Policy expectation	What to verify
Within the facility	₹1,00,000 existing exposure; proposed ₹40,000 commitment; nothing overdue	Allow the transaction if other conditions are satisfied	Check the applicable calculation and attempt submission as a sales user.
Facility exceeded	₹1,80,000 existing exposure; proposed ₹40,000 commitment	Stop ordinary submission and require the agreed resolution	Record the validation, applicable limit and permitted exception route.
Below limit, but overdue	₹80,000 outstanding, including ₹30,000 overdue; proposed ₹20,000 sale	Apply the company’s separate overdue policy	Verify the configured threshold and the exact document checkpoint.
Payment recorded	Customer says ₹50,000 has been paid	Reassess using the correctly recorded payment	Verify submission, company, customer and allocation; then repeat the transaction.
Exception requested	Finance agrees to a one-off supply above the usual facility	Allow only the authorised exception	Check the user’s permissions, approval evidence and whether other orders remain controlled.

Retain document references and screenshots with the results. Where the outcome differs from policy, describe the difference precisely: “Sales Order submission allowed for this user under these settings” is more useful than “credit control does not work.”

Test partial deliveries, returns and direct invoices if they are part of daily operations. An acceptance test is valuable only when it resembles the process people will use after rollout.

Why Is the ERPNext Credit Limit Not Working as Expected?

Check configuration and permissions first

Use the following diagnostic sequence before changing the approved amount.

Symptom	Review first	Appropriate next step
Customer-specific limit seems ignored	Company selection, saved row and fallback settings	Identify the applicable policy record.
Sales Order proceeds unexpectedly	Bypass setting and submitting user’s permissions	Compare the configuration with the intended checkpoint.
One user can proceed while another cannot	Assigned roles and configured exception permissions	Confirm that the difference is intentional.
Invoicing stops, but dispatch has already happened	Actual delivery and billing sequence	Review where the business needs its control.
Report differs from finance’s working sheet	Company, date, invoice status and payment treatment	Reconcile the underlying records before altering policy.

Check balances and payment records before changing policy

A bank receipt, a draft payment and an allocated payment should not be treated as interchangeable during an investigation.

Payment Reconciliation links an existing submitted payment or credit with outstanding invoices. It updates allocation rather than creating another bank movement. Review the party, company and account before reconciling; selecting the wrong invoice can create a different follow-up problem.

Use the Accounts Receivable report to inspect invoice balances and ageing. Check the reporting date and whether ageing is based on posting or due date. A total without its underlying invoices may conceal the reason finance considers the customer overdue.

For a new implementation, inspect opening receivables too. An incorrect migrated balance can make a correctly configured restriction appear unreasonable. The Tally to ERPNext migration guide provides broader context for validating opening data.

Do You Need Configuration, Training or a Custom Approval Workflow?

Match the requirement to the intervention

Begin with a written requirement and the observed gap.

Requirement or problem	Assessment direction
Approved limits have not been maintained	Configuration and master-data review
Staff do not understand why transactions stop	Training with representative examples
Payment records are incomplete or incorrectly allocated	Accounting-process and data review
Finance needs additional approval stages	Workflow assessment
Goods must be held at a different transaction checkpoint	Transaction-control assessment
Management wants consolidated exposure across separate records	Reporting and policy-scope assessment

These are starting points for assessment. Some requirements can be met through standard configuration; others combine configured workflows with custom development. A third-party integration introduces another route that must be evaluated separately.

What affects implementation effort?

The effort depends on the number of companies, transaction routes and existing changes. It also depends on whether finance can provide reliable balances and an agreed policy.

A request to enter approved limits is materially smaller than a requirement for temporary exceptions, escalation and dispatch holds across several channels. Scope the latter around clear acceptance criteria rather than a vague request for “advanced credit control.”

Turqosoft’s ERPNext implementation cost guide explains why business requirements affect implementation effort. A price or delivery commitment should follow that assessment.

Credit-Control Rollout Checklist for Finance and Sales

Before activating the policy broadly, confirm that:

• Finance has approved limits, overdue rules and review responsibilities.
• Customer records and company selections have been checked.
• Opening receivables and significant unallocated receipts have been reviewed.
• Sales understands when an order may be promised to a customer.
• Dispatch knows how a hold or release is communicated.
• Exception permissions are limited to approved users.
• The five scenarios have been tested, including relevant integration routes.
• Someone has recorded the outcome and accepted any remaining gaps.
• Users know where to report an unexpected restriction.

Review exceptions after rollout. If staff repeatedly ask for overrides, investigate whether the policy, records or transaction design needs adjustment. Repeatedly increasing limits can hide the underlying problem.

Make the Next Credit Decision Consistent

An ERPNext credit limit is useful when its settings, underlying records and transaction controls match the policy finance has approved. Start by testing one customer’s normal sale, overdue position and exception route.

If the result does not match your intended process, identify the gap before adding code or changing limits. 

Need help assessing that gap? 

Discuss your credit-control configuration and sales process with Turqosoft.