Two Mandates in One Law
Nigeria's e-invoicing mandate asks for two different things in one sentence. A business-to-business invoice is cleared before it reaches the buyer. A till receipt is reported after it is issued. Those are not two settings on one feature — they are two machines, and only one of them can stand in front of a queue.
There is a sentence in almost every summary of Nigeria's e-invoicing mandate that reads as one requirement and is actually two. Business-to-business and business-to-government invoices are submitted for clearance before they are provided to the buyer. Business-to-consumer transactions are reported. If you run a shop, the second half of that sentence is the whole of your problem, and it is a different engineering problem from the first.
One more thing to get out of the way before anything else, because it is the sort of detail that makes a document look old: the authority is no longer the Federal Inland Revenue Service. The Nigeria Revenue Service (Establishment) Act 2025 rebranded it, and the transition took effect from 1 January 2026. Anything you read that says FIRS was probably written before that and may be describing an older state of the rules as well.
The schedule, and the caveat printed next to it
The national platform is the Merchant Buyer Solution. It went live on 1 August 2025 for large taxpayers, with effective implementation extended to 1 November 2025, and the rollout is banded by turnover.
| Band | Annual turnover | Announced go-live |
|---|---|---|
| Large | ₦5 billion or more | 1 November 2025 |
| Medium | ₦1 billion to ₦5 billion | 1 July 2026 |
| Emerging | Under ₦1 billion | 1 July 2027 |
The scope is broad: VAT-registered suppliers, domestic and foreign, across business-to-business, business-to-government and business-to-consumer. So a retailer is in it, and a retailer's problem is the third of those.
Why clearance and reporting are different machines
Clearance is synchronous by definition. The document has to be validated by the authority before it goes to the buyer, which means the act of issuing an invoice contains a network round trip to somebody else's system, and the invoice does not exist until that returns. For an accounts department issuing forty invoices a month, that is entirely workable — a person clicks, waits a moment, and the document is stamped.
Now put the same mechanism in front of a till on a Saturday afternoon. A queue of eleven people, a card terminal, a customer who wants their receipt, and a validation call to a national platform standing between the payment and the paper. Every second of latency is a second of queue. Every outage is a shop that has stopped trading. This is why B2C is reported rather than cleared in essentially every regime that has thought about it — not as a concession, but because the alternative does not survive contact with a shop.
What clearance needs
- A synchronous call the document waits on
- A user who can tolerate a pause
- A clear failure state before anything is issued
- Retry that a person supervises
- Roughly the shape of a desktop accounting screen
What till reporting needs
- A sale that completes whether or not the network does
- Transmission on a queue behind the counter
- Automatic retries, then a visible failed state
- A way to rescue a stranded sale from the shop floor
- Reversals that transmit too, on the same machinery
The question to ask a vendor is not whether they support the mandate. It is what happens at the till when the platform is unreachable, and who fixes the sale that failed.
What we learned building the equivalent for Kenya
We should be plain about our position first: the fiscal pipeline that ships as standard in this product is Kenya's eTIMS. Nigerian transmission is build-to-requirement work rather than a stock feature, which is set out in full and without softening in our Nigeria VAT and operations piece. What we do have is several years of running a real one, and almost everything difficult about it turned out to be about tills rather than about the protocol.
-
The sale completes first, always
A finished till sale hands the transmission to a background queue rather than performing it in front of the customer. This is the single decision everything else depends on, and it is the one that is hard to retrofit: a design that files synchronously cannot be made asynchronous by adding a timeout, because the receipt has already been printed by then.
-
Automatic retries, then an honest failure
The auto-file hook gives up after three attempts and the sale goes to a visible failed state rather than sitting in a hopeful loop. A silent perpetual retry is worse than a failure, because nobody ever looks at it.
-
A sweep on the hour, not overnight
Failed filings are swept hourly rather than nightly, and the reason is written in the scheduler beside it: an outage during trading strands every sale it touches, and the useful window to recover them is the same day rather than the next morning. Nightly is the intuitive choice and it is wrong for a shop.
-
The rescue has to work from the shop floor
Manually re-filing a stranded sale is available on the phone as well as the desktop. Until that existed, a till that had failed could only be rescued by somebody at a computer — which in practice meant end of day, which in practice meant the next day.
-
Reversals are the half everybody forgets
A refund owes the authority a document too, and it is raised at the moment the shop is busiest and least able to deal with a failure. The reversal sweep runs on the same hourly cadence and also picks up reversals that were never sent at all because the connector was down when they were raised — that last clause is the one that took a production incident to learn.
The two questions worth putting to any vendor, including us
First: at the till, does the sale complete when the platform is unreachable? If the answer involves the word "usually", the design is synchronous and the shop stops when the network does. Second: who finds the sale that failed, and where do they stand while they fix it? A failed-filing report that only exists on a desktop is a report nobody reads until the accountant does, which is a fortnight later and a fortnight too late. Neither question is about Nigeria specifically, and both of them separate the vendors who have run one of these from the vendors who have read about them.
What to do now, by band
The practical position depends entirely on which band you are in, and the useful thing about a turnover-banded rollout is that it gives smaller businesses something rare in tax administration: time, and other people's experience.
- Establish which band your turnover puts you in, and treat the announced date as a planning assumption rather than a fixed one. It is published as a guideline and one of the dates has already moved.
- Separate your B2B document flow from your B2C flow on paper before you buy anything. They are two requirements and a vendor answering only one of them will answer whichever one they have built.
- If you are in the emerging band, spend the time watching. The businesses ahead of you are discovering the operational edges — outages, reversals, corrections — and none of that is in any specification.
- Ask what happens to a sale made while the platform is down, and get the answer as a description of behaviour rather than as a reassurance.
- Confirm the current position with the authority or your tax adviser. This is a product blog and the rules move; nothing here is a reading of your obligations.
What AWRA OpsHub does today
- A fiscal pipeline that runs in production, filing completed till sales to Kenya's eTIMS on a background queue so a sale finishes whether or not the authority is reachable.
- Automatic retries with an honest failure state, an hourly sweep of stranded filings, and a manual re-file available on the phone as well as the desktop.
- Reversals transmitted on the same machinery, including ones that were never sent because the connector was down when they were raised.
- Sales, VAT and customer records kept in the shape a fiscal pipeline needs — per-line tax held on the document, so what was charged stays true whatever changes later.
More we can add to your workspace
- Transmission to the Nigeria Revenue Service's Merchant Buyer Solution. Kenya's eTIMS is the pipeline that ships as standard, and a Nigerian one is scoped and built the same way that one was, against the authority's published interface.
- A pre-clearance flow for business-to-business documents, where an invoice is validated before it is provided to the buyer rather than transmitted after issue.
- A single connector abstraction across fiscal authorities, so a second market is configuration rather than a build.
Where we point you to a specialist
- We will not tell you whether you are in scope, or from what date. That turns on your turnover and on a reading of the rules as they stand when you ask, and it belongs to your tax adviser rather than to a vendor with something to sell you.
- We will not describe a pipeline we have built for one country as coverage of another. The eTIMS integration exists because Kenyan clients needed it and paid for it; saying it makes us ready for Nigeria would be the exact claim this article is asking you to test.
The first and second lines are different builds rather than one, which is the point of the whole article: clearance in front of a document and reporting behind a till are separate machines, and a vendor who has one has not got the other.
What we can build for Nigeria on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Nigeria, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If FIRS e-invoicing, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have 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.
FIRS e-invoicing and tax pipelines
Invoice transmission against the authority's published interface, plus WHT credit handling and sector levies — with the parts vendors gloss over: retries, a failure queue and a daily report of sales carrying no fiscal reference.
Banks, cards and transfers
Bank statement feeds, card acquirer settlements and bulk-payment files pulled into the Payments Register, so money in and out reconciles without anyone re-keying a statement.
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
PAYE, pension and NHF schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt in a spreadsheet each month.
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 integratedFive questions, and none of them mention a specification
At the till, does the sale complete when the platform is unreachable?
What you will hear
"Yes", or a pause and then "usually".
How to read it
The pause is the answer. Synchronous filing turns a network outage into a closed shop, and no amount of configuration converts a synchronous design into an asynchronous one after the fact.
How many times does it retry, and what does it do then?
What you will hear
A number, or an assurance that it keeps trying.
How to read it
Keeps trying forever is worse than fails visibly, because nobody inspects a queue that never complains. Ask to be shown the screen where a failed filing appears.
Who fixes a stranded sale, and where are they standing?
What you will hear
"The accountant."
How to read it
Then it is fixed at month end. A rescue that works from the counter is fixed the same hour, which matters because the record you are correcting is a fiscal one.
What happens to a refund when the connector is down?
What you will hear
Often silence.
How to read it
Refunds are the half that gets forgotten, and they are raised when the shop is busiest. A reversal that was never sent at all is a different failure from one that was sent and rejected, and a system needs to sweep for both.
Have you done this for another authority, and what broke?
What you will hear
Either a story or a brochure.
How to read it
The story is the qualification. Every one of the operational edges in this article came from running a pipeline rather than from reading a specification, and a vendor who cannot name one has not hit any of them yet.
Our take
Read the mandate as two requirements, because it is two. The business-to-business half is a clearance problem and it looks like an accounting screen; the consumer half is a queue problem and it looks like a shop. Work out which band your turnover puts you in, treat the published date as a guideline because that is how it is published, and if you are in the emerging band use the time to watch what breaks for the businesses ahead of you. When you evaluate anything, ask what happens at the till during an outage and who rescues the sale afterwards. Those two questions cost nothing, they are answerable in a demo, and between them they separate the systems that have run a fiscal pipeline from the ones that have described one.
See how a fiscal pipeline is actually wired
Till sales filed on a background queue, automatic retries with a visible failure state, an hourly recovery sweep, reversals on the same machinery, and a manual re-file that works from the counter.
Explore point of saleFrequently asked questions
Is it still FIRS?
No — the Nigeria Revenue Service (Establishment) Act 2025 rebranded the Federal Inland Revenue Service as the Nigeria Revenue Service, and the transition took effect from 1 January 2026. It is worth knowing as a dating signal as much as anything: material that says FIRS was generally written before that point, and may be describing an earlier state of the e-invoicing rules too.
When does the mandate apply to my business?
It is banded by turnover. The announced go-live dates are 1 November 2025 for large taxpayers at ₦5 billion or more, 1 July 2026 for medium taxpayers between ₦1 billion and ₦5 billion, and 1 July 2027 for emerging taxpayers under ₦1 billion. Those dates are published as guidelines subject to change on operational readiness and stakeholder feedback, and the large-taxpayer date has already moved once. Establish your band, plan against it, and confirm the date with the authority or your adviser rather than with a vendor.
What is the difference between clearance and reporting here?
Business-to-business and business-to-government invoices are submitted for clearance before being provided to the buyer, so the document does not exist until the authority has validated it. Business-to-consumer transactions are reported rather than cleared. The distinction is not administrative — clearance is a synchronous call the document waits on, which is fine in an accounts department and unworkable in front of a queue. Confirm the current timing rules for consumer reporting against the authority's own guidance, since that detail moves.
Does AWRA OpsHub transmit to the Merchant Buyer Solution?
Not as a shipped feature. The fiscal pipeline that ships as standard is Kenya's eTIMS, and Nigerian transmission is build-to-requirement work scoped against the authority's published interface — the same way eTIMS was built, because Kenyan clients needed it and paid for it to exist. We would rather say that plainly than let a demo imply otherwise. What does transfer is the operational design: a sale that completes on a queue, retries with a visible failure state, an hourly recovery sweep, reversals on the same machinery, and a re-file that works from the shop floor.
Why does asynchronous filing matter so much at a till?
Because a shop cannot wait. If issuing a receipt contains a call to a national platform, then platform latency is queue length and a platform outage is a closed shop — and the failure arrives on a Saturday afternoon rather than during office hours. Filing on a background queue means the sale completes, the customer leaves, and the transmission is a separate concern with its own retries and its own visible failure state. It is also the decision that is hardest to change later, since a synchronous design has already printed the receipt by the time it decides to give up.
