How to Integrate NRS E-Invoicing with SAP, Oracle, Microsoft Dynamics, Zoho and Custom ERP Systems

A verified account of what each major ERP does and does not ship for Nigeria, the three integration patterns available, and the workstreams that actually consume the project.

Start with the finding that reorganises most Nigerian e-invoicing projects.

We checked the current published documentation of six major ERP vendors. Not their sales pages, not their partner marketing, but the country coverage lists their own engineering teams maintain.

None of them ships a Nigeria e-invoicing localisation.

Not SAP. Not Oracle. Not Microsoft. Not Zoho, Sage or Odoo. In several cases the documentation was refreshed within the last two weeks, so this is the current position rather than a stale page nobody has updated.

That has a direct consequence for how you plan. Nigeria e-invoicing does not arrive as an ERP upgrade, a support pack or a localisation patch. It arrives as an integration you build or buy, connecting your ERP to an accredited Nigerian provider. The question is not whether your vendor will handle it. The question is which of three integration patterns fits your estate.

This article covers what each platform actually gives you, what NRS requires of any integration regardless of platform, and where the project time genuinely goes.

What the integration actually is

Strip away the vocabulary and the shape is simple.

Your ERP produces invoice data. That data must be mapped into a UBL XML document matching the NRS schema, signed, and submitted to NRS through an accredited Access Point Provider. NRS validates it and returns an Invoice Reference Number, a cryptographic stamp and a QR code. Only then is the document a legally valid invoice, and only then does it go to your customer.

For business-to-consumer transactions the flow inverts: the receipt is issued at the point of sale and reported to NRS afterwards rather than cleared in advance.

Two roles sit between you and the tax authority. A System Integrator works on your side, connecting the ERP and mapping the data. An Access Point Provider is the regulated gateway that transmits to NRS. A provider may hold one accreditation or both. If yours holds System Integrator accreditation only, there is a second party in your invoice path and you should know who it is.

The technical surface you are integrating against is small and well defined. Generate an IRN, validate an invoice, sign it, transmit it, confirm it, retrieve a QR code, download the cleared document. Alongside those sit reference data endpoints for HSN product codes, service codes, state codes and local government codes, which you will need for mapping.

What NRS requires of any integration

These obligations come from the National Regulatory Guideline for Electronic Invoicing in Nigeria 2025 and apply whatever ERP you run. Design against them from the start, because retrofitting several of them is painful.

Document standard. UBL XML, mapped from your business processes and data fields to the NRS schema. The guideline puts this squarely on the System Integrator: its stated duty is "mapping the relevant business processes and data fields to the e-invoice system schema" in accordance with UBL.

Authentication. OAuth 2.0.

Signing. A cryptographic stamp identifier and digital signature, potentially using ECDSA. XAdES for XML documents, PAdES for PDF/A-3. Keys generated in line with FIPS 186, with private keys held in a hardware security module. Certificate lifecycle managed through certificate signing requests, one-time passwords per device, and revocation monitoring via CRL or OCSP.

This is the part most in-house teams underestimate. Holding signing keys correctly is not a library import. If your architecture has a private key sitting in an application config file, it does not meet the guideline.

Offline and failure handling. An explicit obligation, quoted in full because people skip past it: "If the ERP system or eInvoicing platform experiences downtime, System Integrators must ensure that invoices can still be generated and stored until they can be submitted. This might involve creating offline storage systems or temporary solutions."

Your design must answer what happens when clearance is unavailable and an invoice still has to be raised.

Data residency. "All electronic data, including users' records, access codes, logs, and invoice data, must be encrypted and stored or backed up on servers or data centres in Nigeria." An architecture that stores invoice data exclusively in an offshore region does not comply. For multinationals running consolidated regional instances, this is often the single most disruptive requirement.

Identifiers. Every participant needs a Tax Identification Number. The Access Point Provider issues a unique Business ID as the standard identifier. Multi-branch businesses create sub-users. Non-residents making taxable supplies must obtain a TIN and charge VAT.

The formats are specific and your master data will need to match them. TINs follow a hyphenated numeric pattern. States and local government areas use ISO-style subdivision codes, so a Lagos or FCT address resolves to codes such as NG-FC for the state and NG-FC-AMA for the local government area. Product and service lines carry HSN classification codes. The Invoice Reference Number returned by NRS follows the pattern InvoiceNumber-ServiceID-YYYYMMDD.

Environments. NRS operates separate staging and production environments with distinct API keys. Onboarding asks for your ERP by name as part of the business profile, alongside industry classification, reporting method, turnover and preferred invoice exchange framework.

Document classification. The schema carries a field identifying each document as B2C, B2B, B2G or G2B. Since February 2026 the tax category list has included withholding tax and stamp duty alongside standard-rated, zero-rated and exempt. Exempt supplies are declared inside the e-invoice with an exemption code rather than left out of the system, and NRS publishes an exemptions endpoint returning an HS tariff code register.

A moving target. NRS releases schema changes with a stated grace period: updates are optional for three months from their release date, after which compliance is enforced. Whatever you build needs a maintenance path, not just a go-live.

Platform by platform

SAP

Nigeria appears in none of SAP's four published Document and Reporting Compliance country lists. We checked all four: S/4HANA Cloud public edition, S/4HANA on premise, SAP ERP on ECC 6.0, and DRC Cloud Edition. All were last updated between 13 and 17 July 2026.

SAP's African DRC coverage is Angola, South Africa and Egypt, and Egypt is the only one with an e-invoicing scenario. Nigeria also appears nowhere in SAP's published DRC release notes, so it is not a delivered feature awaiting announcement.

Note the ECC gap too. DRC exists for ECC 6.0, but with materially narrower coverage than S/4HANA, 41 countries against 59 and 60. If you are on ECC and assuming parity, check the specific scenario you need.

What SAP does document is the fallback, and anyone running SAP in Nigeria should read it carefully. A country without an SAP-delivered local version is handled as a customer local version, and SAP states the position plainly: "SAP does not provide legal changes for customer local versions. Compliance with local laws and maintenance is the responsibility of the customer or their implementation partner."

Read that as a risk allocation. When the NRS schema changes, and it does, SAP will not ship you the update. You or your partner will.

In practice, Nigerian SAP capability exists and is partner-built on top of DRC. SAP hosts a partner page for one such solution, and the partner's own material draws the distinction explicitly, describing its offering as an extension to SAP DRC and listing Nigeria under a rest-of-world category rather than SAP's delivered coverage. Third-party providers also market ERP-side layers claiming compatibility across ECC, S/4HANA and BTP.

Practical route: DRC as the document framework where you already own it, plus a partner or accredited provider extension for the Nigerian specifics, plus an accredited APP for transmission. Establish in writing who maintains the mapping when the schema changes.

Oracle

The Oracle ERP Cloud Global Catalog dated February 2026 contains no reference to Nigeria, and its EMEA availability matrix lists only Egypt and South Africa for Africa.

Oracle is explicit about its approach. Dedicated e-invoicing localisations are delivered "for certain countries such as Brazil and Mexico." Everyone else is directed to "the generic CMK configuration to implement and exchange e-Invoicing messages with customers, and government authorities directly or through certified service providers."

That last phrase is the relevant one. Oracle's documented Nigeria path is the Collaboration Messaging Framework pointed at a certified service provider. CMK gives you a message transformation and delivery layer. It does not give you the Nigerian schema, the signing requirements or the IRN handling.

E-Business Suite: the 12.2 country-specific installation supplement lists no African country at all. There is no Financials for Africa guide in the EBS documentation set. EBS customers are building against the generic path.

NetSuite: the Electronic Invoicing SuiteApp documentation states the position without ambiguity: it "does not include native support for any country-specific requirements or e-document standards. But you can create custom country-specific e-document templates and packages." Nigeria appears nowhere in the NetSuite help centre, and the SuiteApp marketplace returns no Nigeria listings. NetSuite customers build a custom e-document package or integrate externally.

Practical route: CMK or a custom e-document package as the transport, with the Nigerian schema, signing and clearance logic supplied by an accredited provider.

Microsoft Dynamics 365

Microsoft's electronic invoicing coverage documentation, updated 10 July 2026, lists Nigeria in neither its available nor its planned category. The only African country in the entire coverage table is Egypt. The 2026 wave one release plan's Globalization Studio country items are Brazil, the Netherlands, the UAE, France and Poland.

Business Central treats Nigeria as a partner localisation on the international base app, with the database in the South Africa Azure geography. Deployable, but the local functionality comes from a partner rather than from Microsoft.

Microsoft does, however, document the cleanest architectural answer of any vendor here, and it maps almost exactly onto Nigeria's regulatory structure. The ISV last-mile connector pattern exists, in Microsoft's words, to complement standard functionality "when no direct integration with government electronic invoicing platforms is supported out of the box." Dynamics generates the document in the required legal format; the ISV handles transmission to the authority.

In Nigeria, the ISV slot is filled by an accredited provider. Microsoft notes the pattern requires a separate signed service agreement with the ISV, which is worth remembering at contracting time.

Practical route: Electronic Reporting configurations to produce the UBL document, an ISV connector to an accredited APP for transmission. For Business Central, a partner localisation app plus the same transmission arrangement.

Zoho

Zoho Books publishes country editions for Australia, Bahrain, Canada, France, Germany, India, Kenya, Kuwait, Mexico, Oman, Qatar, Saudi Arabia, Singapore, South Africa, the UAE, the UK and the US.

There is no Nigeria edition. Nigerian users land on the global edition, which carries Zoho's own advisory to evaluate for local compliance before use. Nigeria appears in Zoho's pricing in naira, but not in its localisation set.

Note that Zoho does ship Kenya and South Africa editions. Nigeria's absence is a specific gap rather than a policy about the continent.

Zoho is a common choice among Nigerian mid-market businesses, which makes this the most consequential gap on the list for the ₦1bn to ₦5bn cohort now inside the mandate. The integration route is the API: your provider reads invoice data from Zoho, maps it, clears it, and writes the IRN and QR back so the customer-facing document carries them.

Practical route: API integration through an accredited provider. Confirm that the write-back path exists, because an integration that clears the invoice but cannot return the IRN into the document your customer receives has solved half the problem.

Sage, Odoo and the rest

Sage makes no reference to NRS, MBS or the Merchant Buyer Solution on its Nigerian site. Its global e-invoicing commitments are France, Spain, Germany and the EU, and it explicitly refers other jurisdictions to technology partners. Nigerian Sage capability comes from partner connectors, principally around Sage X3 and Sage 300.

Odoo is the case most likely to mislead you, so be precise about it. Nigeria does appear in Odoo's fiscal localisations list from version 18 onward. But the module itself is a chart of accounts, a VAT report and a withholding VAT report. There is no electronic document exchange module for Nigeria in any branch. NRS capability comes entirely from paid third-party apps, one of which is the only publicly listed price we found anywhere in this market at 349 euros per database per year.

If someone tells you Odoo supports Nigeria, they are right about accounting and wrong about e-invoicing.

QuickBooks and Xero we could not verify from their own documentation within this research. Some Nigerian providers advertise connectors for both. Treat those as vendor claims to be tested in a demo rather than confirmed facts.

Custom and in-house ERP

If you built your own system, you have the most freedom and the fewest excuses. There is no localisation to wait for and no vendor roadmap to argue with.

The realistic decision is how much of the regulated layer you take on yourself. Building your own UBL mapping and clearance client is entirely feasible. Building your own signing infrastructure to the guideline's standard, with HSM-held keys, certificate lifecycle management and revocation monitoring, is a genuine security engineering project that most finance-system teams should not take on for a single compliance obligation.

The common and sensible split is: you own the data extraction and the write-back into your system, your provider owns the schema mapping, signing, transmission and the maintenance burden when the schema changes.

One thing that catches in-house teams specifically. Because you control the ERP, it is tempting to solve clearance failures by changing invoice behaviour, for example by holding back document numbers until clearance succeeds. Resist that. Invoice numbering is prescribed and sequential, and improvising around it creates a different compliance problem than the one you were solving.

The three integration patterns

Everything above resolves into three choices.

Direct API integration. Your ERP or middleware calls the provider's API. Most control, most engineering, best fit for custom systems and for organisations with real integration capability in house. You own the failure handling.

Connector or middleware. A pre-built adapter for your ERP handles extraction and write-back. Faster, less flexible, and the important question is who maintains it when the NRS schema changes on a three-month grace clock.

Portal or upload. Invoices are entered or uploaded to your provider's portal rather than flowing from the ERP. Genuinely appropriate for low volumes and as a stopgap while a real integration is built. It becomes untenable at volume and it leaves your ERP and your cleared invoices as two versions of the truth.

A pattern worth naming: organisations under deadline pressure adopt the portal, declare themselves compliant, and then discover the reconciliation burden. As a bridge it is sensible. As a destination it is not.

Where the project time actually goes

Connectivity is rarely the hard part. Five other things are.

Master data remediation. Customer TINs, state and local government codes, product and service classification codes. This is almost always the longest workstream and it is the most common reason integrations fail validation. A decade of customer records captured without TINs does not remediate itself, and no provider can invent the data. Start here, before you have chosen a provider, because the work is provider-independent.

Document type coverage. Not just the standard sales invoice. Credit notes, debit notes, foreign currency transactions, mixed tax treatment on a single document, self-billing if you use it. Enumerate every document your business issues that carries VAT, then check each one against the schema.

Failure handling. The design question the guideline forces on you. What happens when clearance fails at 4pm on the last working day of the month. Where the document is held, how it is reconciled, what the finance team sees, and what order things recover in. Providers with real production experience answer this concretely. Ask early.

Buyer-side receipt. Validating IRNs on inbound supplier invoices. NRS's definition of compliance includes receiving only invoices bearing a valid IRN, so this is half the obligation, and it is routinely scoped out of proposals and discovered late.

Process and people. Clearance turns invoicing from a batch process into a real-time one. Someone must own exceptions daily. Organisations that do not adjust their month-end close feel it immediately.

Testing and go-live

NRS runs separate staging and production environments with distinct credentials, and a taxpayer works through validation and testing in staging before production access is meaningful.

Two points worth planning around.

First, testing is not only a technical exercise. The failures that matter are usually data failures, invalid TINs, missing classification codes, addresses that do not resolve to valid subdivision codes. Run your real customer master through validation early rather than testing with clean sample data and discovering the truth at cutover.

Second, do not treat go-live as the end of the project. NRS's own compliance definition requires you to be actively transmitting invoices, not merely integrated and tested. A company that completes integration and then transmits nothing is not compliant. Build the operational handover into the plan.

The question to settle first

Before you evaluate a single provider, answer one question about your own estate: where does invoice data live, and how many systems produce it?

Organisations with one ERP and clean master data have a genuinely short project. Organisations with a billing system, an ERP, a legacy application nobody wants to touch and three sets of customer records have a data project wearing a compliance project's clothes.

Knowing which one you are is worth more than any vendor comparison, because it determines whether you are buying an integration or funding a remediation.

Where we fit

Doftwerks West Africa Limited holds both System Integrator and Access Point Provider accreditation, approved on 30 April 2026 and listed on the official register at mbs.gov.ng/service-providers-directory. We publish our API documentation openly rather than behind a gate, and our MBS integration runs in the live production environment.

We wrote this article the way an engineering team would want it written: sourced to vendor documentation you can check yourself, with the unverified items marked unverified.

Contact us: [email protected] · +234 903 981 7173 · www.doftwerks.com

Sources

ERP vendor positions are taken from each vendor's own current published documentation: SAP's Document and Reporting Compliance supported compliance tasks by country pages across four product editions, updated 13 to 17 July 2026; the Oracle ERP Cloud Global Catalog dated February 2026, the E-Business Suite 12.2 country-specific installation supplement and the NetSuite Electronic Invoicing SuiteApp documentation; Microsoft's Dynamics 365 electronic invoicing coverage documentation updated 10 July 2026 and its ISV connector documentation; Zoho Books edition listings; the Odoo fiscal localisations documentation and the l10n_ng module manifest; and Sage's Nigerian and global e-invoicing pages. Technical obligations are from the National Regulatory Guideline for Electronic Invoicing in Nigeria 2025 issued by NITDA, in force from 1 September 2025. Platform behaviour, identifier formats and schema details are from the NRS e-invoicing portal at einvoice.nrs.gov.ng, including its developer documentation and changelog. QuickBooks and Xero could not be verified from primary vendor documentation.

This article is provided for general information and reflects the position as at 22 July 2026. It is not legal, tax or technical advice, and vendor roadmaps change. Verify current localisation status directly with your ERP vendor before making a planning decision.