Editorial illustration of Nigeria's FIRS TaxPro-Max submission flow for the how to comply with firs mbs nigeria guide
    E-Invoicing

    How to Comply with FIRS MBS in Nigeria: Onboard, Sign, and Issue Your First IRN (2026)

    Updated:
    13 min read

    Global E-Invoicing Platform Series

    This guide is part of a comprehensive series. Explore all 36 topics:

    To comply with the NRS Merchant-Buyer Solution (the platform still widely referred to as FIRS MBS), a Nigerian VAT-registered business in the active rollout wave must onboard on the NRS MBS portal at einvoice.firs.gov.ng, provision a signing credential bound to its TIN, build the prescribed JSON payload with validated buyer/seller TINs and 7.5% Nigerian VAT, submit it to the MBS API for the IRN, and present the IRN plus verification QR on every buyer-facing invoice.

    At a glance

    • Authority: Nigeria Revenue Service (NRS) — formerly Federal Inland Revenue Service (FIRS) — co-regulated by NITDA for accreditation.
    • Mandate: Merchant-Buyer Solution (MBS), the Electronic Fiscal System for Nigeria.
    • Artefact: Signed JSON payload + NRS-issued IRN + verification QR.
    • Transport: NRS MBS REST API (real-time clearance) or accredited System Integrator.
    • Applies to: VAT-registered taxpayers in the active wave (large from late 2025; medium and small phased through 2026 per the Feb 2026 NRS schedule).
    • Live since: Large-taxpayer pilot Q3 2025; phased rollout schedule published February 2026.
    • Last reviewed: 20 November 2026 against the NRS MBS portal and the NITDA National Regulatory Guideline for Electronic Invoicing 2025.

    Where MBS sits in the global e-invoicing landscape

    NRS MBS is a Continuous Transaction Controls (CTC) regime in the clearance family — the same architectural category as ZATCA Phase 2 in Saudi Arabia, MyInvois in Malaysia, and GST IRN in India.

    NRS MBS is a Continuous Transaction Controls (CTC) regime in the clearance family — the same architectural category as ZATCA Phase 2 in Saudi Arabia, MyInvois in Malaysia, and GST IRN in India. The seller submits a structured payload, the regulator validates it, and the invoice only becomes legally valid once an IRN is returned. Until then, the buyer has no obligation to pay or to claim input VAT.

    If you are coming from a post-audit jurisdiction (UK MTD-only, US sales tax, much of Europe pre-ViDA), the operational shift is sharp: NRS is now a runtime dependency of your invoicing flow. Build the queue-retry-resubmit loop before, not during, the wave window.

    What you need before you start

    An active Nigeria TIN issued through the Joint Tax Board. VAT registration with the NRS (the rebranded FIRS).

    • An active Nigeria TIN issued through the Joint Tax Board.
    • VAT registration with the NRS (the rebranded FIRS).
    • Confirmation that your business is in the current rollout wave — the NRS February 2026 alert lists thresholds for medium and small taxable persons; large taxpayers have been in scope since the Q3 2025 pilot.
    • An invoicing platform either accredited as a System Integrator by NITDA or able to call the NRS MBS API directly. See the accredited list on einvoice.firs.gov.ng → Service Providers.
    • NTP-synchronised server clocks — every payload carries an issue timestamp that the MBS compares to its own UTC clock; drift beyond the tolerated window rejects the submission.
    • An access policy for the signing credential — the private key never leaves your tenant.

    Step 1 — Register on the NRS MBS portal

    Who registers — taxpayer or platform vendor?

    The taxpayer registers as a merchant; the platform vendor registers separately as a System Integrator. The taxpayer-side registration creates the Merchant ID that every outgoing payload references.

    The taxpayer registers as a merchant; the platform vendor registers separately as a System Integrator. The taxpayer-side registration creates the Merchant ID that every outgoing payload references. Service-provider registration is a NITDA accreditation track, not a substitute for taxpayer-side onboarding.

    What information do I need?

    TIN, registered company name, RC number, principal officer details, business address, and the email used for portal correspondence. The portal then issues the Merchant ID and unlocks the credential-request flow.

    TIN, registered company name, RC number, principal officer details, business address, and the email used for portal correspondence. The portal then issues the Merchant ID and unlocks the credential-request flow.

    Step 2 — Provision your signing credential

    How is the credential issued?

    The platform generates a Certificate Signing Request (CSR) bound to your TIN and Merchant ID.

    The platform generates a Certificate Signing Request (CSR) bound to your TIN and Merchant ID. You then request a one-time password from the MBS portal, exchange CSR + OTP for the NRS-onboarded signing certificate, and persist the certificate inside your invoicing platform. The private key never leaves your tenant — Invoicemonk runs the entire CSR + OTP flow inside the product so you never handle key material.

    Does each device need its own credential?

    No. Unlike ZATCA's per-Solution-Unit CSID, the NRS credential is bound to the merchant TIN, not to a device.

    No. Unlike ZATCA's per-Solution-Unit CSID, the NRS credential is bound to the merchant TIN, not to a device. A single credential signs every outgoing payload from your tenant; multi-branch or multi-POS deployments still use one credential.

    Step 3 — Build the JSON payload

    The MBS payload follows a prescribed schema.

    The MBS payload follows a prescribed schema. The mandatory blocks are:

    • Header: Merchant ID, invoice number (seller-controlled), issue timestamp (UTC + Lagos offset), currency.
    • Parties: seller TIN, buyer TIN. Both are validated synchronously against the NRS TIN registry; an unknown TIN rejects the submission before the IRN is issued.
    • Line items: HS code, quantity, unit price, line VAT at 7.5%, applicable Withholding Tax (WHT) code per the NRS schedule.
    • Totals: subtotal, VAT total, WHT total, grand total.
    • Payment terms and reference data: due date, payment method, currency code, FX rate if the invoice is in a foreign currency.
    • Signature block: digital signature using the NRS-onboarded credential, computed over the canonicalised payload.

    Step 4 — Submit to the MBS API and receive the IRN

    Step 4 — Submit to the MBS API and receive the IRN includes: Canonicalise the JSON payload (stable ordering, UTF-8, no insignificant whitespace). Compute the digital signature with your NRS credential and embed it in the signature block.

    1. Canonicalise the JSON payload (stable ordering, UTF-8, no insignificant whitespace).
    2. Compute the digital signature with your NRS credential and embed it in the signature block.
    3. POST the signed payload to the NRS MBS API endpoint.
    4. The MBS validates schema, TINs, VAT computation, and signature. On success it returns an IRN and the regulator-side signed receipt synchronously.
    5. Persist the IRN, the receipt, and the regulator's signature alongside your local invoice record.

    Step 5 — Present the IRN and QR on the buyer-facing invoice

    The buyer PDF must display the NRS IRN and a verification QR that resolves to the NRS public verification endpoint. When the buyer scans the QR they see the seller, the buyer, the totals, and confirmation that the NRS validated the invoice.

    The buyer PDF must display the NRS IRN and a verification QR that resolves to the NRS public verification endpoint. When the buyer scans the QR they see the seller, the buyer, the totals, and confirmation that the NRS validated the invoice. Without these two artefacts, the buyer has no legal basis to claim input VAT or to fulfil their WHT obligation.

    Step 6 — Handle rejections and credit notes

    The most common rejection codes you will encounter on the MBS API:

    The most common rejection codes you will encounter on the MBS API:

    • Unknown seller TIN — the seller TIN is not in the NRS TIN registry, or is not the TIN tied to the merchant credential. Fix the credential mapping, do not retry.
    • Unknown buyer TIN — the buyer TIN failed registry lookup. Verify with the buyer; for non-Nigerian buyers use the prescribed foreign-buyer code, not a fabricated TIN.
    • VAT mismatch — declared line VAT does not equal 7.5% of the taxable line amount. Recompute and resubmit.
    • WHT code mismatch — the WHT code does not match the line's service classification. Look up the code in the NRS WHT schedule before resubmitting.
    • Timestamp out of tolerance — your issue timestamp drifted from MBS UTC. Re-sync NTP and resubmit.
    • Signature failure — the signature does not validate against the credential on file. Most often a canonicalisation drift; re-canonicalise and resign before resubmitting.

    To reverse a cleared invoice, issue a credit note through the same MBS flow. The credit note gets its own IRN and references the original IRN in the header. Do not delete or re-issue the original.

    Pre-go-live compliance checklist

    Pre-go-live compliance checklist includes: ☐ Merchant ID issued and visible on the NRS MBS portal. ☐ Signing credential provisioned via CSR + OTP, private key inside the tenant.

    • ☐ Merchant ID issued and visible on the NRS MBS portal.
    • ☐ Signing credential provisioned via CSR + OTP, private key inside the tenant.
    • ☐ JSON payload validates against the NRS schema in sandbox.
    • ☐ Seller and buyer TINs validate against the NRS TIN registry.
    • ☐ 7.5% VAT computation matches NRS expectation on every line.
    • ☐ Applicable WHT codes mapped per NRS schedule.
    • ☐ NTP synchronisation in place; issue timestamps in UTC + Lagos offset.
    • ☐ IRN and QR rendered on the buyer PDF in the prescribed format.
    • ☐ Credit-note flow tested end to end.
    • ☐ Rejection codes wired to the invoice timeline with retry policy.
    • ☐ Archive policy proven for the statutory retention period.

    Key takeaways

    Key takeaways includes: NRS MBS is clearance, not reporting — no IRN means no legally valid invoice. One credential per merchant TIN, not per device.

    • NRS MBS is clearance, not reporting — no IRN means no legally valid invoice.
    • One credential per merchant TIN, not per device.
    • TIN validation is synchronous on every submission; pre-validate buyer TINs before billing.
    • The buyer PDF must carry the IRN and the verification QR or the buyer cannot reclaim VAT.
    • Build queue-retry-resubmit for portal downtime — the regulator API is now a runtime dependency.

    Related reading

    Start at the e-invoicing pillar, then the FIRS / NRS MBS Nigeria mandate page. For the regulatory context, read FIRS MBS Nigeria explained.

    Start at the e-invoicing pillar, then the FIRS / NRS MBS Nigeria mandate page. For the regulatory context, read FIRS MBS Nigeria explained. To compare across regimes, read clearance vs reporting models. For the artefact that the IRN is part of, see what is an IRN, and for the comparable ZATCA primitive see what is a CSID.

    Authority sources

    Tags:
    FIRS
    NRS
    Nigeria
    MBS
    e-invoicing
    compliance
    how-to
    More in this series (36 articles)
    OO
    Olayinka Olayokun

    Digital Marketing, SEO Specialist, Content Creator & Product Professional

    CIM Certified
    MBA in Digital Marketing and Business Transformation

    Olayinka is a digital marketer, content creator, growth and SEO specialist with 10+ years helping businesses in Nigeria, the UK, the US, Australia, and Dubai achieve their goals online.

    More from Global E-Invoicing Platform