An Invoice That Has to Be Approved
An invoice here is not created and sent in one act. It is drafted, approved by a named person at a recorded time, confirmed, then sent — and a customer over their credit limit stops it dead at the approval step. For a small-business system, having a lifecycle at all is the unusual part.
Most systems in this bracket treat an invoice as a thing you make and then a thing you send. Ours treats it as a document that passes through states, each of which somebody is responsible for.
That is worth knowing before you buy, because it is friction, and friction is either a control or an annoyance depending entirely on what your business is.
The states
An invoice begins as a draft. It can be approved, which records who approved it and when. It can be confirmed. It can be sent. It can be credited or partially credited when a credit note is applied against it. It can be cancelled from draft, from credit hold, from approved, from confirmed or from sent — and cancelling clears the approval, so a cancelled invoice does not carry a stale approver.
And there is a state nobody chooses: credit hold. A customer whose exposure exceeds their limit lands here, and an invoice in that state cannot be approved and cannot be fulfilled.
The approval is a name and a time on a document. Everything a lifecycle is worth comes down to whether somebody has to put their name on it.
What the gate actually stops
Two things, and they are different in kind.
The first is credit. Exposure is computed across the customer's balance plus every open invoice — not just what is posted, which is the correct and harder definition — and it is evaluated when the invoice is created and again when it is changed. So an invoice edited upward after approval cannot slip through on the strength of the earlier check.
The second is fulfilment. An invoice that has not reached approved or confirmed cannot be acted on downstream. So the sequence is enforced rather than conventional: nothing ships against a draft.
And the decision is preserved. The limit, the exposure before and after, the amount over and the reason are all written onto the invoice, so raising the limit next quarter does not rewrite the history of why this invoice was held.
Why an exporter should want the friction
Because a document sent to a customer three time zones away is expensive to correct. Not difficult — expensive, in elapsed time. A wrong invoice to a local customer is a phone call and a reissue on the same day. A wrong invoice into a distant market is a week, a chased email, and a payment that arrives late because the paperwork went round again.
A draft state exists precisely so that the document somebody checks is not the document the customer has already received. That is the whole value, and it is invisible in a demonstration because in a demonstration nothing is ever wrong.
The credit gate has a second-order value in the same setting. Distance makes collection slow, slow collection inflates exposure, and inflated exposure is exactly what a limit is for. A gate that fires at invoice creation stops the exposure before it exists rather than reporting it afterwards.
Where the lifecycle stops
It is a state machine, not an approval workflow, and the difference is worth being precise about.
| What you might expect | What is here |
|---|---|
| A routed approval to a named approver | A state change performed by whoever has the permission |
| Multiple approval steps by value | One approval state |
| A different approver above a threshold | No value tiering on invoice approval |
| A dedicated permission to release a credit hold | The general invoice-edit permission |
| A record of who approved and when | Yes — stored, and cleared on cancellation |
| A record of why a hold happened | Yes — snapshotted onto the invoice |
The fourth row is the one to act on. Overriding a credit hold sits with the same permission that lets somebody edit an invoice, which in most organisations is a much wider group than the one that should be releasing credit. Until those are separated, keep invoice editing narrow — that is the only lever you have.
What AWRA OpsHub does today
- Named invoice states — draft, credit hold, approved, confirmed, sent, credited, partially credited, cancelled.
- Approval recording who and when, and cleared on cancellation so no stale approver survives.
- Fulfilment refused unless the invoice has reached approved or confirmed.
- Credit exposure computed across the customer balance plus every open invoice, evaluated at creation and again on update.
- A credit hold blocking both approval and fulfilment, with the limit, exposure and reason snapshotted onto the invoice.
- An override requiring a written reason and recording who and when.
What it does not do
- A routed or multi-step approval. Approval is a state change by anyone holding the permission.
- Value-tiered approval on invoices — no different approver above an amount.
- A dedicated permission for releasing a credit hold; it sits with the general invoice-edit grant.
- Payment terms on a customer, so the credit gate controls how much and not how long.
- Any recurring or scheduled invoice, so every document passes through this lifecycle by hand.
Not ours, by choice
- Having a lifecycle at all is the unusual part in this bracket, and the credit-hold snapshot is the strongest detail in it.
- The override permission is a real weakness in an otherwise good control, and it is a role-design constraint rather than something you can configure away.
- Nothing here is Malagasy. It is what a draft state is worth; distance from your customer is what makes a wrong document expensive.
What is not built for the Indian Ocean islands 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 in the Indian Ocean islands. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a national tax pipeline, a local payroll engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Tax pipelines, one country at a time
Electronic invoicing or fiscalisation against your authority's published interface, with retries, a failure queue and a daily report of invoices carrying no reference. Said carefully, because this region has no shared framework to hide behind: Mauritius runs real-time fiscalisation through certified providers, and the other three are unrelated regimes on unrelated timetables. That makes each of these a country build, and in Mauritius specifically an accreditation rather than an integration — which is a different kind of commitment and priced as one.
Bank feeds and genuinely multi-currency operations
Bank statement and card settlement feeds into the Payments Register, across the several currencies an island business actually transacts in. This is the shared condition of the region: almost everything is imported, the freight and the goods are frequently invoiced in different currencies, and the reporting currency is nobody's only working currency.
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.
Payroll and statutory returns
Statutory payroll and social contribution schedules per country, computed on live records and produced in the layout each filing body expects. Four countries here means four engines rather than one, and none of them is built today.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about invoice controls
Can an invoice be sent without being approved?
A good answer sounds like
No, and a demonstration.
What it actually means
A lifecycle that can be skipped is a naming convention. Ask them to try.
Edit an approved invoice upward past the credit limit. What happens?
A good answer sounds like
It is re-evaluated and held.
What it actually means
Checking only at creation is the common shortcut, and it is the hole every credit control has until somebody closes it.
Who can release a credit hold?
A good answer sounds like
A named, narrow permission.
What it actually means
Ours is whoever can edit an invoice. Ask, because this is where a good control usually leaks.
Raise the limit. Does last month's hold still explain itself?
A good answer sounds like
Yes, snapshotted.
What it actually means
A control whose history recomputes is a control you cannot audit.
Decide who approves before you go live
The lifecycle only means something if approval is somebody else's job. Two roles and one narrow permission, agreed in an hour, and the control does the rest.
Design the rolesFrequently asked questions
Can I skip the draft stage for speed?
The states exist and fulfilment requires the invoice to have reached approved or confirmed, so the sequence is enforced rather than optional. If invoicing speed is the constraint, the answer is to narrow who checks rather than to remove the check.
What happens to an invoice on credit hold if the customer pays something?
Exposure is recomputed from the customer balance and open invoices, so a payment reduces it and the invoice can be approved. The snapshot on the held invoice records the position at the time of the hold, which does not change.
Should the same person draft and approve?
Nothing in the product stops it, and in a small team it will happen. The useful discipline is to separate it for anything above a value you choose, and to keep the invoice-edit permission narrow — because that permission currently also releases credit holds.
