How ERPNext credit limits stop over-exposure before the invoice goes out
ERPNext supports credit limits at the Customer, Customer Group and Company levels, and it can stop submission of new Sales Orders or Sales Invoices once a limit is reached, until exposure falls or an authorized role approves. For a finance or sales operations leader, this moves credit policy out of spreadsheets and into the document flow, so the check runs when a salesperson creates the order rather than when someone in finance notices the balance. Teams usually need this when several people can take orders for the same customer, when payment terms vary by account, or when a single large order could push a customer well past what the business is willing to carry.
The feature does not replace the rest of credit management. ERPNext holds the limit you set and compares it with outstanding exposure, but it does not score customers, decide what limit a customer deserves, or chase overdue invoices. Credit scoring, the collections process, and any trade credit insurance policy still sit outside the system, and the limits in ERPNext are only as sound as the inputs your team feeds them. Confirm with your own credit team which exposure figure the check uses, how it treats orders already accepted but not yet invoiced, and whether a customer with several group memberships picks up the lowest or highest applicable limit, then test those answers against your own policy before go-live.
Where to set the limit: customer, customer group or company
A limit set on the Customer record applies to one account and is the most specific control ERPNext offers for credit. It fits customers with negotiated terms, a known payment history or a credit insurance cap that differs from the rest of their group. Because it is set per record, it is also the place where exceptions tend to accumulate over time.
- Best for exceptions: Use it when one account needs a limit that differs from its group, such as a larger approved exposure for a strategic buyer.
- Interaction with group policy: Confirm in your version whether a customer-level value replaces the group value or whether the stricter of the two applies. Do not assume either behavior.
- Maintenance cost: Every customer record carries its own number, so changes to policy must be made account by account unless you export and update them in bulk.
- Typical mistake: A generous customer-level limit quietly overrides a tighter group policy, and nobody reviewing the group sees it.
- Ownership: Decide who may edit the field and log changes, because the customer record is often editable by sales roles.
Before go-live, run a test with one customer whose group limit is lower than its customer limit and confirm which value blocks the order.
A limit set on the Customer Group applies to every customer assigned to that group. It fits policy that depends on segment, such as retail accounts, distributors or export buyers, where the risk profile is similar and the same approval rules should apply. It keeps the policy visible in one place and reduces the number of records to review.
- Best for segments: Use it when the risk rule is the same for everyone in the segment and changes should take effect across the group together.
- Assignment discipline: The limit is only as accurate as the customer group assigned to each account, so check that new customers are placed in the right group at creation.
- Interaction with customer limits: Confirm which value ERPNext applies when a customer has both a customer and a group limit, and document the answer for your team.
- Typical mistake: Customers are left in a default group with a broad limit, so the policy looks strict on paper but applies loosely in practice.
- Reporting: Group-level exposure reports help you see whether a segment is concentrating risk in a few accounts.
Confirm the precedence rule with a test order for one customer in each group setting before you rely on the group limit for control.
A limit set at Company level is the broadest control and applies across the selling entity. It fits an overall exposure ceiling set by finance or the board, or a cap that protects the balance sheet regardless of how individual accounts are configured. It is the backstop when lower-level settings are missing or wrong.
- Best for ceilings: Use it as an entity-wide guardrail that caps total exposure, not as the main tool for account decisions.
- Multi-company setups: Each company carries its own setting, so confirm that every selling entity has the intended value rather than relying on one company's configuration.
- Interaction with narrower limits: Confirm in your version which limit blocks first when company, group and customer values all exist, and whether the company value acts as a floor or only applies when nothing narrower is set.
- Typical mistake: The company limit is left blank or set very high, so it never triggers and the team assumes a ceiling exists.
- Ownership: Finance usually owns this level, so changes should go through the same approval path as other financial settings.
Test the company ceiling with a customer that has no narrower limit, then with one that does, to see which value stops the order.
When more than one level has a value, the outcome depends on how the version evaluates them, and that is the point where many credit policies fail. Treat the combined behavior as something to verify in your own version rather than something you infer from the labels. The design goal is that a narrower exception never silently weakens a broader rule your policy requires.
- Write the policy first: Decide whether the stricter value should always win, or whether a customer exception may relax a group rule, and record that decision before configuring.
- Test the matrix: Check at least four cases: no limit, company only, group and company, and customer and group, each with a sales order and a sales invoice.
- Check the exposure basis: Confirm what counts toward exposure, including outstanding invoices, open orders and any credit notes, since this changes the result as much as the limit value.
- Re-test after upgrades: Precedence can change between releases, so repeat the matrix after each version upgrade.
- Keep a record: Save the test results with the configuration so auditors and new administrators can see how the rule was verified.
Ask your implementation lead to show the precedence in writing, backed by test evidence, before you sign off the credit policy.
Most credit control gaps come from configuration that looks correct but was never tested against the policy it is meant to enforce. The mistakes below appear often enough to check for in any review, and each one is easier to prevent at design time than to correct after orders have passed.
- Silent overrides: A customer-level limit overrides a tighter group policy without anyone reviewing the group, so the stricter rule stops applying to that account.
- Blank or inflated ceilings: A company-level limit is left empty or set so high it never triggers, which gives a false sense of coverage.
- Wrong group assignment: New customers default into a broad group, so segment policy is bypassed from the first order.
- Unowned exceptions: Customer limits are raised during sales negotiations without a record of who approved the change or why.
- Untested upgrades: Precedence or exposure calculations change in a new release, and nobody repeats the test matrix.
Before sign-off, export all customers with a limit and their group assignment, then check the list against the approved policy.
Configuration options and when each fits
This table compares the three places ERPNext lets you set a credit limit (customer, customer group and company) and the behavior each one produces at order and invoice stage. Read each row against your own credit policy, then check the override and warning behavior in your version before you finalize the design.
| Option | Where it is set | What it blocks | When it fits | Trade-off |
|---|---|---|---|---|
| Customer credit limit | Credit limit table on the Customer record | New Sales Orders and Sales Invoices for that customer once the limit is reached | Individual accounts with negotiated terms or a history that justifies a specific ceiling | Every new account needs its own maintenance, so review cadence matters as the customer base grows |
| Customer group credit limit | Credit limit table on the Customer Group record | Sales documents for all customers in the group, measured against the group's limit | Segments such as distributors, retailers or regions that share a standard risk profile | Individual exceptions must be handled by overriding the customer level, which can blur who owns the decision |
| Company credit limit | Credit limit setting for the company | Sales documents across the company once total exposure reaches the ceiling | A group-wide cap on receivables exposure set by finance leadership | A single breach can stop unrelated customers, so confirm how the check interacts with customer-level limits in your version |
| Hard block at submission | Credit control behavior tied to the limit | Submission of new Sales Orders or Sales Invoices until exposure falls or an authorized role approves | Policies where no new credit may be extended without sign-off | Sales operations may be delayed; confirm how urgent orders are handled and who can release them |
| Warning behavior | Confirm in your ERPNext version whether a warning-only mode exists and where it is configured | Confirm whether documents still submit with a warning shown to the user | Teams that want visibility before enforcing a limit strictly | Warnings are easy to ignore; confirm whether they are logged for later review |
| Role that can override | Role assigned to the user, confirmed in the credit limit settings of your version | Allows an authorized user to submit a document beyond the limit after approval | Named credit controllers or finance managers who own exceptions | Overrides weaken control if the role is granted broadly; limit it and review the approval log regularly |
| Bypass at sales order stage | Confirm the exact setting or permission in your ERPNext version | Whether the check runs when the Sales Order is created or only later at invoice | Only if your policy explicitly allows orders to be taken before credit is approved | Exposure can build up through orders that are later invoiced, so test both stages before relying on this |
Setting up credit limits and the override role
This sequence takes a company from its receivable account setup to a tested credit control, so that new Sales Orders and Sales Invoices for over-limit customers are blocked and only an authorized role can approve them. Each step ends with a check you can record for your approval path.
Confirm company and receivable accounts
Before setting any limit, confirm the company that will carry the credit exposure and the receivable account each customer will post to. Check that the Customer records under that company point to the correct Debtors accounts and that the currency matches the sales ledger. Credit exposure is measured against outstanding receivables, so a wrong account or company default will produce misleading balances. The step is done when a sample customer shows the expected company and receivable account, and an outstanding balance can be traced to its sales invoices in the General Ledger.
Define customer groups for credit tiers
Create Customer Groups that reflect your credit policy, such as standard trade accounts, strategic accounts and cash-only accounts, so limits can be applied to a tier instead of to each customer by hand. Assign existing customers to the right group and decide which group is the default for new customers. Your finance and sales leaders should agree the tier definitions in writing before anything is configured. The step is complete when a filtered customer list shows each tier and every active customer belongs to exactly one group.
Set limits at the chosen level
Enter credit limits at the level your policy requires: on each Customer, on a Customer Group, or at Company level, and record which level applies when more than one is set. ERPNext supports credit limits at all three levels, so confirm in your environment which one takes precedence for your version before you rely on it. Use illustrative figures only in the test environment and keep production values in the approved credit policy. The step is done when a sample customer's limit appears on its record and the chosen precedence has been confirmed by a test case.
Set the block behavior and assign the override role
Decide whether the credit check stops submission of new Sales Orders and Sales Invoices when the limit is reached, and configure that behavior as the policy requires. Then assign the authorized approval role to the named users who may release an over-limit document, and remove that role from everyone else. Confirm that these users hold the role through their User records and that no other role grants the same ability by accident. The step is complete when a user without the role cannot release an over-limit document and a user with the role can.
Test with an over-limit Sales Order
Create a test customer with a low limit and submit a Sales Order whose value takes exposure above that limit. The submission should be stopped with a credit limit message, and the order should not reach a submitted state. Repeat with a value just under the limit to confirm that the order is accepted. Record both results with the user, date and limit values used. The step is done when the block and the accepted case both behave as your policy states.
Test with a Sales Invoice and an approval
Repeat the test with a direct Sales Invoice, since the control can apply at invoice stage as well as order stage. Confirm the block for a user without the override role, then have an authorized user approve the transaction through the approval path and confirm that it submits. Also check what happens after a payment reduces exposure, because the document should become allowed again once the outstanding balance falls below the limit. The step is complete when block, approval and recovery have each been observed and recorded.
Document the approval path and review access
Write down the approval path as an operating procedure: who requests a release, who holds the override role, what evidence is kept, and how limit changes are approved and logged. Export the role assignments and the limit settings so the configuration can be reviewed. Ask your auditors or internal controls team to confirm the procedure matches the policy they expect. The step is done when the procedure, the role list and the test records are stored together and the control owner has signed off on them.
Bypassing credit checks at the sales order stage, and why it needs a rule
The core decision is whether an authorized user should be able to release a Sales Order that exceeds a customer's credit limit, and if so, under what rule. ERPNext's credit limit control can stop submission of new Sales Orders or Sales Invoices once the limit is reached, until exposure falls or an authorized role approves. The override is therefore a business exception, not a configuration detail, and it should be written down before go-live. Confirm in your version exactly which role can approve, whether the approval happens on the Sales Order, the Sales Invoice, or both, and whether a bypass permission is separate from the role that sets the limit. Those permissions are easy to grant broadly during testing and forget to narrow afterward.
The two stages carry different risk. A Sales Order approval commits the company to deliver goods or services on credit, but no revenue or receivable exists yet. If the approved order is later invoiced, the invoice stage may check the limit again, so a reviewer should test whether the released order still passes at invoice time. Confirm whether an approval granted at order stage carries through to the Sales Invoice, or whether the invoice is blocked again. Also check how deliveries are handled, since shipping goods against an over-limit order increases exposure even when billing is delayed. Document which stage the approver is accountable for, and who signs off on that decision.
The audit trail matters because a credit override is exactly the kind of exception a reviewer will ask about later. Record who approved each override, the limit and outstanding balance at that moment, and the business reason. Use the version history and comments on the document, and export or report on overridden documents regularly rather than relying on memory. The larger risk is normalization: if overrides become routine, the limit stops being a control and becomes a suggestion. Set a review cadence, track the number of overrides per customer group, and agree a threshold at which the limit itself is reviewed. Have your auditors or internal control owners confirm which evidence they will need.
Security and operational risks in credit controls
A credit limit is only as reliable as the people who can change it, the approvals behind an override, and the balances it is measured against. The cards below set out the risks that connect these areas and the controls to design before the limits go live.
Who can edit limits
Changing a Customer, Customer Group or Company credit limit is a policy decision, so edit rights on those records should be narrower than rights to create sales orders. Map which roles can open the credit limit fields, and check whether sales users can reach them through list views, copies or imports. Confirm that edit rights on limit fields sit with finance, not with the sales team that benefits from higher limits.
Override permissions and segregation of duties
ERPNext lets an authorized role approve submission once a limit is reached, so that role holds a financial control. Keep the approver separate from the person who created the order and from the person who maintains customer master data. Test a sample order end to end with two users to confirm the separation holds in practice, not only on paper.
Audit trail of overrides
An approved override should leave a record that someone can retrieve later: who approved it, for which order, against which exposure, and why. Review ERPNext's version history and comments on the blocked document, and decide whether the approval reason is recorded in a required field or in a free-text comment. Agree the retention period for these records with your auditors before go-live.
Limit changes during a dispute
When a customer disputes an invoice, sales may ask for a higher limit to keep shipping, while finance may want the account frozen. Define who can change the limit during a dispute, whether the change must be time-bound, and how it is reverted. Without this rule, a temporary increase can quietly become the permanent limit.
Data quality of outstanding balances
The check compares a new order against the exposure ERPNext calculates from receivables, so unposted invoices, misapplied payments or open credit notes distort the result. Reconcile the receivables ledger against the customer exposure figures on a fixed schedule, and check that payments and returns are posted in the period they occur. Ask whether your data migration brought in historical balances with their original dates.
Role changes after staff turnover
When an approver moves teams or leaves, their override rights may remain active, or the role may be granted to a group of users who no longer need it. Set a recurring review of who holds the credit approval role, tie removal to offboarding, and check that role assignments made through group or permission rules are reviewed along with direct assignments.
Questions teams ask before configuring ERPNext credit limits
What drives the effort to configure ERPNext credit limits?
The effort is driven mainly by how many limits you need to set and how well your credit policy is written down. A single company-level limit takes little work, while per-customer limits across a large receivables book take longer because each limit needs an owner, a basis and an approval rule. The number of customer groups, the number of companies sharing one customer base, and whether limits differ by currency or payment terms all add configuration and review steps. Expect more work if sales orders and invoices flow through different teams, because each document type must be tested against the same policy.
Can one internal team configure ERPNext credit limits without a partner?
A capable internal team can configure credit limits if it has an ERPNext administrator who understands Customer, Customer Group and Company records, and someone who owns the credit policy. The harder part is usually agreeing on the policy itself: how limits are calculated, who may approve exceptions and what happens to open orders when a limit is reached. Teams without a Frappe-experienced administrator often use a partner for the configuration review and the test plan, while keeping policy decisions in-house. Confirm your internal skills against the ERPNext credit limit documentation before deciding.
What does the work need from finance and sales?
Finance must define the credit policy: the exposure measure, the limit per customer or group, the treatment of unpaid invoices and the approval authority for overrides. Sales must confirm which customers are active, which terms they trade on and which orders are time-sensitive enough to need an exception route. Both teams should agree on who receives a blocked-order notice and how quickly they respond. Without these decisions written down, the configuration will reflect whatever default the implementer chose, which is rarely what the business expects.
How long does testing usually take for credit limits?
Testing time depends on the number of customers, the complexity of the customer group structure and the number of document paths you need to cover. A small customer base with one company and a few groups can be tested with a short set of scenarios. A larger book with multiple companies, overrides and partial shipments needs more cases, including orders that cross the limit, invoices raised after payment and approvals by each authorized role. Ask any partner to show the test matrix in the written scope, because it reveals how much verification the quote includes.
Does customer data need cleaning before limits are set?
Yes, it helps to clean customer data first. Duplicate customer records, outdated groups and inconsistent company assignments will make exposure figures and limit checks unreliable. Confirm that open invoices and unpaid balances are accurate, because the limit logic depends on them. If you are migrating from another system, check how opening balances were loaded and whether they match the ledger. A short reconciliation of receivables before go-live usually prevents blocked orders caused by bad data rather than real credit risk.
Which role should be able to override a credit limit?
Only a role that finance has explicitly authorized should override a limit. Name the role, the people in it and the conditions under which an override is allowed, such as a maximum amount or a required approval note. Test that users without this role receive the block as intended, and that overrides are traceable in the document history. Confirm with your security owner how the role is assigned, because overrides are a control point that auditors and finance leaders will ask about.
What should I ask a partner for in a quote about credit limits?
Ask for a written scope that lists each credit limit level in use, the document types that will be blocked, the override role and its approval rule, and the test cases that will prove the behavior. Request the assumptions about customer data cleanup, the number of companies and customer groups, and the responsibilities split between your team and the partner. Also ask what training is included for sales and finance staff and what support is available after go-live. DeployOpen provides fixed-scope quotes based on this written scope.
How DeployOpen scopes and delivers credit control configuration
Credit control work starts with a written scope agreed before any configuration begins. The scope names which limits apply at customer, customer group and company level, which documents are blocked when exposure reaches the limit (Sales Orders, Sales Invoices, or both), which role may approve an override, and which exceptions, if any, are allowed at the sales order stage. It also records what is out of scope, such as receivables collections or credit scoring from external bureaus. Your finance lead, sales operations lead and an ERPNext administrator should sign off on this document together, because each of those decisions changes what a salesperson sees on screen.
Configuration is then tested against your own customer data and your own roles, not a generic demo dataset. DeployOpen builds a test company with a representative sample of customers, customer groups, open invoices and orders, and runs each credit scenario through the actual user roles your staff hold: a salesperson hitting the limit, a credit controller approving an override, and a user who should be unable to change the limit at all. Expect the test cycle to repeat whenever a role or customer group changes. Confirm with your ERPNext version's documentation how credit limit checks interact with bypass permissions, because that behavior should be verified in your environment rather than assumed.
Each approval path is documented as a short runbook covering who may override, how the override is recorded, and how exposure is brought back under the limit. This document is what your auditors and internal control owners will ask to see. DeployOpen does not issue audit opinions, but it prepares the configuration evidence they need. Because credit policy and staffing change, many clients add an optional retainer for upgrades, role changes and periodic review of limits. Ask any partner, including DeployOpen, to state in the quote which of these items are fixed-scope and which recur.
