The Limit With No Currency On It
A customer credit limit of 500,000 is a control that genuinely fires: over the line, the invoice goes on hold and somebody has to lift it. What the number never says is 500,000 of what — and the exposure it is weighed against is a sum of invoices that each carry a currency of their own.
Open a customer record and there is a field called credit limit. Put 500,000 in it. The control is real — raise an invoice that takes the customer past the line and it is created on hold rather than approved, with the limit, the exposure before, the exposure after and the amount over all frozen onto the document. That is more than most systems do. Now answer the only question the field does not ask you: 500,000 of what?
It is a fair question and it has a slightly uncomfortable answer, which is that the number has no currency on it. Not a hidden one, not an implied one — the field is a quantity and nothing else. For most businesses that is completely fine, because every invoice they will ever raise is in the same currency and a unit everybody shares does not need writing down. For the businesses this post is about, it is the difference between a control and a coin toss.
What the check actually adds up
The arithmetic is short enough to state in full, which is the useful thing about it. When an invoice is created or edited, three figures are put together and compared to the limit.
| Component | Where it comes from | What currency it is in |
|---|---|---|
| Opening balance | A running balance on the customer record | A quantity, with no currency attached to it |
| Open invoice exposure | The sum of every unpaid invoice for that customer | Each invoice carries its own — the sum does not |
| This invoice | The total of the document being raised right now | Whatever this document is denominated in |
| The limit | The number on the customer record | A quantity, with no currency attached to it |
So a customer with one open invoice for 4,000 in a hard currency and another for 400,000 in a soft one has, as far as the credit check is concerned, an exposure of 404,000. Not because anybody chose a rate — because nothing in that line of arithmetic ever asked what the numbers were.
This is not a conversion done at the wrong rate. It is an addition performed without a conversion, which is the failure mode that leaves no wrong rate behind for anybody to find.
It fails in both directions, and only one of them is loud
The two outcomes are not symmetrical in how you find out about them, which is what makes this worth an article rather than a footnote.
-
The hold that should not have happened
A large-numbered currency inflates the exposure against a limit set in a small-numbered one. The invoice lands on hold, somebody in sales is annoyed, somebody with the right permission lifts it, and the whole thing is resolved inside an hour. Irritating, visible, self-correcting.
-
The hold that should have happened and did not
The other direction. Exposure that ought to be counted large is counted small, the invoice sails through as approved, and nothing at all happens — no message, no queue, no annoyed colleague. The control did exactly what a working control looks like from the outside. This is the one that costs money, and it is silent by construction.
-
The number nobody re-reads
Between the two sits the ordinary case: the limit was typed once, by somebody who had a currency clearly in mind, and has not been looked at since. Nothing on the screen records what they were thinking, so the next person to read it supplies their own assumption.
The workaround, and it is a good one
There is a version of this that works today and needs no code from anybody: one customer record per currency you trade with them in. Acme Ltd (USD) and Acme Ltd (KES), each with its own limit denominated in the currency of the invoices that will be raised against it.
It is not elegant. It splits a statement, it splits an ageing report, and somebody has to remember which record to raise against. What it buys is that every credit decision is then made on figures that are actually comparable, which is the only property that matters in a control. Most businesses that sell across two currencies are already running the customer as two commercial relationships in every way except the database, so the split is often closer to the truth than the merge was.
What we do, and what to configure around it
Our credit limit is a quantity, our customer balance is a quantity, and our exposure figure is a sum over open invoice balances with no currency clause in it. Every invoice does carry its own currency code, and the limit, the exposure and the amount over are all frozen onto the document at the moment of the check — so a hold can always be explained after the fact. If you trade with one customer in more than one currency, use a record per currency until we hold the limit as an amount rather than a number. Separately: who may lift a hold is a permissions question and is not the same conversation, and if you want the wider picture of what the limit measures and when it fires, that is covered here.
The opposite problem, for contrast
It is worth putting this next to a limit that has the reverse defect, because seeing both makes the shape obvious. Several legal systems express statutory ceilings in an inflation-indexed unit rather than in currency, so the limit has a unit and the unit is revalued — once a year in one country and once a day in another. There the number is correct on the day it is entered and drifts afterwards.
Here it is the mirror image: the number never drifts and never needed to, because it was never anchored to anything. One limit means something that changes. The other means whatever the reader assumes. Between them they cover most of the ways a stored threshold stops being a control while continuing to look like one.
Three questions for any system holding a credit limit
Is the credit limit stored with a currency, or as a bare number?
What you will hear
Often a pause, then "it is in our base currency".
How to read it
A pause is an honest answer and it tells you the field is a number. What matters next is whether the exposure it is compared against is also base currency — because if invoices are raised in other currencies, those two statements cannot both be true.
Show me a customer with open invoices in two currencies. What is their exposure?
What you will hear
A single figure, produced quickly.
How to read it
Ask what unit that figure is in. If the answer is a rate and a date, the system is converting and you should ask which rate. If the answer is a shrug, it is adding.
When the hold fired, what was recorded about why?
What you will hear
Sometimes a status, sometimes nothing.
How to read it
A hold that records the limit, the exposure before and after, and the amount over is one you can audit six months later. A hold that records only that it happened leaves you re-deriving the decision from data that has since changed. Ours records the four figures; ask whether theirs does.
What AWRA OpsHub does today
- A credit limit that actually refuses. Past the line an invoice is created on hold rather than approved, and it takes a deliberate act by somebody with the permission to clear it.
- The decision frozen onto the document — the limit, the exposure before, the exposure after and the amount over — so a hold from six months ago can still be explained.
- A currency code on every invoice, so each document is unambiguous about what it is denominated in whatever else is going on around it.
- An override that is recorded, with the person, the moment and the reason kept against the invoice it applied to.
More we can add to your workspace
- A credit limit held as an amount rather than a number, so the field itself says which currency it is expressed in.
- Exposure scoped to a single currency, so a customer trading in two has two limits and two answers rather than one blended figure.
- Conversion at a stated rate inside the credit check, with the rate and its date kept on the hold alongside the four figures already frozen there.
- A warning at the point a customer is given invoices in a second currency, flagging that the limit on the record was set against a different one.
Where we point you to a specialist
- We will not pick the rate a credit decision should be made on. Spot, contractual, month-average and hedged rates all have defensible cases and choosing between them is a treasury policy, which belongs to you and your adviser.
- We will not advise on what a credit limit for a given customer should be. That is a commercial judgement about a relationship we are not part of.
The first and second lines are one change rather than two, and the second is the half that does the work: a limit with a currency written on it is only useful once the exposure it is compared against is measured in the same one.
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 needsSee how invoicing and credit control fit together
Credit limits with holds and recorded overrides, per-invoice currency, and the decision frozen onto the document at the moment it is made.
Explore invoicingFrequently asked questions
What currency is the credit limit in?
Whichever one you had in mind when you typed it — the field stores a quantity and nothing records the unit. In a business that invoices in one currency this is invisible and harmless. In one that invoices in two, the limit means whatever the next person to read it assumes, and the exposure figure it is compared against is a sum of invoice balances in mixed currencies. Until the limit is held as an amount, the workable pattern is one customer record per currency.
Does the exposure calculation convert between currencies?
No conversion happens. The figure is a sum over the balances of open invoices for that customer, filtered by status rather than by currency, added to the running balance on the customer record. Each invoice knows its own currency; the addition does not consult it. That is why the failure leaves no wrong exchange rate behind for anyone to find later — there was never a rate involved.
Why is one customer record per currency the recommended workaround?
Because it makes every figure in the credit check comparable, which is the one property a control needs. The cost is real: a split statement, a split ageing report, and somebody remembering which record to raise against. The consolation is that most businesses selling across two currencies already treat the customer as two commercial relationships in terms, pricing and payment behaviour, so the split usually describes the situation more accurately than the merged record did.
Which direction of the error should worry me more?
The quiet one. An exposure inflated by a large-numbered currency produces a hold that should not have happened — annoying, immediately visible and cleared in an hour. An exposure understated produces an invoice that is approved when it should have been stopped, and nothing at all happens: no message, no queue, no complaint. From outside it is indistinguishable from a control working correctly, which is exactly why it is the expensive one.
Can we see why a particular invoice was held?
Yes, and this part is solid. At the moment of the check the limit, the exposure before, the exposure after and the amount over are all written onto the invoice, so the decision does not have to be reconstructed later from data that has moved on. If an override was applied, the person, the time and the reason are recorded against the same document. What the record does not carry is a currency for those four figures, which is the subject of this post.
