How to Build an Integrated Business System

Companies usually arrive at this question after accumulating tools. There is an accounting package, a spreadsheet for stock, a WhatsApp-based sales process and possibly a website that takes orders. Each works. Together they produce a business where the same customer exists four times, nobody can produce a reliable monthly picture, and three people spend their mornings copying figures between systems.

The answer is architecture, not another purchase. This article covers the three integration patterns available, how to choose your core system of record, the identifier discipline that makes everything else possible, the order to build modules in, what it costs in Nigeria, and how to avoid creating an expensive system that is still not integrated.

What "integrated" actually means

A business system is integrated when each fact is stored once, in one place that owns it, and every other part of the system reads that fact rather than keeping its own copy.

Three tests tell you whether you have it:

• The single-entry test. When a new customer places a first order, how many places does someone type their name? The answer should be one.
• The single-answer test. If you ask three departments for last month's revenue, do you get one number? Different numbers mean different systems of record.
• The traceability test. Can you follow one order from enquiry, through fulfilment, to invoice, to payment, to the delivery record, without leaving the system or opening a spreadsheet?

Integration is not the same as having a single vendor's product, and it is not the same as having everything on one screen. A business using three separate tools that share a customer identifier and pass data automatically is more integrated than one using a single large platform where half the departments keep parallel spreadsheets because the platform does not fit their work.

The three architecture patterns

There are three realistic ways to arrive at an integrated system. Most Nigerian companies end up with the third.

A practical way to choose: if an existing product handles 80% or more of a function well, configure it. If your core operating process is the thing that makes you better than competitors, build that part. Then connect. Very few Nigerian SMEs should custom-build accounting or payroll; many benefit from custom-building the operational process specific to their trade.

Step 1: Choose your core system of record

The core is the system that holds transactions — orders, jobs or cases — because that is what everything else refers to. Choose it deliberately, because it determines the shape of every later integration.

Criteria for the core:

• Holds the transaction that defines your business (order, job, booking, case, consignment)
• Can store the customer identity you will use everywhere
• Has an accessible API or export mechanism for connecting other tools
• Supports the roles and permissions your operation needs
• Works on phones, since much Nigerian operational work happens away from desks
• Can be extended without replacing it as volume grows
• Your team can get support for it, locally or reliably remotely
• You own or can export the data at any time

The last two are frequently ignored and frequently regretted. A well-featured platform that no one in Nigeria can support, or that makes data extraction difficult, creates a dependency that is expensive to escape.

Accounting is usually not the core, despite being the oldest system in most businesses. Accounting records the financial consequence of operations; it is a poor place to run operations from. Keep it, integrate it, and let the operational system own the transaction.

Step 2: Define shared identifiers and the data model

This step is short, unglamorous and decides whether integration is possible at all.

Customer identity. Pick one identifier used by every component. In Nigerian practice a normalised phone number works best, because customers keep numbers across channels and it is what staff already ask for. Normalise the format everywhere — one country prefix convention, no spaces — or matching will fail silently. Where a business has both individual and corporate customers, use an internal customer ID with the phone number as the lookup key.

Product and service identity. One code per item, used in orders, stock, invoices and reports. Branch-specific codes are a common cause of unreconcilable reporting in multi-location Nigerian businesses.

Transaction identity. One order or job reference, visible to the customer, quoted on the invoice and used as the payment reference. This one decision removes a large share of the reconciliation work that Nigerian businesses do manually.

Staff identity. One user per person, never shared logins. Shared accounts destroy the audit trail and make it impossible to answer who changed a price or issued stock.

Write the model down as a short table: entity, identifier, which system owns it, which systems read it. Two pages is enough, and it is the document every future vendor should receive.

Step 3: Decide what each module owns

Ownership means one system is authoritative for each type of data. Others may display it, but only one may change it.

Ambiguity here is what produces two versions of the truth. If both the online store and the inventory system can change stock levels independently, they will disagree within a week.

Step 4: Build in dependency order

Build order follows data dependency, not enthusiasm.

1. Master data. Clean customer, product, price and staff lists, with the identifier scheme applied. Nothing built before this is trustworthy.
2. Core transaction system. Orders, jobs or bookings, with roles and statuses. This is the spine.
3. Money. Invoicing generated from transactions, payment recording with references, and the accounting integration.
4. Operations modules. Stock, dispatch, production or scheduling, driven by the transactions already in the core.
5. Customer-facing surfaces. Website, online store, customer portal — connected to the core so orders arrive in the same place as every other order.
6. Communication integrations. WhatsApp, SMS and email tied to the customer record, so messages attach to a history.
7. Reporting layer. Built once several modules are producing reliable data.
8. Automation and AI. Last, because both amplify whatever the system already does, including its errors.

Deliver each step as something usable. A twelve-month build with a single reveal at the end is the highest-risk approach available, particularly with a Nigerian SME's cash flow and attention span.

Step 5: Design for change and failure

Integrated systems fail in ways that isolated tools do not, because a break in one connection silently corrupts data elsewhere. Design for it upfront.

• Log every exchange. Each transfer between systems should be recorded with a timestamp, a status and the payload reference. Without logs, diagnosing a mismatch takes days.
• Make failures visible. Build an exceptions list somebody checks daily: payments that did not match, orders that did not reach accounting, stock movements rejected. Silent failure is the real risk.
• Retry safely. Connections drop. Retries must not create duplicate orders or double-post payments, which means each transaction needs a unique reference the receiving system checks.
• Keep a manual override. With an audit record. Businesses need a way to proceed when an integration is down, and if you do not provide one, staff will invent an unrecorded one.
• Version and document the interfaces. When a vendor updates an API, an undocumented integration breaks and nobody knows what it did.
• Hold your own credentials. API keys, hosting, domain and repository in the company's accounts, not a developer's personal ones.
• Back up and test restoration. An untested backup is an assumption. Test a restore at least annually.
• Plan for volume. Ask what happens at five times current transaction volume. It is cheaper to know now than to discover during a peak season.

What changes in the Nigerian context

Payment reconciliation is the hardest integration. Money arrives by transfer, POS, USSD, cash and gateway. Gateways such as Paystack, Flutterwave, Interswitch or Moniepoint provide clean webhooks; direct bank transfers do not, which is why the transaction reference discipline in step 2 matters so much. Many Nigerian businesses use virtual account numbers per customer or per order to make matching automatic — worth discussing with your provider.

WhatsApp is a system, not a channel. For integration purposes, treat it as a component: the WhatsApp Business Platform can create leads, send confirmations and receive replies into your core. Budget the conversation-based charges and verify current pricing in Meta's documentation.

Older accounting packages may lack usable APIs. Where a desktop package is entrenched, scheduled file exchange is a legitimate fallback: a nightly export and import, with reconciliation reporting. It is less elegant than a live connection and perfectly workable.

Connectivity affects design. Integrations should queue and retry rather than assume constant availability, and field capture should work offline where staff operate away from reliable networks.

FX affects the running cost. Integration platforms, cloud hosting and messaging are typically dollar-priced. A system with eight paid connectors has a running cost that moves with the exchange rate; consolidate where you sensibly can.

Data protection applies across the whole system. Once customer data flows between components and third parties, the Nigeria Data Protection Act 2023 is relevant to each of those flows. Document which systems hold personal data, restrict access by role, and verify obligations with the Nigeria Data Protection Commission as of 2026. This is not legal advice.

Example (hypothetical): an Onitsha wholesale business

The following is a hypothetical illustration, not a Linestech client result.

A wholesale business in Onitsha supplies retailers across the South East with 70 staff and two warehouses. It runs a desktop accounting package, a spreadsheet per warehouse for stock, a WhatsApp group for sales orders, and a notebook for credit customers. Month-end takes three weeks and warehouse stock rarely matches the books.

Architecture chosen. Best-of-breed with an integration layer. The accounting package is retained because it works and the accountants know it. A custom core order and stock system is built, because the credit and consignment model does not fit standard products.

Identifiers. Customers keyed by normalised phone number with an internal customer ID. One product code list replacing two warehouse-specific ones. Order references used as payment references.

Build order. Master data consolidation (5 weeks), core order and credit system (14 weeks), invoicing with payment matching plus nightly accounting export (6 weeks), warehouse stock movements (8 weeks), retailer ordering portal (7 weeks), reporting (5 weeks).

Failure design. A daily exceptions list shows unmatched payments and failed accounting exports. Sales staff can record an order offline on a phone, which syncs when the connection returns, with duplicate protection on the order reference.

Indicative spend: ₦16,500,000 over 11 months, plus ₦420,000 per month running including hosting, subscriptions and support. The change the owner measures is time to close the month, stock variance at count, and the proportion of credit balances that both the warehouse and accounts agree on.

What an integrated system costs

Indicative 2026 ranges for Nigerian businesses; actual quotations vary with scope, vendor, number of integrations, data condition and exchange rate.

Total indicative range for a Nigerian SME or mid-sized company: ₦2,000,000–₦20,000,000+ across the programme. Configure-heavy approaches sit low in the range; custom cores with several integrations sit high. Ask for build and annual running cost separately, and for a per-integration price so you can defer the ones that are not yet needed.

Mistakes that produce a disintegrated system

• Buying tools before designing identifiers. Once two systems hold customers with no common key, integration becomes a matching exercise that never quite works.
• Letting accounting be the core. It produces operational processes shaped around financial periods rather than around customers and work.
• Duplicating ownership of data. Two systems that can both change stock or prices will disagree, and staff will lose confidence in both.
• Integrating without logging. When numbers differ, nobody can say which exchange failed or when.
• No exceptions list. Silent failures accumulate for weeks before someone notices at month end.
• Shared logins. They destroy accountability and make audit trails meaningless in exactly the businesses that need them most.
• Vendor-held credentials. Hosting, domains, API keys and repositories must sit in the company's own accounts.
• Connecting everything at once. Each integration adds failure modes. Add them in order of value and stabilise each one.
• Ignoring the volume question. Systems that work at 50 orders a day can behave very differently at 500.

Conclusion

Building an integrated business system is an architecture exercise: choose a core system of record that owns your central transaction, define one identifier per customer, product and order, assign clear data ownership to each module, then add components in dependency order with logging and a visible exceptions list.

Do that, and you can keep the tools that already work while ending the copying between them. Skip the identifier and ownership decisions, and you will have bought several good systems that still cannot agree on how many customers you have.

If you are planning an integrated system for a Nigerian business, Linestech can design the architecture and data model, then build or connect the modules in a sequence that keeps you trading throughout.

Frequently asked questions

Should we buy one big platform or connect several tools?

It depends on how closely a platform matches your process. If an existing product fits most of your operation, a single platform is simpler to run and cheaper to maintain. If your core process is distinctive, build that part and connect specialist tools around it. Most growing Nigerian SMEs end up with a connected best-of-breed arrangement.

Is an ERP the same as an integrated business system?

An ERP is one way of achieving integration — a single platform covering finance, operations and more. It is not the only way, and for many Nigerian SMEs the licensing, implementation cost and process rigidity outweigh the benefit. Integration is the outcome; an ERP is one route to it.

Can we keep our existing accounting software?

Usually yes, and often you should. Accountants know it, historical data lives in it, and replacing it adds risk without adding operational capability. Integrate it, with a live connection if the package supports one, or a scheduled export if it does not.

How many integrations are too many?

There is no fixed number, but each connection adds cost, failure modes and maintenance. If a connector exists only to move data that nobody acts on, remove it. Review the list annually alongside subscriptions.

What if a connection breaks and we do not notice?

That is the central risk, which is why every integration needs logging and a visible exceptions list checked daily. The failure itself is normal and unavoidable; failing to notice is a design fault.

Do we need a technical person in-house?

For a small system, no, provided your vendor documents everything and your accounts hold the credentials. Past roughly ten integrated components, having someone internally who understands the architecture — not necessarily a developer — reduces cost and dependency considerably.

How do we avoid being locked into one vendor?

Own your hosting, domain, repository and data; require documentation as a deliverable per phase; use standard, documented interfaces; and ensure you can export complete data at any time. Lock-in is created by contract terms and account ownership far more than by technology.

Can we build this gradually while trading normally?

Yes, and that is the recommended approach. Deliver each module as usable, run short parallel periods at each switch-over, and avoid major cut-overs during peak trading. Big-bang launches are where Nigerian businesses most often lose both data and staff confidence.

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.

• Nigeria Data Protection Commission (NDPC)
• Paystack developer documentation
• Flutterwave developer documentation
• WhatsApp Business Platform — Meta for Developers
• PostgreSQL documentation
• Cloudflare Learning Center
• Baymard Institute e-commerce UX research