The Credit Hold a Salesperson Cannot Click Past
A credit limit that a salesperson can override with a reason is a note, not a control. A workspace can now set a credit policy that holds a customer who is too far overdue, and lifting that hold takes a request with a reason that somebody else approves.
A hardware wholesaler in Eldoret had a customer 74 days overdue on KES 640,000. On a Thursday in March the customer asked for another KES 210,000 of roofing sheets, and the invoice went on credit hold, exactly as it should. The salesperson typed a reason, “customer promised to pay Friday”, and overrode it. The override was recorded. Nobody else read it until the customer stopped answering the phone.
The salesperson did nothing dishonest. The customer had paid before, the sale was real, and the commission was real too. That is the point: the person who decides whether to extend credit should not be the person whose month depends on the sale. A credit policy built on 29 October makes that separation the default, for workspaces that switch it on.
One policy, three places it can be set
The Credit Policy settings page holds a workspace default: a credit limit, payment terms in days, a hold when the oldest overdue invoice passes a number of days, and a hold when the overdue balance passes an amount. Below it, segments group customers who should be treated alike — hardware retailers on 30 days, county governments on 60, walk-in accounts on cash. A customer’s own figure, where one is set, wins over the segment’s, and the segment’s wins over the workspace’s.
| Rule | What happens |
|---|---|
| Oldest overdue invoice past the day threshold | The customer is on hold |
| Overdue balance in any one currency above the amount threshold | The customer is on hold; currencies are never added together |
| Customer in a cash-only segment | The customer is on hold for credit, whatever they owe |
| An approved manual hold | The customer is on hold until a release is approved |
| The invoice would take the customer over their limit | The invoice is held; the plain over-limit hold can still be overridden with a reason |
The customer page shows the policy in force and where each figure came from: the customer, the segment or the workspace. A salesperson who asks why an invoice is held reads the reason in words, such as “An invoice is 74 days overdue, past the 60-day threshold”, before anyone has to explain it.
Off until you switch it on
The policy is a workspace setting and starts switched off. Until it is on, segments, workspace defaults and both overdue thresholds do nothing, and a customer’s own credit limit works exactly as it did before. Switching it on is a decision for the finance lead, not a side effect of an upgrade.
A policy hold has one way out
This is the part that changes the Thursday afternoon. When a customer is held by the policy — overdue past a threshold, in a cash-only segment, or on a manual hold — the per-invoice override is refused. The invoice says why and points to the customer page, where the only way forward is a release request.
-
Ask for a release, with a reason
“Paid KES 400,000 this morning by RTGS; balance by the 30th.” One hold or release request per customer can wait at a time, and it stores a snapshot of the policy and the customer’s overdue position at the moment it was asked.
-
Somebody else decides
Everyone who may approve credit holds, except the person who asked, gets it in the bell. In the approvals hub and on the customer’s credit panel, the person who asked sees “Waiting for another approver” instead of Approve and Reject. The decision needs its own reason.
-
The release runs for a set number of days
An approved release lifts the automatic hold for as many days as the workspace sets (seven unless you change it). Invoices already held go back to draft with the release written on them as the reason. When the days run out, the thresholds apply again.
There is deliberately no fallback here for a workspace with a single approver: the person who asked never decides their own request. If one person holds every role, the honest way to run credit is a policy they set in advance, not a release they grant themselves on the day.
An override with a reason tells you what happened. A release somebody else approved tells you that somebody else agreed.
Payment terms that set the due date
The same policy carries payment terms. A new invoice for a customer on 30-day terms opens with a due date 30 days after the invoice date, on the web, through the API and in the app, and so does an invoice converted from a quote or a sales order. Type a different due date and yours wins. The terms come from the same customer, segment and workspace order as the limit, so the customer page and the invoice can never disagree about them.
That matters for the holds, because “overdue” is measured from the due date. A workspace that has been entering due dates by hand has been setting its own credit policy one invoice at a time.
The roofing-sheet order, under the policy
Illustrative. Had the payment not arrived, the controller would have declined with a reason, and the salesperson would have read it in the bell.
How exposure and limits are measured in the first place is in Credit Limits: The Control That Acts Before the Money Is Gone. What happens to the invoices that do go overdue is the subject of The Promise to Pay That Nobody Wrote Down. Setting up the policy, segments and releases step by step is in the Credit Policy guide, and the wider sales module is on the sales management page.
What AWRA OpsHub does today
- A workspace credit policy, switched on per workspace and off by default: a default limit, payment terms, and holds on days overdue and on overdue amount.
- Customer segments with their own limit, terms and thresholds, including cash-only segments.
- Overdue amounts judged per currency, never added across currencies.
- A policy hold that refuses the per-invoice override; only an approved release lifts it.
- Hold and release requests with a reason, decided by someone other than the person who asked, with a reason of their own, and a release that runs out after a set number of days.
- Payment terms that default the due date on new invoices and on quote and order conversion, on the web, the API and the app; a typed date wins.
More we can add to your workspace
- A credit check at sales order confirmation, so a held customer’s order is stopped before the warehouse picks it, not only at the invoice.
- Broken promises to pay as a hold trigger, so a customer who misses two promises in a quarter is held whatever their days overdue.
- A scheduled credit limit review that lists each customer’s limit against their payment record every quarter for someone to confirm or change.
- A credit bureau lookup on a new account, stored with the decision to open it.
Where we point you to a specialist
- How much credit to extend, to whom and on what terms is a commercial decision for your finance lead. The policy applies the rules you set and records who lifted them.
- A credit hold is an internal control, not a debt collection step. Contacting a customer about a debt follows your own process and the law where you trade.
A credit check at order confirmation and a promise-based hold each build on records the workspace already keeps.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe short version
If the person who wants the sale can also lift the hold, the hold is advice. Set the policy once, keep the override for the plain over-limit case, and let a release be something a second person agrees to.
Four questions for your own credit control
Who extended credit to your most overdue customer last month?
A good answer sounds like
A named approver, with a reason, who was not the salesperson.
What it tells you
If the answer is “the system allowed it”, the salesperson decided.
How many held invoices were overridden last quarter, and by whom?
A good answer sounds like
A count and a list of names.
What it tells you
A high count from one person is a policy problem, not a people problem.
Where do your due dates come from?
A good answer sounds like
Agreed terms per customer or group, applied automatically.
What it tells you
Hand-typed due dates make every overdue figure negotiable.
Which customers should never be on credit?
A good answer sounds like
A cash-only list the till and the invoice both respect.
What it tells you
If the list lives in someone’s head, it leaves when they do.
Credit control in AWRA
Credit limits, holds, segments and payment terms on the same customer record your invoices and collections use.
Read the feature pageFrequently asked questions
Can a salesperson override a credit hold in AWRA OpsHub?
Only a plain over-limit hold, and only with a reason that is recorded. When the workspace credit policy holds a customer, for being overdue past a threshold, being in a cash-only segment or being on a manual hold, the per-invoice override is refused and the hold lifts only through a release request that someone else approves.
Is the credit policy on by default?
No. It is a workspace setting that starts switched off. Until it is switched on, segments, workspace defaults and the overdue thresholds do nothing, and each customer’s own credit limit works as it always has.
How is an overdue amount judged when a customer owes in two currencies?
Per currency. If the overdue balance in any one currency is above the threshold, the customer is held. Balances in different currencies are never added together.
Can the person who asked for a credit release approve it?
No. The person who asked sees the request as waiting for another approver, and only someone else who holds the credit hold approval permission can approve or decline it, with a reason.
Do payment terms set the invoice due date automatically?
Yes. A new invoice, or one converted from a quote or sales order, takes its due date from the customer’s terms, then the segment’s, then the workspace’s. A due date typed on the invoice always wins.
