Terms That Live on the Document
A customer here has a credit limit and no payment terms. The limit is enforced properly — exposure computed across every open invoice, a real hold, the numbers snapshotted so history cannot be rewritten. How long they may take to pay is typed onto each invoice, one at a time.
Credit has two dimensions. How much, and how long. Almost every discussion of credit control is about the first, and almost every cash-flow problem is caused by the second.
Our product models the first carefully and does not model the second at all.
How much: properly built
A customer carries a credit limit. Exposure against it is computed across their balance plus every open invoice, which is the correct definition and not the easy one — a limit checked only against a posted balance ignores everything invoiced and not yet due, which is usually most of the risk.
The check runs when an invoice is created and again when it is changed, so an invoice edited upward cannot slip past a limit it originally passed. A customer on hold has invoices blocked at both approval and fulfilment, with explicit refusals rather than silent failures.
And the detail that makes it auditable: the limit, the exposure before, the exposure after, the amount over and the reason are all snapshotted onto the invoice. Raise the limit next quarter and the record of why that invoice was held does not change. An override requires a written reason and records who and when before returning the invoice to draft.
A control whose history can be rewritten by a later settings change is not a control. This one cannot be, and somebody thought about that deliberately.
How long: not modelled
There is no payment terms field on a customer. Not thirty days, not end of month, not anything.
An invoice has a due date and a free-text terms note, both entered per document. So the terms you agreed with a customer are re-stated, by hand, on every invoice you send them — and the correctness of that depends on whoever raises the invoice knowing what was agreed.
Four consequences follow, and they are all quiet.
- The due date can be wrong without being detectably wrong. Nothing compares it to an agreed term, because no agreed term is stored.
- Terms drift. A customer negotiated to thirty days is invoiced at sixty by somebody who did not know, and the ageing report faithfully reports them as current.
- You cannot report on terms. Which customers are on what, how much of your receivables sits on long terms, how the mix has changed — none of it is answerable, because there is nothing to group by.
- A term change is retail. Moving a customer from sixty days to thirty means telling everybody who raises invoices, and then hoping.
Why the two halves are not interchangeable
It is tempting to think a limit covers you. It does not, and the reason is arithmetic.
The same customer, the same limit, two term structures
The figures are illustrative. The mechanism is not: a credit limit is a stock measure and payment terms are a flow measure, and controlling only the stock means you find out about the flow after it has already accumulated.
Why an Italian seller feels this specifically
Because business-to-business terms here are genuinely long and genuinely varied, and both facts are commercial reality rather than indiscipline. A customer on ninety days is not a bad customer; they are a customer whose terms you agreed to and priced for.
Which makes the missing field more consequential, not less. Where all your customers are on the same terms, a per-invoice due date is a formality — everybody knows the number. Where terms genuinely vary between customers, the number lives in a relationship rather than a record, and the person raising the invoice is often not the person who agreed it.
Add a second-order problem: with no stored terms, an ageing report tells you an invoice is thirty days old and cannot tell you whether it is late. Those are different facts and only one of them is actionable.
Four questions about credit and terms
Where are this customer's payment terms stored?
A good answer sounds like
A field on the customer that defaults onto invoices.
What it actually means
Ours has none. A due date on an invoice is a fact about that invoice, not an agreement.
Does the credit check include invoices not yet due?
A good answer sounds like
Yes — exposure, not balance.
What it actually means
This is the difference between a real credit control and a posted-balance check. Ours does it correctly.
If I raise a limit today, does last month's hold still show why it happened?
A good answer sounds like
Yes, snapshotted.
What it actually means
Most systems recompute, which means the audit trail of a credit decision quietly rewrites itself.
Show me receivables split by payment terms.
A good answer sounds like
A report.
What it actually means
Not answerable here. It is the single most useful receivables view and it needs terms to be stored somewhere.
What AWRA OpsHub does today
- A credit limit per customer, with exposure computed across the balance plus every open invoice.
- The check evaluated at invoice creation and again on update, so an edited invoice cannot slip past.
- A credit-hold status blocking both approval and fulfilment, with explicit refusals.
- The limit, exposure before, exposure after, amount over and reason snapshotted onto the invoice so a later change cannot rewrite the decision.
- An override requiring a written reason and recording who and when.
- A due date and a free-text terms note on every invoice, and ageing reporting on receivables.
What it does not do
- Any payment terms field on a customer. There is no standing agreement to default from.
- Automatic calculation of a due date from agreed terms.
- Any report grouping receivables by terms.
- Days sales outstanding, or a cash conversion cycle.
- A separate permission for overriding a credit hold — it sits with the general invoice edit grant.
Not ours, by choice
- The credit limit implementation is one of the better things in the product and we would put the snapshotting in particular against anybody's.
- The override permission sharing the invoice-edit grant is a real weakness in an otherwise strong control, and it is worth knowing when you design roles.
- Nothing here is Italian. It is the difference between a stock control and a flow control, and long varied terms are simply where the flow matters most.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — 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 the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — 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 rather than calling it a gap. 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 gaps, which are the ones this blog admits 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 position
Trust the limit — it is properly built, properly evaluated and properly recorded. Do not expect the system to know your terms: store them somewhere your invoicing team will actually look, and check a sample of due dates against them monthly. And when you design roles, notice that overriding a credit hold sits with the ordinary invoice-edit permission, which is almost certainly wider than you want.
Separate the two questions in your own policy
How much, and how long. Write both down per customer, put the limit in the system where it is enforced, and put the terms somewhere your invoicing team reads. We will help you set the limits from real exposure history.
Set the limitsFrequently asked questions
Can I hold payment terms in a custom field?
You can store the number, and no due date will be calculated from it. Its value is as documentation your invoicing team can see on the customer record, which is genuinely better than terms living in an email thread.
Does the ageing report know whether an invoice is overdue?
It ages against the due date on the invoice, so it is accurate about that date. What it cannot tell you is whether the date itself was right — an invoice given sixty days when the customer was agreed thirty ages as current for two months.
Who should be able to override a credit hold?
Fewer people than can currently do it. The override sits with the general invoice-edit permission rather than a dedicated one, so anybody who can edit an invoice can release a hold. Until that is separated, treat it as a role-design constraint: keep invoice editing narrow.
