Nigeria E-Invoicing Mandate 2026: Scope, Timeline & Rules

Nigeria's e-invoicing mandate runs on a central clearance platform, not on an invoice network. A supplier in scope submits each invoice to the tax authority's platform over HTTPS, the platform validates and signs it, and only then does the document have a cleared invoice reference number and a QR signature. This article covers who has to use it, what the authority has actually dated, what a compliant invoice contains, and what to do now — taken from the authority's own developer documentation and from our own integration testing against its sandbox.

Is e-invoicing mandatory in Nigeria?

Yes for taxpayers the authority has brought into scope, on a phased rollout. The platform is live, it handles business-to-business, business-to-government and business-to-consumer invoices, and a cleared invoice is the only kind that counts. Which taxpayers, and from which date, is set by the authority's rollout notices.

That last sentence is doing real work, so it is worth being explicit about what this page will and will not tell you. Nigeria's phase dates have been restated and revised in secondary coverage more than once, and a cohort date repeated from a summary is the commonest way a readiness plan ends up budgeting for the wrong quarter. This page previously carried a table of cohort dates by taxpayer size. That table has been removed because we could not trace those dates to the authority, and they are not repeated here even to be disowned — a date in print gets quoted whatever the sentence around it says. Everything below is either in the authority's published developer documentation or in our own test logs against its sandbox, and it is cited as such.

Two places give you your own answer: the notices the authority publishes, and any message addressed to your own taxpayer identification number inside the e-invoicing portal. Neither is something a blog can read on your behalf.

Which system are you actually being asked to connect to?

A central clearance platform operated by the tax authority — the Merchant-Buyer Solution, documented by the Nigeria Revenue Service at einvoice.nrs.gov.ng and still exchanging over the host api.firsmbs.com. Both the FIRS and NRS names are in use for the same thing, and nothing about the integration changes with the name.

It is a continuous transaction control regime: the tax authority sits in the path of the invoice rather than reading a report afterwards. Three consequences follow, and they shape the whole project.

• The platform is authoritative, not advisory. An invoice that has not passed validation and signing has no cleared identity. There is no "send now, fix later" path.
• Your software talks to one central place, over ordinary HTTPS with two headers — an API key and an API secret, issued per registered application from the service-provider dashboard. There is no certificate-based transport layer to stand up and no directory in which to look the buyer up.
• The platform publishes the code lists it validates against. Units of measure, currencies, countries, tax categories, payment means, service codes, Nigerian states, local government areas and invoice type codes are all served as ordinary read endpoints. Pull them; do not hard-code them.

The mechanics of each call are set out in our companion article, FIRS e-invoicing Nigeria: the Merchant-Buyer Solution explained. The step-by-step build order is in the Nigeria e-invoicing onboarding runbook. Our Nigeria e-invoicing page covers what we operate locally.

Is Nigeria's mandate built on Peppol?

No. Nigeria runs a central clearance model, not a Peppol four-corner exchange. There is no AS4 transport, no SMP lookup and no Peppol participant identifier anywhere in the flow. The platform's "Access Point Provider" role is a Nigerian role defined by the tax authority, and it is not a Peppol Access Point.

This is the most expensive misunderstanding in Nigerian e-invoicing projects, and the shared job title is what causes it. Side by side:

Two practical consequences. First, if your procurement paper asks for "a Peppol access point for Nigeria", it is asking for the wrong product: what you need is your own registration on the Nigerian platform, or a provider registered on it. Second, an architecture document or compliance statement that describes Nigeria in Peppol terms — corners, AS4, SMP lookup, participant identifiers — is describing a different country's system, and a reviewer who knows the platform will say so.

If you want the four-corner model itself explained, we cover it in Peppol vs PINT. The closest comparable to Nigeria among the regimes we work in daily is not a Peppol country at all: it is Saudi Arabia, described in our ZATCA e-invoicing guide. The wider country-by-country picture is in the e-invoicing mandates 2026 tracker.

What has the authority actually dated?

The rollout notices set your go-live. The documented changes to the platform are dated, published by the authority, and they are the timeline you can plan a release calendar against. As read at documentation version 1.1 in May and June 2026:

Two things follow from that table that matter more than any single row.

The schema moves, and it moves in public. The authority's stated policy is a three-month grace window before a breaking change is enforced. That window is only useful to a team that is reading the changelog, so put someone's name against it and put the grace period in your release calendar.

Cross-border is the open item. If your Nigerian entity issues export invoices, the schema for that case was still described as being prepared in April 2026. Track it; do not design around a guess.

Who is in scope, and how do you find out?

Scope comes from the notices. What the documentation establishes is the shape of the population the platform is built to serve, and that is useful for working out whether a rule will land on you.

• All three invoice kinds are live in the schema. invoice_kind accepts B2B, B2G and B2C, so consumer retail is in the design, not an afterthought.
• Consumer receipts carry a QR code. The QR requirement is specific to the business-to-consumer case, and the authority publishes a self-test page for it.
• A taxpayer can report directly. Reporting does not have to run through an integrator: a taxpayer may use its own keys with a reserved value in the integrator field.
• Foreign customers are handled, with a condition. A foreign tax identifier is acceptable for a customer that is not supplying or earning in Nigeria.
• The position of a supplier established outside Nigeria is not settled in the documentation. We are not going to infer it. If you invoice Nigerian buyers from abroad, ask the authority or your buyer's provider, and get the answer in writing.

What must a compliant invoice contain?

A UBL-derived invoice, submitted as JSON, up to two megabytes. Eleven fields are mandatory: the business identifier, the invoice reference number, the issue date, the invoice type code, the invoice kind, the document currency code, the tax currency code, the supplier party, the tax total, the legal monetary total and the invoice lines. The supplier party itself must carry a TIN and an email address.

The line-level trap

Every invoice line needs a classification code — an HSN code where the line is goods, an ISIC code where it is services. This is the field most likely to fail a document that otherwise looks complete, because a generator that emits it for the first line and not the second produces an invoice that reads correctly and validates as an error. Our own first validation run failed for exactly that reason, on the second line of a two-line invoice.

Identifiers and geography

• TIN is the primary party identifier. Where a business buyer genuinely has none, the incorporation number is accepted in the same field, prefixed RC-.
• State and local government area are required on the accounting parties. The platform serves both lists — Nigerian states in the NG- form and the full local-government list — as resource endpoints.
• The invoice reference number is composed by you, not issued by an endpoint. It is the invoice number, the service identifier assigned to your business, and the date, joined with hyphens: {InvoiceID}-{ServiceID}-{YYYYMMDD}. The service identifier arrives when the business is registered on the platform.

Identifier and rounding mistakes are the commonest cause of silent rejection anywhere; the general pattern is in invoice validation errors you can prevent.

How is an invoice cleared, and what comes back?

Validate first, then sign. A validated invoice returns HTTP 200; signing returns 201, and from that point the invoice exists under its reference number. The rest of the lifecycle is what most projects underestimate:

Transmission is asynchronous. The platform reports what happened through a webhook rather than in the response body: you register a URL, your endpoint must accept POST and answer 200, and the messages are TRANSMITTING, TRANSMITTED, ACKNOWLEDGED and FAILED. They are stateless and event-driven, so process them idempotently — the same message can arrive twice and the order is not guaranteed. An invoice counts as completely transmitted only once every party has acknowledged it.

Payment status is part of the record rather than your ledger's private business: PENDING, PARTIAL, PAID and REJECTED, with a partial payment carrying the amount of that instalment. The VAT post-payment call records the tax side separately — supplier and beneficiary identifiers, base amount, other taxes, the VAT calculated and the rate, which in the authority's own example payload is 7.5.

What happens when an invoice fails validation?

Nothing goes forward. Signing is refused until validation passes, so a rejected invoice is not a cleared invoice with a warning attached — it does not exist yet. The platform answers HTTP 400 with four things worth persisting together: a request identifier, the handler that rejected the document, a machine-readable detail naming the field, and a user-facing message you can show an accounts-payable clerk without translating it first. The request identifier is what the authority's support desk will ask for.

Three failure patterns account for most of the time lost on a Nigerian integration:

1. A missing per-line classification code. One line without its HSN or ISIC code fails the whole document.
2. Building to the sandbox rather than to the documentation. When we tested, the documentation listed the invoice kind as mandatory while the sandbox accepted a payload without it and signed it. Build to the documented schema: a permissive sandbox today is not a promise about production tomorrow.
3. Discovering a schema change late. The changelog is the authority's own record of what has moved, and the three-month grace window only helps a team that is reading it.

There is a quieter fourth: burning your quota on documents your own system could have rejected. Validate locally first — structure, totals, the classification code on every line, the state and local-government values — and send the platform only what you believe is correct.

What does being unprepared actually cost?

The mechanical consequence arrives before any statutory one. Signing is refused until validation passes, so an unprepared supplier does not issue a defective invoice — it issues nothing. No cleared reference number, no QR code, and an in-scope buyer with no compliant document to pay against. Receivables stall while the integration is fixed.

Penalties for non-compliance are a matter for the authority's own rules and enforcement practice. We do not quote figures or deadlines for them here, because we cannot cite them to the authority's published material, and a penalty number repeated from a summary is exactly the kind of claim that gets a readiness plan approved on the wrong basis.

How do you prepare?

• [ ] Confirm your own position from the authority's notices and from the message addressed to your TIN — not from a summary, including this one.
• [ ] Decide the route: your own registration on the platform, or a registered System Integrator or Access Point Provider.
• [ ] Register the business and record the service identifier it is issued.
• [ ] Download the business's own cryptographic keys, and check the certificate is not the sample value printed in the documentation.
• [ ] Map your ERP to the documented schema, with a classification code on every line.
• [ ] Pull the reference code lists from the platform rather than hard-coding them.
• [ ] Compose the invoice reference number as invoice number, service identifier and date.
• [ ] Stand up the webhook endpoint before you need it: POST, 200, idempotent, logged.
• [ ] Build acknowledgement and payment-status updates, not just validate and sign.
• [ ] Archive the cleared invoice and its reference number for the retention period Nigerian tax law requires of you.
• [ ] Subscribe someone to the documented changes, and put the three-month grace window in your release calendar.

The order to do these in, with what breaks at each step, is the Nigeria e-invoicing onboarding runbook. For the finance-team framing of a structured-invoicing rollout generally, see the onboarding checklist for finance teams.

What does GoRoute provide for Nigeria?

We have built the Merchant-Buyer Solution integration and exercised it end to end against the authority's sandbox: validate, sign, QR generation, invoice-reference signature validation, encrypted download and decryption, and webhook delivery received from the authority's own dispatcher. That work was completed and evidenced in June 2026.

GoRoute also operates a certified Peppol Access Point and SMP for the markets that use Peppol — which, as this article has laboured, Nigeria does not. The two capabilities sit side by side in one API rather than in one network, and that is the honest way to describe it. Book a demo to walk the integration through against your own taxpayer population.

Sources: the Nigeria Revenue Service e-invoicing documentation at einvoice.nrs.gov.ng/docs — endpoints, schema, roles, dated changes and certification — read at version 1.1 in May and June 2026; the Federal Inland Revenue Service; and GoRoute's own end-to-end integration testing against the platform's sandbox, May–June 2026.