The Invoice You Cannot Issue Until the Authority Answers
Real-time fiscalisation moves the tax authority out of the reporting cycle and into the invoicing cycle. It stops being something you report to afterwards and becomes something standing between you and your own document.
Mauritius requires invoices to be fiscalised with the Revenue Authority in real time, through a certified Electronic Billing System, before they are issued to the customer. The obligation began with the largest taxpayers and the stated direction of travel is all VAT-registered persons, with the thresholds lowered in stages.
We are deliberately not printing dates or intermediate thresholds. They are reported inconsistently across sources, they have moved, and your accountant or your billing provider has the current position for your turnover band — which is a five-minute question to somebody who is right about it. What this piece is about is the part that does not change with the timetable: what real-time fiscalisation does to how a business operates.
The change is in the sequence, not the paperwork
Every business already reports sales to a tax authority. The novelty here is not reporting, it is position.
Periodic reporting
- You invoice. The customer gets the document immediately.
- You report afterwards, on a cycle, from records.
- A mistake is corrected in the next return.
- The authority is downstream of your operation.
- If their systems are unavailable on a Tuesday, you do not find out and it does not matter.
Real-time fiscalisation
- You submit. You wait for a response. Then the customer gets the document.
- The reporting is the invoicing — there is no separate step to be late with.
- A mistake is a rejected invoice, in front of a customer who is standing there.
- The authority is in the path.
- If anything in the chain is unavailable, that is your problem in real time.
The tax authority moves from being a body you report to into being a dependency of your sales process. Everything difficult about fiscalisation follows from that one sentence.
Four operational consequences
These are the ones that show up in the first month and that nobody prepares for, because the preparation is usually framed as a compliance project rather than an operations one.
| Consequence | What it means in practice |
|---|---|
| Master data becomes blocking | A customer record missing a required field used to be untidy. Now it stops an invoice. Data quality moves from a housekeeping task to a trading dependency, and the discovery usually happens at a counter with someone waiting |
| You need a failure queue and somebody who owns it | Submissions fail — connectivity, a validation rule, a field, an outage. The question is not whether that happens but whether a failed invoice sits in a visible queue owned by a named person, or becomes an unrecorded sale nobody notices until the month end does not balance |
| Credit notes and corrections get formal | Adjusting an invoice quietly is no longer available. Every correction is its own fiscalised document with its own reference, which is better discipline and more steps — and it changes how your team handles the ordinary case of getting something slightly wrong |
| Reconciliation acquires a third party | Your sales ledger and the authority's records should agree. When they do not, the difference is not a bookkeeping question, it is a question about which submissions succeeded — so you need to be able to see, per invoice, whether a validation reference came back |
What to ask a provider
Certification is the entry ticket rather than the answer. Every certified provider can submit an invoice on a good day. The differences are all in the bad day, and these five questions are where they show up.
- When a submission fails, where does the invoice go, who is told, and what does the person at the counter see?
- Is the validation reference stored on the transaction, so you can prove per-invoice that it was accepted — or only in a log?
- Can you get a list of today's sales carrying no reference, without asking anybody?
- What happens during an outage on your side? Is there a queue that drains, or does trading stop?
- When a rule changes, who changes it and how do you find out — is it a provider update you receive, or a configuration you maintain?
A provider who answers those five specifically is telling you they have operated this in anger. A provider who answers by repeating that they are certified is telling you something too.
The sequencing advice, which cuts against our own interest
If you are in scope now or expect to be, choose your billing and fiscalisation first and fit everything else around it. Not the other way round.
The reason is asymmetry. Fiscalisation sits in the path of your revenue and requires an accreditation that a general operations vendor either holds or does not. Everything else — procurement, stock, landed cost, projects, payables, the records questions this corpus mostly writes about — can be adopted later without disturbing your billing. Reverse the order and you can find yourself with an operations platform you like and a fiscalisation route you have to bolt on, and the bolt-on is in the revenue path.
Where we stand, so this is not read as an argument for us
We are not a certified Electronic Billing System in Mauritius and we hold no connection to the Revenue Authority. That is why this piece is advice to go and buy something from somebody else first. If the sequencing above means you evaluate us second or not at all, that is the correct outcome of correct advice, and we would rather publish it than have a customer discover the gap after signing.
What is genuinely adjacent
Fiscalisation puts a gate on the invoice. It does nothing about what happens before the invoice exists, which is where most operational cost actually is: the order, the stock, the price, the approval, the delivery. Nor does it help with anything on the buying side, which fiscalisation does not touch at all.
The fiscalisation connection itself
Not built. This requires becoming a certified Electronic Billing System, which is an accreditation rather than an integration — a different kind of commitment from wiring up an API, and one we do not currently hold. Choose your EBS independently of us.
Statutory returns and filing
Not built. No VAT return preparation, no submission, no advice on your obligations or your turnover band. We hold the transaction detail a return is built from; the return stays with your accountant.
Everything upstream of the invoice
The order, the stock reservation, the approved price, the delivery, the receipt. Fiscalisation validates a document; it has no opinion about whether the document reflects what your operation actually did. That gap is where the ordinary work is.
The whole buying side
Purchase orders, receiving, three-way matching, landed cost, supplier balances and payments. Fiscalisation is about invoices you issue and touches none of this, which is worth remembering when a fiscalisation project starts describing itself as a systems project.
Master data quality as a discipline
Customer and item records with the fields your billing needs actually present, maintained in one place rather than per-document. Configuration and habit rather than a feature, and the cheapest preparation available for a regime that makes bad data blocking.
One thing to do before the threshold reaches you
Fix your master data. It is unglamorous, it is free, and it is the single thing that determines whether your first month of fiscalisation is uneventful or a series of small crises at the counter.
Under periodic reporting, a customer record with a missing field is a tidiness problem you will get to. Under real-time fiscalisation it is a sale that cannot be completed. Nothing about that requires software you do not have, and it is worth doing while it is still a chore rather than an incident.
What is not built for Mauritius 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 Mauritius. 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 certified EBS fiscalisation connection, a Mauritian payroll engine, a bank or mobile money feed, a statutory return format 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.
Real-time fiscalisation, through certification we do not hold
Invoice fiscalisation against the Revenue Authority in real time — structured invoices, a validation response held on the transaction, retries, a failure queue and a daily report of invoices carrying no reference. Stated precisely, because precision is the whole value of saying it here: this requires becoming a certified Electronic Billing System, which is an accreditation rather than an integration. We are not certified and hold no connection today. If you are in scope, choose your EBS first and fit everything else around it.
Banks, cards and genuinely multi-currency settlement
Bank statement feeds and card acquirer settlement into the Payments Register, across the several currencies a Mauritian entity actually operates in rather than one reporting currency with conversions bolted on. There is no exchange control to work around here, which makes this the ordinary version of a problem that is difficult almost everywhere else on the continent.
Payroll and statutory returns
PAYE, National Pensions Fund and National Savings Fund contributions and the associated returns, computed on live records and produced in the layout each body expects. Not built today — our maintained engine covers Kenya only, and the local providers here are good.
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 integrated