What NRS e-invoicing means for your business systems

Nigeria is moving business invoicing onto a national electronic framework administered by the Nigeria Revenue Service (NRS), formerly the Federal Inland Revenue Service. For most organisations the question is not whether to comply, but how their existing systems will do it without disrupting billing.

E-invoicing is often treated as a tax-department project. In practice it is a systems integration project. Every place that issues an invoice now needs to produce structured data, send it, and act on the response.

Under a paper or PDF regime, an invoice is a document a customer receives. Under e-invoicing, an invoice is a structured record that is validated and reported electronically, and a document second. Invoice data has to be complete, consistent and machine-readable at the moment of issue, not tidied up at month end.

• Invoices are exchanged as structured data rather than as free-form documents.
• Each invoice is checked against the framework's rules, and errors come back to the issuing system.
• Credit notes and corrections follow the same path, so reversals need a process, not a manual adjustment.
• Records need to reconcile between your system, the framework and your customer.

Few organisations connect their accounting system directly to a national platform. The usual route is through licensed intermediaries. A system integrator connects the business systems that create invoices (ERP, accounting, billing and point-of-sale software) and maps their data to the required format. An access point service provider transmits validated invoices to the framework and returns responses.

The two roles can sit with one provider. What matters is that the connection is reliable, that failures are visible, and that someone owns the mapping when your products, prices or tax treatment change.

1. An inventory of every system that issues invoices, including the ones finance forgets: branch tills, subscription billing and manual templates.
2. Clean master data: customer tax identification numbers, consistent product and service codes, and correct VAT treatment for each line.
3. A defined integration path for each source, through an API, a connector or a middleware layer, so that invoices are not re-keyed.
4. Error handling: what happens when an invoice is rejected, who is told, and how it is corrected and resent.
5. An audit trail that links the internal invoice, the submitted record and the response.

Start with the data, not the connection. Most integration problems we see trace back to incomplete customer records or inconsistent item codes, not to the transport layer. Fix those first, then connect one invoice source end to end, test rejections deliberately, and only then roll out to the remaining sources.

Check the current NRS timetable and requirements for your category of taxpayer, because rollout and technical specifications are set by the regulator and can change.

• Treating the integration as a one-off. Tax rules, product catalogues and customer records change, and the mapping has to change with them.
• Connecting only the main ERP and forgetting invoices raised elsewhere, so a share of revenue is invoiced outside the framework.
• Retrying rejected invoices automatically without fixing the data, which multiplies errors rather than clearing them.
• Leaving finance to discover rejections at month end because nobody owns the alerts.

1. Which of our invoice sources can you connect, and how?
2. How are rejected invoices reported back to us, and to whom?
3. Who maintains the mapping when our data or the specification changes?
4. What records will we hold to reconcile our ledger with what was reported?
5. How is the connection monitored, and what happens during an outage?