1. Home
  2. Blog
  3. Industry Technology
  4. Accounting Software Development in Nigeria: Scope, Cost and Build Guide

Accounting Software Development in Nigeria: Scope, Cost and Build Guide

Business colleagues working on a laptop in an office — an article about accounting software development in Nigeria

Accounting software is deceptively hard to build. The user interface is the easy part. What takes the time is the ledger underneath it: transactions that must balance, periods that must close, corrections that must leave a trail, and reports that must reconcile to the last kobo no matter which way the data is sliced.

Most Nigerian businesses should not build this. A distributor with three depots, a school, a clinic or a consulting firm will be better served by a cloud accounting package and a good bookkeeper. The businesses that genuinely need a build are the ones whose operation does not fit a package: multi-entity groups, businesses with unusual revenue recognition, companies embedding accounting inside a larger operational system, and founders building accounting software as a product for the Nigerian market.

This guide covers who should build, what the modules actually are, the Nigerian requirements most packages handle poorly, how to architect the ledger, what it costs, and how long it takes.

Who actually needs custom accounting software

Work through this honestly before spending anything.

Build is usually justified when:

  • You run several legal entities that must consolidate, with inter-company transactions between them
  • Accounting has to sit inside a larger operational system, so that a delivery, a booking or a production run posts to the ledger automatically
  • Your revenue model does not fit standard invoicing, for example commission splits, agent settlements, subscription billing with proration, or milestone-based recognition
  • You are building an accounting or bookkeeping product for the Nigerian market
  • Regulatory or sector reporting requirements are specific enough that no package produces the schedules you need

Buy is usually correct when:

  • You need general ledger, invoicing, expenses and basic reporting
  • Your transaction volume is moderate and your structure is a single entity
  • The real problem is that nobody is doing the bookkeeping, which software does not fix

Extend rather than build when:

  • A package handles 80% of the need and the gap is reporting, integration or a specific workflow
  • The gap can be closed with an integration layer, a reporting tool or a small custom module sitting beside the package

Build vs Buy Business Software in Nigeriain full. The short version: a build carries a maintenance obligation of roughly 15 to 25% of the build cost every year, forever. Budget for that or choose a package.

The core modules of an accounting system

ModuleWhat it holdsComplexityUsual phase
Chart of accounts and general ledgerAccount structure, journals, double-entry postings, trial balanceHigh. This is the foundationPhase one
Accounts receivableCustomers, invoices, credit notes, receipts, ageingMediumPhase one
Accounts payableSuppliers, bills, payments, advances, ageingMediumPhase one
Tax handlingVAT, withholding tax, tax codes on lines, tax reportsMedium to high in NigeriaPhase one
Banking and reconciliationBank accounts, statement import, matching, unreconciled itemsHigh in practicePhase one or two
ReportingTrial balance, profit and loss, balance sheet, cash flow, custom schedulesMedium, grows foreverPhase two
Inventory and costingItems, valuation method, stock movements, cost of salesHighPhase two or three
Fixed assetsAsset register, depreciation schedules, disposalsMediumPhase three
PayrollEmployees, PAYE, pension, statutory deductions, payslipsHigh and heavily regulatedOften bought, not built
Multi-entity and consolidationEntities, inter-company, elimination, group reportingHighOnly if genuinely needed
Approvals and controlsAuthorisation limits, segregation of duties, audit logMediumPhase two

A realistic first release is the first five rows plus basic reporting. Anyone quoting a complete system in six weeks is quoting the screens, not the ledger.

Nigerian requirements that packages often miss

These are the gaps that push Nigerian businesses towards a custom build, and the requirements a developer must get right.

Withholding tax on both sides. Nigerian businesses deduct withholding tax when they pay certain suppliers and suffer it when customers pay them. The system must record WHT deducted, produce the schedules needed for remittance, and, critically, track WHT credit notes received from customers so they can be applied against tax liabilities. Rates vary by transaction type and payee status, so hold them in a configurable table rather than hard-coding a percentage.

VAT treatment with exemptions. The system needs tax codes at the line level, handling of exempt and zero-rated items, and a VAT return schedule that separates output and input VAT. Nigeria's VAT rules and rate have changed before; confirm the current rate, thresholds and exemptions with the Federal Inland Revenue Service and keep them configurable.

Electronic invoicing and tax reporting. FIRS has been progressively introducing electronic invoicing and digital tax administration requirements. Any new build should keep invoice generation in one place so that a future integration requirement can be met without rewriting the module, and the current obligations should be confirmed with FIRS before launch.

PAYE across state boundaries. PAYE is remitted to the internal revenue service of the state where the employee is resident. A company with staff in Lagos, Abuja and Rivers needs employee records that carry the relevant state and payroll schedules that split accordingly.

Bank statements without feeds. Automatic bank feeds for Nigerian banks are frequently unavailable. Build for statement import instead: PDF and CSV parsing per bank format, a matching engine with fuzzy rules, and a manual review queue. This module is consistently underestimated and consistently the one users judge the system by.

Cash, POS and transfer receipts. Payments arrive by bank transfer with a narration the customer typed themselves, by POS terminal with a settlement that nets fees and lands a day or two later, and in cash. Receipt matching must handle partial payments, overpayments and one transfer covering several invoices.

Multi-currency with naira as base. Importers, exporters and any business with dollar-denominated costs need foreign-currency invoices, exchange-rate history, and correct treatment of realised and unrealised exchange differences. Get the rate source and the revaluation logic agreed with the client's accountant before writing any of it.

[CAC](https://www.cac.gov.ng/) and TIN on records. Customer and supplier records should carry registration details, which matters for tax schedules and for verification.

Getting the ledger right: architecture decisions that matter

Seven decisions determine whether the system survives its second year.

  1. Immutable postings. A posted journal is never edited. Corrections are made by reversal and re-posting. This single rule is what makes an audit trail possible and is the most common thing a cheap build gets wrong.
  2. Double-entry enforced at the database level. Every transaction balances before it is accepted. Not validated in the interface, enforced in the posting layer.
  3. Money as integers. Store amounts in kobo as integers, never as floating-point numbers. Rounding errors in a ledger are not a cosmetic problem.
  4. Period close with locking. Once a period is closed, postings into it require a specific permission and leave a record. Without this, last month's reported figures change quietly.
  5. A separate source-document layer. Invoices, bills and receipts are business documents; journals are their accounting effect. Keeping them separate lets you change document logic without corrupting history.
  6. Full audit log. Who did what, when, from where, and what the value was before and after. Auditors will ask, and so will you.
  7. Reporting that reads from the ledger, not from documents. Reports built on invoice tables and reports built on the ledger will eventually disagree, and reconciling them will cost more than building them correctly.

If the system is a product for other businesses rather than internal software, add multi-tenancy with strict data isolation, per-tenant chart of accounts templates, and a migration path for onboarding a client's historical balances. That work is substantial and belongs in the estimate from the start.

What changes when you build for Nigeria

Users expect WhatsApp, not email. Invoice delivery, payment reminders and approval requests reach people faster on WhatsApp. Building delivery through the WhatsApp Business Platform from Meta alongside email is normally worth the effort.

Payment collection is local. Card, bank transfer and USSD through a Nigerian provider such as Paystack, Flutterwave, Interswitch or Moniepoint. Where the system supports a payment link on the invoice, reconciliation improves immediately because the payment carries a reference.

Connectivity is inconsistent. Depot and field users lose connection. Decide early whether data capture must work offline and sync later. Offline-first roughly increases the cost of the affected modules, so apply it only where it is genuinely needed.

Hosting choices affect running cost and latency. Cloud hosting is usually billed in US dollars, so the naira rate moves your operating cost. Some businesses require data to stay in Nigeria for policy reasons; check whether that is a real requirement or an assumption before it constrains the architecture.

Personal data obligations apply. Customer, supplier and employee records are personal data under the Nigeria Data Protection Act 2023. Design access control, retention and deletion in from the start and confirm current obligations with the Nigeria Data Protection Commission.

Accountant involvement is not optional. The most expensive accounting builds are the ones specified entirely by business owners and developers. A qualified accountant should sign off the chart of accounts, tax treatment, revenue recognition and the closing process before development begins.

What accounting software development costs in Nigeria

Indicative 2026 ranges. Actual quotes vary with scope, integrations, vendor and exchange rate. Compare two or three written quotations on an identical written specification.

ScopeIndicative costTypical timeline
Accounting module inside an existing operational system₦2,500,000 to ₦6,000,0008 to 14 weeks
Core accounting system: ledger, AR, AP, tax, banking, reporting₦4,000,000 to ₦15,000,0004 to 7 months
Core system plus inventory and costing₦8,000,000 to ₦25,000,0006 to 10 months
Multi-entity system with consolidation, approvals and payroll₦15,000,000 to ₦40,000,000 and above8 to 14 months
Accounting SaaS product for the Nigerian market₦20,000,000 and above for a credible first release9 months upwards

Recurring costs, separate from the build:

Recurring itemIndicative rangeNotes
Cloud hosting and database₦150,000 to ₦800,000 per year and aboveUsually billed in US dollars
Maintenance and support15 to 25% of build cost per yearBug fixes, regulatory changes, minor features
Payment gateway feesPer transaction, set by the providerVerify current rates directly
Third-party servicesVariesStatement parsing, document storage, messaging

Two things reliably push a quote upward: bank statement reconciliation for many banks, and inventory costing. Two things reliably reduce it: accepting a package for payroll, and deferring consolidation until the single-entity system is stable.

Example (hypothetical): a distributor with seven depots

This is an illustrative scenario, not a Linestech client result.

A fast-moving consumer goods distributor operates seven depots across the South West, sells to about 900 retailers on a mix of cash and short credit, and buys from three manufacturers. It uses a desktop accounting package at head office, spreadsheets at each depot, and reconciles monthly, roughly two weeks late.

The real problem is not accounting software. It is that sales, stock movement and cash collection happen in the depots and reach the ledger by re-entry. The build therefore starts with operations, not accounts.

Phase one, 12 weeks. Depot sales and stock issue capture on tablets, working offline and syncing, posting automatically to a central ledger. Customer accounts with credit limits. Indicative cost: ₦7,000,000.

Phase two, 10 weeks. Accounts receivable with payment matching across bank transfer and POS settlements, supplier bills and payables, VAT and withholding tax handling including WHT credit note tracking. Indicative cost: ₦5,500,000.

Phase three, 10 weeks. Inventory valuation across depots, cost of sales, and management reporting by depot and by product line. Indicative cost: ₦6,000,000.

Payroll stays on a package. Consolidation is deferred because there is only one legal entity. The annual maintenance budget is set at roughly a fifth of the total build cost. The company's external accountant reviews and signs off the chart of accounts and tax treatment before phase two begins.

Timeline and phasing

  1. Discovery and specification, 3 to 5 weeks. Document the current process, agree the chart of accounts with a qualified accountant, define tax treatment, list every report required and who reads it, and decide what is in the first release.
  2. Ledger and core postings, 4 to 8 weeks. The foundation: accounts, journals, posting rules, period handling, audit log. Little to show visually and the most important phase in the project.
  3. Receivables, payables and tax, 4 to 8 weeks. Documents, tax codes, ageing, credit notes, WHT handling.
  4. Banking and reconciliation, 3 to 6 weeks. Statement import per bank, matching rules, review queue.
  5. Reporting, 3 to 5 weeks. Standard statements plus the specific schedules the business actually uses.
  6. Parallel run, 4 to 8 weeks. Run the new system alongside the old one for at least one full month, ideally a quarter, and reconcile the difference line by line. Do not skip this.
  7. Migration and cutover. Opening balances, open invoices and bills, and a clean cut at a period boundary.

Parallel running is where most of the value of the project is protected and where most schedules slip. Plan it into the contract rather than treating it as an overrun.

Pre-build requirements checklist

  • Has a qualified accountant approved the chart of accounts?
  • Is the tax treatment for VAT and withholding tax documented, including WHT credit notes?
  • Is every required report listed, with a named person who reads it?
  • Are the bank statement formats you must import collected and tested?
  • Is the payment reconciliation flow defined for transfer, POS and cash?
  • Is multi-currency genuinely required, and has the rate source been agreed?
  • Are approval limits and segregation of duties documented?
  • Is the opening balance migration plan agreed, with a cut-off date?
  • Is a parallel run of at least one full period in the plan and the budget?
  • Is the annual maintenance budget agreed before the build starts?
  • Does the contract cover source code ownership and data export?
  • Is there a named internal owner who will run the system after handover?

Mistakes to avoid

Building the screens before the ledger. Demonstrations look impressive and the accounting underneath does not balance. Insist that the posting engine, period close and audit trail come first.

Allowing edits to posted transactions. It solves a support complaint this month and destroys the audit trail permanently. Reverse and re-post.

Using floating-point numbers for money. The errors are small, cumulative and extremely difficult to explain to an auditor.

Underestimating bank reconciliation. It is usually the single largest piece of unglamorous work and the feature users judge the system by.

Skipping the parallel run. Cutting over without reconciling against the old system means discovering problems in the figures you have already reported.

Hard-coding tax rates. Rates and rules change. Keep them in configuration with effective dates so history stays correct when they do.

No maintenance budget. Tax rules change, banks change statement formats, browsers change. Software without a maintenance line degrades into a system nobody trusts.

Conclusion

Custom accounting software is a fit decision, not a cost decision. Build when your structure, your revenue model or your operational system genuinely cannot be represented in a package, and buy when the requirement is ordinary bookkeeping.

If you do build, protect the foundation: immutable double-entry postings, money stored as integers, period locking, a full audit log, configurable tax rules, and reporting that reads from the ledger. Get an accountant to approve the chart of accounts and tax treatment before development starts, budget for bank reconciliation properly, and run the new system in parallel with the old one for at least one full period before cutover.

Weighing a custom accounting build against extending what you already run? Linestech scopes accounting and operational systems for Nigerian businesses, including VAT and withholding tax handling, bank and POS reconciliation, and phased delivery. Share your current process and we will map a realistic scope, sequence and budget.

Frequently asked questions

Is it cheaper to build accounting software than to subscribe to a package?

Almost never in the first three years. A package costs a monthly subscription; a build costs a substantial one-off plus annual maintenance. Building is justified by fit, not by price, usually when the operation cannot be modelled in a package or when accounting must be embedded in a larger system.

How long does a custom accounting system take to build in Nigeria?

A core system covering ledger, receivables, payables, tax, banking and reporting typically takes four to seven months, plus a parallel run of at least one full accounting period. Adding inventory costing or multi-entity consolidation extends that considerably. Discovery quality is the largest factor in whether the estimate holds.

Can we add accounting to the software we already have?

Often yes, and it is usually the better route. If you already run an operational system for bookings, deliveries or production, adding a posting layer so that operational events create ledger entries is cheaper than a standalone accounting system and removes re-entry entirely.

Who should specify the accounting rules?

A qualified accountant, not the development team and not the business owner alone. The chart of accounts, tax treatment, revenue recognition and closing process should be signed off in writing before development starts. This is the cheapest risk control available on the project.

Does custom accounting software satisfy Nigerian audit requirements?

Auditors need a complete, tamper-evident record: immutable postings, a full audit log, period locking and reports that reconcile to the ledger. A system built with those properties supports an audit well. Discuss the requirements with your auditor during specification rather than after the first year end.

What happens when tax rules change?

If rates and rules are held in configuration with effective dates, a change is an administrative update. If they are written into the code, it is a development job every time. Insist on the first approach, and keep a maintenance arrangement in place so regulatory changes can be applied promptly.

Should we own the source code?

Yes, and the contract should say so explicitly, along with your right to export your data in a usable format at any time. Also agree what happens if the relationship ends: documentation standard, handover process, and whether the code is held anywhere you can reach it.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.