How to connect your ERP or accounting system to NRS e-invoicing

In short: Connecting your ERP or accounting system to Nigeria's e-invoicing platform means teaching your system to send each invoice out as structured data, have it validated, and store the reference number that comes back. The work splits into five stages, and the data clean-up usually takes longer than the connection itself.

What "integration" actually means here

Nigeria's platform, the Merchant Buyer Solution, accepts invoices as structured data in the BIS Billing 3.0 UBL format, an international standard also used across Europe. Your invoice leaves your system, is validated, and comes back with an Invoice Reference Number (IRN), a cryptographic stamp and a QR code.

So integration is four jobs:

1. Get the invoice data out of your system.
2. Translate it into the required format and fields.
3. Send it and handle the response.
4. Store the reference number, stamp and QR code against the invoice, and show them on the document your customer receives.

Stage 1: Map where invoices come from

List every system that issues an invoice: ERP, accounting package, point-of-sale, billing or subscription tool, and any spreadsheet still in use. Each is a separate source with its own data quality.

For each one, record: how many invoices per month, whether it can export structured data, whether credit notes are linked to the original invoice, and whether invoice numbers are unique across all branches.

Stage 2: Map your fields

The format has dozens of mandatory fields across supplier, buyer, line items, tax and totals. Build a mapping table: required field, where it lives in your system, and what to do when it is empty.

The fields that most often have no clean source:

• Buyer tax identification number.
• Registered legal name, as registered.
• Tax category per line item, not per invoice.
• Unit of measure.
• Discounts and charges as separate structured amounts rather than a note.

Anything with no source is a data project, not a coding task. Find these before you write code.

Stage 3: Choose a connection route

• Manual portal entry: no integration; only viable at low volume.
• Through an accredited Access Point Provider: the provider handles secure transmission to the NRS; you supply correctly formatted data.
• Through a System Integrator: your systems are connected so the flow runs automatically.

Accreditation covers software architecture, security and interoperability, and providers are assessed against recognised protocols. Confirm any provider's current accreditation directly with the NRS rather than relying on a marketing claim.

Stage 4: Build the integration properly

Design decisions that matter more than they first appear:

• Validate before you send. Check your own payload against the required fields first. Rejections handled inside your system are cheap; rejections arriving after the customer is waiting are not.
• Make submissions idempotent. Network timeouts happen. Sending the same invoice twice must not create two cleared invoices, so key each submission on your own invoice identifier.
• Queue and retry. Never let a failed transmission silently drop an invoice. Use a queue with retries and a visible failure state.
• Store the full response. The reference number, stamp identifier, QR code payload and the timestamp all need to persist against the invoice for audit.
• Model corrections from day one. Cleared invoices cannot simply be deleted. Credit notes and cancel-and-reissue flows must reference the original invoice.
• Log everything, expose nothing. Keep a full audit trail, but never log credentials or personal data.

Stage 5: Test with your ugliest invoices

Test data that looks like a textbook proves nothing. Run: a credit note against an old invoice, a foreign-currency invoice, an exempt item alongside a standard-rated one, a partial delivery, a very long line-item list, and an invoice for a customer with a missing tax identification number. That last one should fail cleanly, with a message a human can act on.

Then reconcile a full month end to end: invoices issued, accepted, rejected, and still pending. Those numbers must agree with your ledger.

What to monitor once you are live

• Rejections, grouped by reason, so recurring data faults get fixed at source.
• Invoices with no reference number older than your agreed threshold.
• Queue depth and the age of the oldest pending item.
• The difference between invoices in your ledger and invoices accepted by the platform. This should be zero.

Frequently asked questions

Do we need to replace our ERP?

Usually not. If it can export invoice data reliably and hold the returned reference number, it can normally be integrated.

How long does an integration take?

The connection is typically weeks. The timeline is set by data clean-up and by how many separate systems issue invoices.

What about systems with no API?

Scheduled exports, a database view, or a middleware layer can all work. It is more fragile than a real API, so invest in monitoring.

Can we run old and new side by side?

Yes, and you should: keep issuing as you do now while the new flow runs in parallel on real data, then cut over once a full reconciliation matches.

---

*General information based on published standards and guidance, not tax advice. Confirm current requirements at einvoice.firs.gov.ng. Provider-specific API details should come from that provider's official documentation.*