The Hold Stops the Invoice, Not the Work
A credit limit stops the next invoice going out to a client who has stopped paying. It does not stop your team logging another two hundred hours to them. One of those two is a software control; the other is a conversation nobody wants to have.
The worst receivable a professional firm carries is not the one that goes bad. It is the one that goes bad slowly while the team keeps working, because the effort is real, the cost is real, and by the time somebody adds it up the exposure is twice the invoice everyone was worried about. A firm chasing a two-million-shilling debt has one problem. A firm chasing a two-million-shilling debt while three people bill fifty hours a month into the same client has a different, larger, entirely self-inflicted one.
There is a real control for the first half of this and none at all for the second half, and the gap between them is worth understanding precisely — because the control that exists is good enough to create false confidence.
What the credit limit actually does
Set a credit limit on a client and every new invoice for them is checked against their total exposure before it can proceed. Exposure is not just the invoice in front of you — it is the client's balance plus the balance still due on every open invoice they hold. If adding the new invoice would push that past the limit, the invoice is created with a status of credit hold rather than draft.
What makes this useful rather than decorative is what gets stored on the invoice at that moment:
- The credit limit as it stood — not looked up later, snapshotted then.
- Exposure before the invoice and exposure after it.
- The amount it went over by.
- A reason naming the excess.
Because those are snapshots rather than live lookups, raising the client's limit next month does not quietly rewrite the record of why an invoice was held in March. The held invoice keeps its own account of the decision — the same discipline that makes a rate a fact about a date rather than a fact about a customer.
The hold has teeth. A held invoice cannot be approved and cannot be fulfilled — both paths refuse it with a message telling you to override first. It is not a badge on a screen that everyone learns to ignore.
The override is the good part
You can override a hold, and this is correct — a partner sometimes has information the credit limit does not. But the override demands a written reason, and it records who overrode it and when alongside that reason, then returns the invoice to draft for normal approval. A control you cannot bypass gets disabled within a month; a control you can bypass on the record is one people actually keep.
Two limits on the mechanism, both worth knowing. It only engages where a limit is actually set — a client with no credit limit is never held, so an unmaintained customer list means an inactive control. And overriding a hold uses the same permission as editing an invoice, so whoever can amend an invoice can release a hold. If you want those to be different people, that is a workflow rule you build, not a setting you switch on.
What it does not touch
Nothing in the credit control reaches the timesheet. There is no check on the client's status when an hour is logged, no warning, no flag on the engagement, no reduced permission. A client can be on hold for four months while the team logs billable time into their matters every week, and the only thing that changes is that the resulting hours have nowhere to go.
This is the honest shape of it: the credit limit governs billing, not delivery. And that is not unreasonable as a design — software should not be silently refusing to record work that genuinely happened, and an hour logged to a delinquent client is still a fact about how the firm spent its week. But it means the number that actually matters to a partner — total exposure including unbilled effort — is not a number the system computes, because unbilled time is not carried as a balance anywhere.
Your receivables report shows what you invoiced and they have not paid. It does not show what you delivered and have not yet invoiced, to the same people, since the hold went on.
The number nobody is looking at
Take a mid-sized consultancy with one client that stops paying in week seven. The invoicing control does its job perfectly. The exposure that grows afterwards is invisible to it.
One client, twelve weeks, one hold
The receivables ledger says 2,140,000 and it is correct. The credit limit says the client is 140,000 over and it is correct. Both are answering the question "what have we billed and not been paid?" — and the question the firm needed answered in week eight was "what are we still spending on someone who has stopped paying?" Nothing on the screen was wrong. The number simply was not there.
Note the two figures on the last rows: the billable value is what you hope to recover, the delivery cost is what has already left the firm as salaries. The second is the one that is genuinely gone. Five weeks of an unpaid client cost this firm two hundred thousand shillings of real payroll before anybody raised it in a partners' meeting.
The decision the software will not make for you
Because the stop-work decision cannot be automated here, it has to be a standing rule with a trigger, agreed before you need it. Three defensible positions, and the wrong answer is not having one.
If the client is strategic and the delay is procedural
Keep working, cap the exposure
Set an explicit ceiling on unbilled hours — not on invoices, on hours — and review weekly. This is the common case with government and large-corporate clients where payment is slow rather than doubtful, and it is a legitimate commercial choice as long as somebody owns the ceiling.
If the client has gone quiet on a held invoice
Stop at the current deliverable
Finish what is in progress so nothing is half-done and unbillable, then stop. Half-finished work is the worst possible position — you have spent the cost and have neither a deliverable to invoice nor a clean file to hand over.
If the hold has been overridden more than once
Treat the pattern as the signal
Two overrides on the same client is the system telling you something in writing. Read the reasons that were recorded — they are on the invoices — and decide as a firm rather than invoice by invoice, which is how a limit gets overridden into meaninglessness.
The weekly review that closes the gap
- Every client with a held or overridden invoice in the last quarter, listed by name.
- For each, hours logged since the hold — the number the credit control cannot see.
- That figure valued twice: at the bill rate, for what is at risk, and at the cost rate, for what has already gone.
- Any client with no credit limit set at all, because for them the control has never run.
- Every override reason recorded since the last review, read aloud rather than filed.
The first three of those are now one screen. Credit Hold Exposure, under Reports, lists every client with an invoice on hold or released by override, the hours logged to each of them since, and those hours valued twice — at the bill rate for what is at risk, at the cost rate for what has already gone out. The window per client opens at its earliest held invoice, so the figure answers "since this went wrong", not "this month". The last two on the list are still yours to run: clients with no limit set at all, and the override reasons since the last review. Both are readable from data already captured; neither is a screen.
What AWRA OpsHub does today
- A credit limit per client, checked at invoice creation and at invoice update.
- Exposure computed across the client's balance and every open invoice, not just the document in front of you.
- A credit hold status that genuinely blocks approval and blocks fulfilment, with an explicit refusal message on each path.
- Limit, exposure before, exposure after, amount over and reason all snapshotted onto the invoice, so later changes to the limit do not rewrite the history of a hold.
- An override requiring a written reason, recording who overrode it and when, and returning the invoice to draft rather than straight to approved.
- The same control on the API, not only in the interface.
- Receivables ageing, statements and overdue reminders behind the whole thing.
- A credit hold exposure report listing every client with a held or overridden invoice, the hours logged to each since that hold, and those hours valued at both the bill rate and the cost rate.
More we can add to your workspace
- Credit status connected to time logging, so hours logged against a client on hold raise a warning, a flag or a restriction. The exposure report tells you afterwards today.
- Unbilled time is still not carried as a balance. The exposure report computes it on demand for clients with a hold, so the number is now readable — but no ledger holds work in progress, so it does not appear on the client record, in ageing, or in the accounts.
- A credit hold on the client rather than only on invoices — a "this customer is stopped" state that new documents inherit.
- An effect on quotations or new engagements — you can quote and start work for a client whose invoices are all on hold.
- A separate permission for overriding a hold, so amending and releasing stop sharing one grant.
- A dunning ladder. The overdue reminder is one template on a cadence, not a sequence that escalates in tone or routes to a partner.
- A record on the invoice of when a reminder was last sent, so "have we chased this?" is answerable from the document.
- A promise-to-pay or follow-up date, so a commitment a client made on a call lives in somebody's notes.
- A write-off or realisation tracking against billed value.
The first two used to be one problem — the system knew what you had billed and could not tell you what you had spent. Half of that is now answered: the exposure report tells you, per client, what has gone out since the hold. Intervening is what the middle column adds — refusing the hour, warning the person logging it, and putting the figure on the client record rather than in a report you have to open. So today the control is a reporting control, and a firm that reads "credit limits" as "we are protected" has drawn the wrong conclusion.
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 needsOur take
Put the credit limits in, because the invoicing control is real and the override record is genuinely valuable evidence six months later. Then put the exposure report on somebody's Monday, because a number nobody opens is the same as a number nobody has. What is still a management routine rather than a feature is the decision the report provokes — stop, cap, or carry on — and no software is going to make that one for you.
Find the number this week
Open Credit Hold Exposure under Reports and read the top row: the client you are working hardest for while they are not paying, the hours logged since their hold, and what those hours cost. If your firm has never seen that figure, it is usually larger than the invoice everyone was already worried about.
See invoicing and receivables