Skip to content

Odoo Credit Limits and Collections: A Practical Guide

Managing Customer Credit Risk and Overdue Payments in Odoo

The Order That Should Never Have Left

A customer places an order on a Tuesday. They already owe you for three invoices, the oldest of which is ninety-four days old. The order is picked, packed, despatched and invoiced, and nobody involved in any of those steps knew about the ninety-four days.

Six weeks later the customer stops answering the phone, and the amount at risk is now larger than it was on Tuesday, by exactly the value of the order you chose to ship.

Except nobody chose. That is the part worth sitting with. No individual decided to extend further credit to a customer who was not paying; the order simply moved through a process that had no point at which anyone was required to look. The decision was made by the absence of a control.

This article is about putting that control back. It covers how to set credit limits that reflect something real, what should happen when one is breached, how to run collections as a process rather than as a monthly act of remembering, and the reports that change behaviour rather than merely describing it. It is written for finance leaders (CFOs, controllers and credit managers) and for the sales directors who will have opinions about all of it.

The Business Problem: Credit Decisions Made by Nobody

The symptoms are consistent across trading, distribution, manufacturing and services businesses.

  • Credit limits exist on paper and nowhere else. A limit was agreed when the account was opened, written on a form, and never connected to anything that could act on it.
  • Nobody knows the exposure at the moment of the order. The salesperson sees a customer. Finance sees a ledger. Neither sees both at the point the order is taken, which is the only moment the information would have changed anything.
  • Collections depend on one person’s recall. Somebody runs an aged debtors report, works down it, and chases whoever they get to. Customers who are awkward get chased; customers who are quiet do not.
  • Escalation is improvised. There is no agreed point at which an account stops being a collections matter and becomes a commercial decision, so every difficult account is handled differently depending on who is dealing with it.
  • Disputes hide inside the ageing. A substantial share of apparently overdue balances are not refusals to pay; they are unresolved queries about a delivery, a price or a credit note. Nobody is distinguishing the two, so collections effort goes to the wrong accounts.
  • Sales and finance disagree, structurally. Sales is measured on orders. Finance is measured on cash. With no agreed rule between them, the argument recurs monthly and is settled by whoever is more senior that day rather than by policy.

What Uncontrolled Credit Costs

  • Working capital, continuously. Every day of unnecessary days-sales-outstanding is cash funding someone else’s business. In a thin-margin distribution business, the financing cost of slow receivables can exceed the net margin on the sales that created them.
  • Bad debt, occasionally and expensively. A write-off is not a cost equal to its value; it is a cost equal to the sales you must make to replace the lost margin, which at a ten per cent net margin means ten times the write-off in replacement revenue.
  • Concentration risk nobody measured. Businesses routinely discover, at the worst possible moment, that a single customer represents a significant share of total receivables. Without exposure reporting, that fact is invisible until it matters.
  • Wasted collections effort. Chasing disputed invoices is work that cannot succeed, because the customer is not withholding payment; they are waiting for an answer. Until disputes are separated from genuine overdues, a meaningful share of collections time is spent on accounts that need a different department.
  • The relationship cost of inconsistency. Customers notice when the rules change depending on who they speak to. Inconsistent credit treatment damages relationships more reliably than firm, consistent treatment ever does.

Setting a Credit Limit That Means Something

Most credit limits fail because of how they were set, not how they were enforced.

  • Base it on evidence, not on the order the customer wants to place. A limit set to accommodate the first large order is not a limit; it is a formality. The inputs that matter are trading history, payment behaviour, any credit reference or insurer position you hold, and the customer’s size relative to your own exposure tolerance.
  • Set a policy for new accounts. A default opening limit, a defined probation period, and a review point. Without this, every new account becomes an individual negotiation conducted by whoever opened it.
  • Define who can change a limit, and record why. This is the single most important governance point in the whole area. A limit anyone can raise is not a control. A limit raised with a recorded reason and an approver is both a control and an audit trail.
  • Review limits on a schedule, in both directions. Most businesses only ever raise limits. A customer whose payment behaviour has deteriorated should have their limit reduced, and that only happens if review is a calendar event with an owner rather than a reaction to a problem.
  • Distinguish the limit from the terms. Thirty days and fifty thousand are different controls answering different questions: how long they may take, and how much they may owe. Businesses that conflate them end up enforcing neither.
  • Account for group exposure. Where several customer records belong to one corporate group, exposure is a group number. A limit per record understates risk in exactly the cases where it matters most.

Deciding What Happens When the Limit Is Breached

This is the decision that determines whether any of this works, and it has to be made by the business rather than by the system.

Three positions are available, and the right one differs by customer segment:

  • Warn. The order proceeds, but the person taking it sees the exposure and the ageing. Lowest friction, and it depends entirely on the warning being acted upon. Appropriate for established accounts with good history where the breach is likely to be timing rather than trouble.
  • Require approval. The order is held until a named person releases it. This is the position most mid-market businesses should take as a default, because it inserts a decision without stopping trade. The critical design point is that approval must be fast: an approval step with no service standard becomes a queue, and a queue becomes a workaround.
  • Block. The order cannot proceed. Appropriate for accounts already in a collections process, for new accounts without established history, and for any account where the commercial decision has already been taken.

Three rules that make any of these work:

  1. The rule must be written down before it is configured. A control implemented without an agreed policy becomes an argument with the system rather than a conversation about the customer.
  2. Approval must have a named owner and a response time. β€œFinance will look at it” is not an approval process.
  3. There must be a documented override path with a recorded reason. Overrides will happen: a strategic customer, a quarter-end, a genuine timing issue. Pretending otherwise means they happen informally and invisibly. An override with a name and a reason attached is a control; an override without one is a hole.

Collections: Running It From the System, Not From Memory

Collections run from an aged debtors report is collections run from whoever shouts loudest. The alternative is a defined sequence that happens whether or not anybody remembers.

Segment Before You Chase

Not all overdue balances are the same thing, and treating them identically wastes the effort:

  • Timing: invoice sent late, customer pays on a fixed run date, payment in transit. Needs confirmation, not pressure.
  • Administrative: wrong purchase order number, invoice sent to the wrong person, missing reference. Needs a correction, and it is usually the fastest money in the ledger.
  • Disputed: a query about quantity, price, condition or a promised credit note. Needs the dispute resolved; collections pressure achieves nothing until it is.
  • Unable or unwilling: the genuine collections case, and usually a much smaller share of the ageing than the report suggests.

Build an Escalating Sequence with Defined Timings

A reminder before due date for larger invoices, a prompt notice shortly after, a firmer written notice, then a call, then an internal escalation to the account owner, then a defined commercial decision point. The specific intervals matter less than the fact that they are fixed and applied consistently.

Automate the Early Stages and Reserve People for the Late Ones

The first two or three steps are information, and information can be sent reliably by a system. Human effort belongs where judgement is required, which is the conversation about a disputed balance or a deteriorating account, not the sending of a first reminder.

Log Every Promise to Pay, with Its Date

A broken promise is the most reliable early warning available, and it is only visible if promises were recorded in the first place.

Agree the Handover Point in Advance

The stage at which an account moves from routine collections to a commercial decision (stop supply, payment plan, external recovery) should be defined before you need it, because defining it in the moment produces inconsistency and delay.

Give Disputes an Owner and a Clock

Disputes sitting unresolved are not a finance problem; they are an operations or sales problem being stored in the receivables ledger. Routing them out, with a response time, typically removes a surprising share of the ageing.

The Reports That Change Behaviour

Most businesses have an aged debtors report and nothing else. These are the ones that actually alter decisions.

  • Exposure against limit, by customer. Balance, limit, headroom, and whether an order is currently pending. This is the report that makes the credit position visible before the order rather than after the invoice.
  • Ageing split by reason, not just by bucket. Timing, administrative, disputed, genuine. The same total, categorised, directs effort correctly and usually shows that the collections problem is smaller and more specific than it appeared.
  • Days sales outstanding, tracked monthly as a trend. The headline number. Its value is in the direction of travel, not the absolute figure.
  • Concentration: top ten customers as a share of total receivables. The risk report nobody runs until after the event.
  • Promises made and promises kept. The best available predictor of which accounts are heading for difficulty.
  • Credit limit overrides, by approver and reason. An uncomfortable report, and a necessary one. If overrides are concentrated in one approver or one customer, you have found either a policy that is wrong or a control that is not working.
  • Dispute ageing, owned outside finance. How long queries sit unresolved, and with whom. This is usually the fastest improvement available to a business starting this work.

Implementation Considerations

  • Clean the ledger before you configure anything. Unapplied credits, old unreconciled balances and duplicate customer records will make any limit you set wrong on day one, and will destroy confidence in the reporting immediately.
  • Consolidate group customer records. Exposure is a group question; a ledger that splits one group across six records cannot answer it.
  • Set the policy document first. Limits, terms, who approves what, the breach rule, the collections sequence, the escalation point, the override rule. One or two pages. Configure afterwards.
  • Bring sales into the design, not the announcement. Credit control is experienced by the sales team as a constraint on their numbers. Involving them in setting the rules produces rules that survive contact with customers; announcing the rules produces workarounds.
  • Phase the enforcement. Run in warning mode first so you can see how often the rule would have bitten, and on which accounts, before anything is actually blocked. This surfaces bad limits and bad data before they surface as blocked orders.
  • Train the people who take orders, not just finance. The control operates at the point of order entry. If the person there does not understand what the warning means or what to do about it, the control is decorative.
  • Agree the reporting pack and its owner. Monthly, to a named audience, with the same reports every time. Credit control that is not reported is credit control that quietly stops.

Blocking Approaches Compared

ApproachWhat happens at the limitFrictionBest used forMain risk
No controlNothingNoneNothingCredit decisions made by default, exposure discovered after the fact
Warn onlyOrder proceeds; exposure shown to the order takerLowEstablished accounts with good payment historyDepends entirely on the warning being read and acted on
Approval requiredOrder held until a named person releases itModerateThe sensible default for most mid-market businessesBecomes a queue without a response-time standard
Hard blockOrder cannot proceedHighAccounts in collections, new accounts, post-decision casesLegitimate orders stopped if limits or data are wrong
Segmented rulesDifferent treatment by customer tierModerate, and correctly targetedBusinesses with a wide spread of customer riskNeeds maintained segmentation, or it drifts into inconsistency

Best Practices

  1. Write the credit policy before configuring the system. Every later argument traces back to this not existing.
  2. Set limits from evidence, and review them in both directions on a schedule.
  3. Make approval to exceed a named role with a response time, not a department.
  4. Record every override with a reason, and report on overrides monthly.
  5. Separate disputes from genuine overdues, and route disputes out of finance with a clock on them.
  6. Automate the early collections steps; reserve people for judgement.
  7. Log promises to pay and track the kept rate.
  8. Consolidate group customers so exposure is a group number.
  9. Run in warning mode before enforcing, to find bad limits and bad data safely.
  10. Report monthly to a fixed audience: exposure, ageing by reason, DSO trend, concentration and overrides.

Common Mistakes

  • Setting the limit to fit the order. A limit designed around the order it was meant to test is not a control.
  • Enforcing on dirty data. Unapplied credits and duplicate records produce false breaches, and false breaches destroy the policy’s credibility in the first fortnight.
  • Approval with no service standard. An unbounded approval step becomes a queue, and a queue gets routed around.
  • Treating every overdue balance identically. Effort goes to disputed invoices that cannot be collected until someone answers a question.
  • No override path. Overrides happen anyway; without a sanctioned route they happen invisibly.
  • Leaving sales out of the design. Rules imposed on a sales team get worked around; rules built with them get enforced by them.
  • Reviewing limits only upward. Deterioration goes unnoticed because nobody looks for it.
  • Ignoring group exposure. The risk concentrates exactly where the record structure hides it.
  • Stopping the monthly report once things improve. Receivables discipline decays the moment it stops being visible.

An Illustrative Scenario: A Building Materials Distributor

The following is a composite illustration drawn from patterns common to distribution businesses. It is not an account of a specific Techvaria client, and no figures below come from any real engagement.

Consider a building materials distributor supplying contractors and merchants, with several hundred credit accounts and a sales team taking orders by phone and email.

The Starting Position

Credit limits were recorded on the customer master and enforced nowhere. Orders went out on the strength of the relationship. The aged debtors report was produced monthly and worked through by one person in accounts, who knew which customers responded to a call and concentrated there.

Two problems had become visible. A contractor had failed owing a sum large enough to matter, having continued receiving deliveries for several weeks after their first missed payment. And the finance director could not answer a lender’s question about receivables concentration without a week of work.

What the Review Found

Three things, none of them about the system. A significant share of the ageing was disputed rather than overdue, mostly short deliveries and pricing queries that had been raised and never routed anywhere. Several of the largest accounts were separate customer records belonging to the same group. And limits had last been reviewed, as a set, more than three years earlier.

What Was Implemented

The ledger was cleaned first: unapplied credits allocated, dormant records archived, group accounts consolidated. Limits were reset from trading and payment history, with a written policy covering opening limits for new accounts, who could change a limit, and a six-monthly review in both directions.

The breach rule was approval-based rather than a hard block, with a named approver and a response-time standard, and an override path requiring a recorded reason. It ran in warning mode for a full month first, which surfaced a number of limits that were simply wrong and would have blocked good customers on day one.

Collections moved to a fixed escalating sequence, with the first stages automated and people reserved for the later ones. Disputes were separated out and routed to the branch that raised the delivery, with a response time attached. Promises to pay were logged.

After Two Quarters

The most significant change was not in collections at all: routing disputes out of finance removed a meaningful portion of the ageing that had never been collectable in the first place, and did so faster than any chasing would have. Days sales outstanding improved, though the finance director was clear that part of that was the dispute clean-up rather than better chasing.

The override report proved the most uncomfortable and most useful output. It showed overrides concentrated on a small number of accounts and one approver, which led to two limits being formally raised, because the real answer was that the policy had been wrong, not that the control was.

Industry Use Cases

  • Trading and distribution. The core case: many credit accounts, thin margins, and exposure that moves daily. See trading and distribution.
  • Manufacturing. Fewer, larger customers, which makes concentration risk the dominant concern rather than volume of chasing. See manufacturing solutions.
  • Construction and contracting. Retention, staged payments and certification disputes make the distinction between disputed and overdue especially important here. See construction.
  • Logistics. High transaction volumes with small invoice values, where administrative disputes (references, proof of delivery) make up a large share of the ageing. See logistics solutions.
  • Professional services. Fewer invoices, larger values, and disputes that are usually about scope rather than delivery. See professional services.

Frequently Asked Questions

For most mid-market businesses, approval is the right default: the order is held until a named person releases it, which inserts a decision without stopping trade. Reserve hard blocks for accounts already in collections or without established history, and use warnings for established accounts with good records. Whichever you choose, write the rule down before configuring it.

Involve them in writing the policy rather than announcing it to them. Most objections are about response time rather than about control; a salesperson’s real fear is an order sitting in a queue with no answer. A named approver with a service standard addresses that, and a documented override path addresses the rest.

From policy rather than from the first order. A default opening limit, a defined probation period and a review point. If the first order exceeds the opening limit, that is a conscious decision for somebody to take and record, not a reason to set the limit at whatever the order happens to be.

It helps by making the distinction visible. Disputed balances are not a collections problem and cannot be fixed by chasing; they need routing to whoever can answer the query, with a response time. Separating the two is frequently the single fastest improvement available, because it both reduces the ageing and redirects collections effort to accounts where it can work.

Exposure against limit by customer, ageing split by reason, days sales outstanding as a monthly trend, receivables concentration in the top ten customers, promises made versus kept, and credit limit overrides by approver and reason. The last one is the most uncomfortable and the most informative.

The configuration is not the long part. Cleaning the ledger, consolidating group customer records and agreeing the policy are what take the time, and running in warning mode for a period before enforcement is strongly worth the delay. Plan in months rather than weeks, and expect the data work to dominate.

Partly. The collections sequence matters less, but exposure reporting and the disputes distinction still apply to whatever credit trading you do, and most businesses that believe they sell only on advance payment have more credit exposure than they assume once group accounts are consolidated.

Conclusion

The order that should never have shipped was not a failure of judgement. It was a process with no point at which judgement was required.

Putting that right has three parts, and only one of them is configuration. Limits have to be set from evidence and reviewed in both directions, by someone with the authority to do it and a record of why. The breach rule has to be decided by the business (warn, approve or block), written down before it is built, and given a named owner with a response time and a sanctioned override path. And collections have to run as a defined sequence that separates disputes from genuine overdues, because chasing a customer who is waiting for an answer to a query is effort that cannot succeed.

The reporting is what keeps it alive. Exposure against limit, ageing by reason, DSO as a trend, concentration, promises kept, and overrides by approver. Credit control that is not reported monthly reverts to being run from memory within about two quarters.

Start with the ledger clean-up and the dispute split. In most businesses that is where the fastest and largest improvement is sitting, and neither requires a decision anyone will argue about.

Find Out What Your Receivables Are Really Costing You

Techvaria is an official Odoo Silver Partner with more than 350 implementations delivered since 2016, from offices in Bangalore, Ahmedabad and Dubai.

A receivables and credit control review gives you four things in writing: your current ageing split by reason rather than by bucket, so you can see how much of it is actually collectable; your true exposure by customer group rather than by record; a credit policy drafted with your sales and finance teams rather than imposed on them; and a configuration plan with a warning-mode period before anything gets enforced.

If you are already running Odoo, the review works from your live ledger. If you are not yet, it defines what the implementation needs to deliver.

Talk to our Odoo consultants, or see how we approach implementation.

Find Out What Your Receivables Are Really Costing You

A receivables and credit control review gives you your ageing split by reason, your true exposure by customer group, a credit policy drafted with sales and finance, and a configuration plan with a warning-mode period before anything is enforced. Tell us how credit control runs today and we will tell you honestly where the cash is being lost.
Mustufa Rahi

Mustufa Rahi is an Odoo Certified Functional Consultant and ERP expert at Techvaria with 15+ years of experience in implementation, automation, and business process optimization, helping organizations scale efficiently.