Nigeria FIRS E-Invoicing

Key Features

FIRS-aligned document builder producing the required structured payload from posted `Sales Invoice Header` and `Sales Cr.Memo Header` records, with per-line tax detail

Table and page extensions carrying TIN, buyer identification scheme, submission status, authority reference, submission timestamp and raw response on the posted document itself

Setup-driven tax mapping from VAT Business Posting Group, VAT Product Posting Group and VAT Posting Setup to FIRS tax categories, rates and exemption reason codes

Pre-submission validation that blocks a document with a missing TIN, unmapped tax code, unmapped unit of measure or incomplete customer data, with a field-level error list instead of a generic failure

Job Queue Entry-driven asynchronous transmission with configurable retry, exponential back-off and timeout, so posting is never blocked by an authority outage

Codeunit-based HTTPS client handling authentication, token lifecycle and signing, with credentials held in Isolated Storage rather than in setup fields

FIRS Submission Log page with status, attempt history, authority error text and the full request/response payload for every document

Rejection work queue that surfaces the authority error, prevents blind re-submission and drives the corrective credit memo or corrected invoice with the original reference preserved

Human-readable output from the same posting: customer-facing invoice report carrying the FIRS identifiers and verification data returned on acceptance

Multi-entity and multi-currency support, including reporting-currency amounts derived from Currency Exchange Rate entries and per-company FIRS credentials

Event subscribers on standard posting codeunits — no base application objects modified, so the extension survives Business Central release wave updates

Dedicated permission sets separating submit, correct, and view-log rights from ordinary sales roles, with an audit trail of who submitted or corrected what

API pages (REST API v2.0 / OData v4) exposing submission status and authority references to Power BI, Power Automate and Dataverse-connected apps

Compliant archive retaining the transmitted payload, authority acknowledgement and identifiers per document, retrievable from the posted record for audit and inspection

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

Nigeria's FIRS e-invoicing regime turns invoicing from a printing exercise into a transmission obligation. Every sales invoice and credit memo has to leave Business Central as a structured, FIRS-aligned payload carrying seller and buyer TIN, the correct VAT and withholding treatment per line, currency and FX detail, and a document reference that survives correction cycles. Standard Dynamics 365 Business Central gives you posted sales documents, VAT posting setup and a report layout — but nothing that builds the FIRS document structure, authenticates and submits it, stores the returned authority identifiers against the posted document, or drives a rejection back into a controlled correction. Teams bridge that gap with a spreadsheet and a portal login, and the ERP and the tax authority start disagreeing the moment someone re-keys a figure.

We build an AL extension for your tenant that closes the loop inside Business Central. Table extensions on Sales Invoice Header, Sales Cr.Memo Header and Customer carry the FIRS fields — TIN, buyer identification scheme, submission status, authority reference, timestamp and raw response — so compliance state lives on the document, not in a side system. A mapping layer translates your existing master data into FIRS terminology: VAT Business and VAT Product Posting Groups to tax categories and rates, item and G/L lines to the required classification, Units of Measure to the expected code list, and Currency Exchange Rate data to reporting-currency figures. Nothing is hard-coded — mappings live in setup tables your finance team maintains, and validation refuses to submit a document with an incomplete mapping rather than sending something the authority will bounce.

Transmission runs through codeunits that build the payload, apply the required signing and authentication, call the FIRS endpoint over HTTPS with retry and timeout handling, and persist the full request and response for audit. Submission is driven by a Job Queue Entry, so posting stays fast and an authority outage never blocks a sale: documents queue, submit and reconcile on their own schedule, with a dedicated FIRS Submission Log page showing status, attempt count, error text and the raw payload. One posting produces both the machine format for the authority and the human-readable document — the customer-facing PDF carries the identifiers and verification data returned by FIRS, so what the buyer receives matches what was filed. Rejections land in a work queue: the extension surfaces the authority's error, blocks blind re-sends, and drives the corrective document with the original reference preserved.

Technically it stays upgrade-safe. We subscribe to events on the standard posting codeunits rather than modifying base application objects, ship dedicated permission sets so submission and correction rights are separable from ordinary sales roles, and expose submission status through API pages (REST API v2.0 / OData v4) so Power BI, a Power Automate flow or a Dataverse-connected app can read compliance state without a database hop. We target current Business Central release waves and support both online (per-tenant extension, or AppSource-track packaging if you intend to publish) and on-premises deployments.

This is built to order, not downloaded. After a short scoping call we confirm your Business Central version and deployment model, your Nigerian entity structure and TIN setup, which document types are in scope, your VAT and WHT treatment, and how FIRS credentials and endpoints are provisioned to you. We then build against your exact version, test on your sandbox with your real chart of accounts and customer data, run UAT with your finance team, and deploy with a rollback plan. Typical delivery is 2-4 weeks from confirmed scope, depending on document types, integration surface and how many legal entities are involved. You receive the AL source, the git repository, technical and user documentation, a training session and a post-go-live support window — and because regulatory schemas move, we agree the update path for schema and endpoint changes as part of the engagement rather than leaving you to discover them at filing time.

What you get

Installable AL extension source (.al project plus compiled .app) built and tested against your exact Business Central version and deployment model

Installation and configuration on your sandbox and production environments, including FIRS setup, tax mapping tables and Job Queue Entry configuration

Technical documentation: object ID ranges, table/page extensions, codeunit and event-subscriber map, API page endpoints, permission sets and integration configuration

End-user guide covering submission, monitoring the FIRS Submission Log, handling rejections and running the correction workflow

Live training session for your finance and AP/AR team, recorded for onboarding new staff

UAT on a staging sandbox using a copy of your production data, with a signed-off test script and a documented rollback plan

Post-go-live support window for defect fixes, submission troubleshooting and configuration adjustments

Full git repository handover with commit history, branch structure and build pipeline notes, so any AL developer can maintain it

Who this is for

Financial Controller, Nigerian operating entity

Accountable for the accuracy of what is filed with FIRS. Needs every posted invoice to be transmitted once, matched to an authority reference, and reconcilable back to the general ledger without maintaining a parallel spreadsheet.

Head of Tax / Tax Compliance Manager

Owns VAT and withholding treatment and the audit response. Needs tax mapping to be visible and maintainable in setup tables, exemption reasons to be explicit, and a retrievable archive of exactly what was transmitted and acknowledged for each document.

Business Central Functional Consultant or ERP Manager

Owns the tenant and the upgrade path. Needs an extension that uses event subscribers rather than base object modification, ships proper permission sets, and can be re-tested cleanly against each Business Central release wave.

Finance Shared Services / AR Team Lead

Processes the daily invoice volume and handles rejections. Needs a clear submission status on each document, a work queue that shows why the authority rejected something, and a correction path that does not require a portal login or manual re-keying.

How Nigeria FIRS E-Invoicing Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Fit to your tax setup	Mapped to your actual VAT posting groups, items and units during scoping	Fits perfectly if your team knows both the FIRS rules and AL	Generic mapping; you bend your setup to fit its assumptions	VAT posting setup exists but has no FIRS document concept
Transmission to FIRS	Job Queue-driven submission with retry, back-off and full request/response log	Built to whatever depth your budget and timeline allowed	Usually present, but the retry and logging behaviour is a black box	None — export a report and use the portal manually
Rejection and correction	Rejection work queue with authority error, blocked blind re-sends, linked correction	Frequently the first thing cut when the deadline tightens	Status flag; correction workflow often left to your process	Handled outside the ERP entirely
Upgrade safety	Event subscribers and extension objects only; no base app modification	Depends on the developer's discipline; base object edits are common	Vendor manages it, but on the vendor's release schedule not yours	Nothing to break, nothing to help you
Source code and lock-in	Full AL source and git repository handed over at delivery	Yours, along with sole responsibility for maintaining it	Compiled .app only; renewal is the price of continuity	Not applicable
Time to production	2-4 weeks from confirmed scope, including sandbox UAT and rollback plan	Months once hiring, specification and rework are counted honestly	Install in a day, then weeks of configuration and gap workarounds	Immediate, but the compliance gap stays open
Regulatory change handling	Update path for schema and endpoint changes agreed in the engagement	Your team tracks FIRS notices and reworks the payload each time	Included while your subscription is current, on their timeline	Your problem, discovered at filing time
Reporting and integration	API pages (REST v2.0 / OData v4) exposing status to Power BI, Power Automate, Dataverse	Possible, usually deprioritised behind core submission	Vendor-defined surface; extending it often needs their consent	Standard APIs exist but carry no FIRS data to expose

Frequently Asked Questions about Nigeria FIRS E-Invoicing

How long does delivery take?

This is a build-to-order extension, not an existing AppSource download. Typical delivery is 2-4 weeks from confirmed scope. That window covers building against your Business Central version, configuring the tax mapping to your posting groups, sandbox testing with your data, UAT with your finance team and production deployment. Multiple legal entities, additional document types or extra integrations (for example pushing status into Power BI or a Power Automate approval) can extend it; we give you a firm date once scope is signed off, not before.

What support and updates do we get after go-live?

Every engagement includes a post-go-live support window for defect fixes, submission troubleshooting and configuration adjustments. Because e-invoicing schemas and endpoints change, we agree the update path explicitly during scoping: how schema or endpoint changes are handled, what turnaround applies, and how it is packaged. You also receive the full AL source and git repository, so you are never locked in — your own team or another AL developer can maintain it if you prefer.

Does this work on Business Central online, on-premises, or both?

Both. For Business Central online we deliver a per-tenant extension installed into your environment (or AppSource-track packaging if you intend to publish it yourself). For on-premises we build against your specific version and provide the .app plus deployment instructions. We target current release waves and confirm your exact version during scoping, because the platform version determines available APIs and the object model we build against.

Will this survive Business Central upgrades?

It is designed to. We use table and page extensions plus event subscribers on the standard posting codeunits rather than modifying base application objects, which is what breaks on upgrade. Each release wave still deserves a regression pass against your sandbox before you upgrade production, and that is part of the support conversation we have with you at scoping.

How does the extension handle a rejection from FIRS?

A rejected document does not silently disappear. The authority's error is captured against the posted record and surfaced in a rejection work queue with the raw response retained. The extension blocks blind re-submission of an unchanged payload and drives the correction path — a corrective credit memo and corrected invoice, or resubmission where the regime permits — with the original document reference preserved so the audit trail links the correction to what it replaces.

Do we need to change our existing chart of accounts or posting groups?

No. The mapping layer sits on top of what you already have: your VAT Business and VAT Product Posting Groups, items, resources, G/L accounts and units of measure map to the FIRS code lists through setup tables your finance team maintains. If we find gaps during scoping — a tax treatment with no clean FIRS equivalent, for example — we raise them before the build rather than discovering them in UAT.

Who provides the FIRS credentials and endpoint access?

You do. Registration with FIRS and provisioning of your entity's credentials and endpoint access is a taxpayer obligation we cannot perform on your behalf. We tell you exactly what the extension needs, store it securely in Isolated Storage rather than in plain setup fields, and help you validate connectivity against the sandbox environment before go-live.