The Override That Shares a Permission
Overriding a customer credit hold here needs the permission to edit invoices — the same grant that lets somebody change one. Three modules away, an equivalent override was deliberately given a permission of its own.
A control and an override are two halves of one design. Building the control is the visible work. Deciding who may override it is where the control is actually calibrated, and it is usually decided by whichever permission was nearest.
The control, which is good
Customer credit here is properly built. Exposure is computed across the customer's balance plus every open invoice, not just the one in front of you. It is evaluated when an invoice is created and again when it is changed. A customer over their limit puts the invoice into a credit-hold status that blocks both approval and fulfilment, with explicit refusals rather than a silent failure.
And the evidence is snapshotted onto the invoice itself — the limit, the exposure before and after, the amount over, and the reason — so a later change to the customer's limit cannot rewrite the history of why a hold happened. That is a detail most implementations miss, and it is the difference between an audit trail and a set of current values.
The override records who did it, when, and a written reason. So far, so careful.
And the gate on it
The permission to edit invoices. The same one that permits editing an invoice, approving one, cancelling one and recording a payment against one.
So anybody who can do the ordinary daily work of invoicing can release a customer past their credit limit. There is no separate grant, and therefore no way to give somebody the job without also giving them the override.
The credit hold override
- Needs the permission to edit invoices
- Same grant as approve, cancel, record payment
- Reason recorded, actor recorded
- Cannot be separated from the day job
The supplier payment override
- Needs its own dedicated permission
- Deliberately not the one that approves orders
- Reason recorded, actor recorded
- Pinned to what it authorised, and withdraws itself
The same product answered the same design question twice and gave two different answers, three modules apart.
Why the procurement version is the better one
Two reasons, and both are worth stealing regardless of what software you run.
The first is separation. The override permission is deliberately not the permission that approves purchase orders, so the person who authorises spending and the person who overrides the control on spending can be different people. That is a choice an organisation gets to make, and on the sales side it is not offered.
The second is subtler and it came out of a test rather than a design. The override is pinned to the specific discrepancy it authorised. If the underlying problem changes into a different problem, the authorisation no longer applies. A first version would have kept releasing money after a discrepancy agreed as "short delivery accepted" turned into something else entirely.
A standing override is a permanent hole with a justification attached to it. Pinning it to the facts it was granted for is what stops that.
What to do about the sales side today
-
Accept that the override travels with the job
Anybody doing invoicing can release a hold. Grant the invoicing permission on that basis rather than on the basis of the daily tasks.
-
Use the recorded reasons as the control
The override writes an actor, a time and a written reason to the invoice. Read them, monthly, out loud. A control you cannot enforce in advance becomes a control you review afterwards.
-
Watch overrides on the same customer
One override is a commercial decision. Four on one customer is a credit limit that is wrong, and nothing in the product will point that out.
-
Do not raise the limit to avoid the hold
The snapshot means an override leaves a record and a raised limit does not. Quietly raising limits is how credit control stops existing without anybody deciding to stop it.
What AWRA OpsHub does today
- Exposure computed across the customer's balance plus every open invoice, evaluated on create and on update.
- A credit-hold status blocking both approval and fulfilment, with explicit refusals.
- The limit, exposure before and after, amount over and reason snapshotted onto the invoice, so a later limit change cannot rewrite history.
- An override recording who, when and a written reason before returning the invoice to draft.
- A dedicated override permission on the equivalent procurement control, pinned to what it authorised.
What it does not do
- A separate permission for the credit-hold override — it shares the invoice-editing grant.
- Any pinning of a credit override to the exposure it authorised, so it does not withdraw itself if circumstances change.
- Any report of overrides by user or by customer.
- Any alert on repeated overrides for one customer.
- Any link between credit control and stopping work in progress — the hold stops the invoice, not the delivery of further work.
Not ours, by choice
- The credit service is one of the better-built things in the sales module, and this page is about one line of middleware rather than about the control. The evidence snapshot in particular is a detail we would point at as a model.
- That last not-built item deserves its own thought: a hold stops an invoice and nothing stops the work. A customer on hold can keep consuming your time and materials while nothing is billable.
- Nothing here is Cameroonian, Gabonese, Chadian or Congolese. Central Africa is here because trading on credit over long distances with slow settlement is ordinary, which makes the limit a live operational control rather than a formality.
One permission, and one report
The pattern to copy is already in this codebase, on the procurement side. This is applying a decision that was made once to the place it was not.
A dedicated credit-override permission
Separated from the invoice-editing grant, exactly as the supplier payment override is separated from order approval. Small, and it is the difference between an organisation that can choose who overrides credit control and one that cannot.
An override register
Every credit override, by user, by customer, with the reason and the amount, over a period. The data is already snapshotted onto the invoices — this is a report, not a mechanism, and it turns a set of recorded reasons into something somebody actually reads.
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. If you trade on credit at any scale, the first one is worth asking for.
Talk to us about credit controlOur position
Grant the invoice-editing permission knowing it carries the credit override with it, and put a monthly read of override reasons into somebody's week — that review is the control until a separate permission exists. And treat four overrides on one customer as evidence that the limit is wrong rather than as four decisions.
Four questions about any override
Which permission overrides this control?
A good answer sounds like
A dedicated one.
What it actually means
If it is the same permission as the day job, the control cannot be separated from the work.
Is a reason required, and is it stored?
A good answer sounds like
Yes, with the actor and time.
What it actually means
Ours does this on both sides. It is the minimum, and plenty of systems record only the actor.
Does the override expire when the facts change?
A good answer sounds like
Yes, pinned.
What it actually means
Ours does on the procurement side and not on the sales side. A standing override is a permanent hole.
Can I report on overrides?
A good answer sounds like
Yes, by user and by subject.
What it actually means
Recorded and unreportable is the usual state, and it is ours. The evidence exists; nothing gathers it.
Ask the same question of every control
Who overrides it, is that a separate grant, and does the authorisation survive the facts changing. Three questions, and they separate a control from a formality.
Talk about credit and controlsFrequently asked questions
Does a credit hold stop work as well as invoicing?
No. It blocks approval and fulfilment of the invoice; it does not stop time being logged or material being issued to that customer's work. A customer on hold can keep consuming your resources while nothing is billable, which is worth watching separately.
Can I see why a hold happened after the limit changed?
Yes — the limit, exposure and reason are snapshotted onto the invoice at the moment of the hold, so later changes to the customer's limit cannot rewrite that history. This is the part of the design we would most want copied elsewhere.
Why is the procurement override stricter?
Because it was built later, after somebody counted how many ways a supplier could be paid and found six. That exercise produced a dedicated permission and an override pinned to what it authorised — and the sales side has not had the same pass.
