ERP Requirements Consultant, Nigeria

How a Nigerian ERP specification is organized

Implementers bidding for Nigerian projects often receive a long list in a spreadsheet with no context. A specification with a clear shape gives every bidder the same picture and makes their answers comparable.

• Business context: entities, factories, depots, distributor network, users, volumes and any systems staying in use.
• Process sections: imports and procurement, including documentation such as Form M where your bank requires it; production or assembly; depot stock and transfers; distributor sales, credit and rebates; collections across several banks; and the close.
• Statutory annex: VAT, withholding tax, electronic invoicing, payroll journals and record keeping.
• Currency section: rate sources, overrides, revaluation inputs and naira reporting.
• Non-functional section: resilience, hosting, access, audit trail and performance.
• Interfaces and migration: one entry per connection and per data object.

Each line carries a reference, an owner, a priority, its source and the reason it exists. Discovery work, meaning the workshops, interviews and process maps that surface these needs, belongs to my Nigerian business analyst engagement. This engagement is about the document as a controlled instrument: what goes in, how it is worded, who approves it and how it behaves once money rides on it. My wider approach to writing requirements is set out under ERP requirements gathering.

A statutory annex designed for changing tax rules

When tax administration is in flux, a statutory line written as fact can be wrong by the time the system goes live. I write the Nigerian annex so that change is expected. Each line has four parts: the outcome the system must show, the assumption it rests on, the advisor who confirmed it and how the outcome will be tested.

Examples of outcomes I would phrase this way:

• Tax codes, rates and their accounts can be changed by an authorized finance user through configuration, with the change logged and no developer involved.
• The status of every invoice sent for electronic exchange with the tax authority, including rejections and corrections, can be listed in one report.
• Outstanding withholding tax credits can be reported by customer and age, so finance knows which credit documents are still awaited.
• The payroll provider's journal posts PAYE, pension and other statutory deductions to the liability accounts your accountant specifies.
• Records and documents stay retrievable for the period your advisor confirms.

Because the assumption sits beside the line, a rule change triggers a visible update to that line and its test, not a debate about what the original wording meant. Tax advice is outside my role. Your advisor confirms the obligations; I make sure each one is written so an implementer can be held to it.

Non-functional lines for power, network, hosting and control

In Nigeria the non-functional section often decides whether a system is usable outside head office. It deserves the same care as the process sections.

• Power and network resilience: which tasks a depot or branch running on a generator or mobile data must continue during an outage, how documents captured offline are numbered and synchronized, and how duplicates are prevented.
• Hosting and data protection: where production data and backups sit, which outside staff have access, and whether that setup meets Nigeria's data protection law. Your legal advisor and IT lead judge the answers.
• Access control: separation between maintaining bank details, approving payments and releasing goods, with approval limits per location.
• Audit trail: who changed an exchange rate, a price list, a credit limit or a bank account, and how that history reaches the auditor.
• Performance: expectations for month-end, bulk invoicing and users on slow links, stated as points to agree rather than invented figures.
• Exit: how a full copy of your data is delivered if you change provider.

Bidders who see these lines early can price backup connectivity, offline tools and hosting honestly, instead of discovering them as change requests.

Payment channels, interfaces, migration and traceability

Nigerian companies often collect through several banks, transfers, card terminals and payment gateways at once, and each channel needs its own interface entry. The entry states what data arrives, how often, what reference links a payment to a customer and invoice, how failed or reversed payments appear and who clears exceptions. The same format covers the payroll provider, a distributor portal and any group reporting link.

Migration lines define which customer and supplier balances, dollar-denominated items, open withholding positions, stock by depot and documents move from Sage, QuickBooks or spreadsheets, and how each object is reconciled before the old system closes.

Priorities are set with the people who own each process. Must lines are those you would not go live without, should and could lines are traded against budget and time, and will-not lines are kept so excluded ideas do not quietly return. Every line then names the selection demo that displays it and the test case that proves it in user acceptance testing. That chain lets a finance director trace any withholding tax or exchange rate line from the fit-gap analysis to its accepted test.

Bids, milestone contracts and gaps to watch

The approved specification is sent to each bidding implementer as a requirement annex for line-by-line response, and the scripted demos on my Nigerian ERP selection page are drawn from it. In the contract, the scope clause names the approved version, and milestone payments can be connected to acceptance of named groups of lines rather than to hours spent. Organizations under public procurement rules use whatever tender format their procurement team prescribes, with the specification attached.

Change control continues after signing. Every revision is numbered and approved, with a log of changed lines and the reason, which matters when a tax or currency rule shifts mid-project and both sides need to agree what changed in scope.

Gaps that create risk in Nigerian specifications include:

• Tax codes hard-wired into custom code, so each rule change needs a developer.
• Electronic invoicing named, with no line on rejection handling or status reporting.
• Exchange rate overrides allowed without approval or evidence.
• No offline requirement, leaving depots idle during outages.
• Bank and payment channel matching assumed to be manual forever.
• Withholding credits left out of migration, so old balances never clear.

Wider remote support is described on the Nigeria hub and the ERP consultant page for Nigeria.