System Integration Consultant, Nigeria

Why Nigerian integration maps get crowded

The integration inventory for a Nigerian trading, manufacturing or services company is usually longer than management expects. A typical list includes:

• Several banks: naira and domiciliary accounts with different banks, each with its own statement format, portal and payment process.
• Payment gateways: online collections for webshops, invoices or subscriptions, settling in batches net of fees.
• POS terminals: card collections at branches and depots, often from more than one provider.
• Electronic invoicing: the tax authority's system for invoice reporting, which your advisor should confirm applies to you and how.
• Payroll: a provider or payroll system handling employee taxes and pension deductions, posting journals to the ERP.
• Commerce and logistics: webshops, marketplaces, delivery companies and clearing agents for imports.
• Reporting: Power BI or similar tools for management packs.

For each item I record what data moves, in which format, how often, by which method and who would notice if it stopped. Sometimes the answers show a finance officer downloading statements from each bank portal every morning, or a gateway connector set up by a former contractor with no documentation. Flows like these are tackled first.

The inventory also shows where the same data is entered twice, such as customer details in the webshop and the ERP. The ERP consultant page for Nigeria places these integrations within the wider ERP picture.

Banks, gateways and POS: one receipt model

Each payment source describes money differently. A bank statement line carries a narration typed by the customer. A gateway report lists individual transactions, then a single settlement net of fees days later. A POS provider sends batches by terminal. If each source is integrated in its own way, the ERP ends up with inconsistent records and matching rules that work for one channel and fail for the next.

I design a single receipt model that every source maps into:

• Transaction: the individual customer payment, with amount, date, channel, unique reference and any customer or invoice identifier provided.
• Fee: the charge deducted by the gateway, POS provider or bank, recorded separately so expenses are visible.
• Settlement: the amount that actually reached the bank account, linking the group of transactions it covers.
• Source account: which bank account or merchant account received the money, tied to the right entity and branch.

Unique references from each provider become the key that stops duplicates when notifications are resent. Webhooks from gateways give near real-time status, while statement imports act as the daily check that nothing was missed. Each source then gets a field mapping into this model, and matching rules sit on top of it, the same for every channel.

A daily control compares ERP totals with each bank and provider and sends differences to a named owner. The receipt rules themselves, such as how unidentified transfers are handled, are covered on the ERP business analyst page for Nigeria.

Exchange rates as integrated data

When exchange rates are typed in by whoever happens to post the transaction, the result is a mix of rates for the same day, revaluations nobody can explain and arguments with auditors. Treating exchange rates as integrated data, with a defined source and owner, solves much of this.

The design I agree with finance covers:

1. Source: which published rate or bank rate applies to which kind of transaction, as decided by finance and your advisors.
2. Feed: how rates reach the ERP, whether through an automated feed, a scheduled import or a controlled manual entry by one role.
3. Timing: how often rates update and which rate applies to transactions posted after hours or backdated.
4. Transaction-specific rates: how the actual rate a bank applied to an import payment or dollar receipt is captured from the bank document and stored with the entry.
5. Approval and audit: who can override a rate, what reason is recorded and how changes are logged.

Connected systems must follow the same rules. If the CRM quotes in dollars, or the webshop shows dollar prices, they should read rates from the same source as the ERP rather than keeping their own. Integrations that carry amounts across currencies record both the original amount and the rate used, so finance can trace every conversion.

Testing includes posting on a day with a rate change, receiving a dollar payment at a bank rate different from the system rate and running a revaluation. The multi-currency ERP page explains the accounting side in more depth.

E-invoicing links and resilience under unstable networks

Nigeria's tax administration has been introducing electronic invoicing, and the details continue to evolve. Which businesses are covered, which documents must be reported and through which route are questions for your tax advisor. My work is designing an interface that can meet the requirement they confirm and adapt when it changes.

The specification lists the master data to fix before go-live, including customer tax identification numbers, item descriptions and VAT codes; whether the ERP connects directly or through an intermediary; how invoice status is stored; and who handles rejections. Credit notes and cancellations get explicit rules, since they are where invoice data most often drifts.

Resilience matters for every interface, not only e-invoicing. Power interruptions and variable connectivity are a practical reality at many Nigerian sites. I design for them:

• Queuing: documents and receipts wait in a queue when a link drops and are sent in order once it returns.
• Idempotency: unique references ensure a resent record is recognized rather than duplicated.
• Hosting: middleware and connectors run on cloud infrastructure rather than a server in a branch that depends on a generator.
• Visibility: a status screen showing pending, failed and completed transmissions by site.
• Alerts: email or messaging alerts to named people when a queue grows or an interface stops.

Tests deliberately cut connections mid-transaction and replay queues. The ERP audit page for Nigeria covers reviewing invoice data quality in an existing system.

Who builds, how it is tested and who runs it

I stay on the design and supervision side. Coding is carried out by the ERP implementer, staff programmers or a specialist integrator, whether based in Lagos or overseas. I write the requirements and mappings, settle the method with you, review the builder's approach, compare each delivered interface with the written design and sit in on the test cycle.

Method is decided per interface:

Testing uses Nigerian scenarios: a transfer with a narration that matches nothing, a gateway settlement net of fees covering many orders, a POS batch posted twice, a dollar receipt at an unexpected rate, an e-invoice rejected for a missing tax number, a site offline for hours. Finance reconciles totals across banks and providers before sign-off.

Ownership is settled in writing before the build starts. Source code, hosting accounts, API keys and documentation belong to your company, not to the developer. From launch day, every interface keeps a log, raises alerts and has a runbook page, while a responsibility table names who handles bank, gateway, rate and e-invoicing issues. The CRM consultant page for Nigeria and the Nigeria page describe related remote services.