Buying an ERP is a business design decision, not a software shopping exercise. The right system should make the organisation’s important work more visible: what has been sold, what is owed, what is in stock, what has moved between locations, and which approvals are still outstanding.
For an East African business, the decision also has to account for connectivity, mobile-money workflows, tax and e-invoicing obligations, local support, and the practical reality that people may work from phones, branches, warehouses, and offices with different network quality. A demo can show a polished screen. It cannot, by itself, prove that the system will survive a busy month-end.
Start with the work, not the feature list
Write down the five workflows that currently create the most delay or uncertainty. They might include:
- issuing a customer invoice and following up the receivable;
- receiving stock, transferring it to another branch, and confirming delivery;
- recording a mobile-money collection and matching it to the customer account;
- approving a purchase without losing the supporting document; and
- producing a monthly management report without rebuilding it in a spreadsheet.
Ask each vendor to demonstrate those workflows with your terms, approval steps, currencies, branches, and exceptions. A generic tour of dashboards is less useful than a test of one complete transaction from source document to report.
Compare the architecture in plain language
Cloud computing has a specific meaning: the customer uses shared computing resources over a network, with on-demand access and defined service characteristics. That does not mean every cloud product has the same security, availability, backup, or exit arrangements. The NIST definition is a useful baseline, while the National Cyber Security Centre’s provider guidance provides questions for assessing responsibility, resilience, and supplier risk.
During evaluation, ask:
- Where is the service hosted, and which party is responsible for each security control?
- How are backups made, tested, retained, and restored?
- What happens when a user loses connectivity during a transaction?
- Can the business export its master data and transaction history in a usable format?
- Which features are included in the quoted plan, and which become paid add-ons?
The answer should be specific enough for a finance lead and an operations manager to check. “The platform is secure” is not a control description.
Test the controls, not only the convenience
An ERP should reduce repetitive work without making errors harder to detect. Test whether the system records who prepared, approved, posted, changed, and reconciled a transaction. Check whether posted entries can be corrected through a traceable reversal rather than silently overwritten. Confirm that roles can be separated so that one person does not prepare, approve, post, and reconcile the same payment without review.
The Technology Code of Practice is a useful general checklist for user needs, security, privacy, interoperability, sustainability, and open standards. It is not East African law, but the decision disciplines are transferable. Local statutory and tax requirements still need confirmation for the countries in which the business operates.
Build a total-cost view
Compare the cost of operating each option for three years, not just the monthly subscription. Include:
- implementation and data-cleaning time;
- user training and replacement-staff onboarding;
- integrations for banks, mobile money, payroll, or e-invoicing;
- support tiers and response times;
- additional branches, users, storage, and reporting;
- downtime, manual workarounds, and reconciliation effort; and
- exporting data if the business later changes provider.
If a supplier cannot explain which assumptions drive the price, mark the estimate as provisional. A low licence fee can still be expensive when every exception requires a custom project.
Run a short, evidence-led pilot
Choose one branch or operating unit and one reporting period. Give the vendor a controlled sample: opening balances, a few customers and suppliers, representative stock, one purchase, one sale, one return, one transfer, and one reconciliation. Agree beforehand what “working” means.
Useful pilot measures include:
- time from source transaction to approved report;
- number of manual re-keying steps;
- unmatched items after reconciliation;
- time required to train a new operator;
- successful export and restore of a test dataset; and
- number of unresolved exceptions at pilot close.
The pilot should include failure cases. Disconnect a test device, enter a duplicate reference, reject an approval, reverse a transaction, and ask for the audit trail. These are normal operating conditions, not edge cases.
Questions to ask before signing
Request written answers to the following:
- Which country-specific tax, e-invoicing, payroll, and reporting features are live today?
- Which integrations are supported in production, and who maintains them?
- What is the service-level commitment and escalation path?
- What is the data-retention and deletion process at contract end?
- Can the vendor provide a reference customer with a similar branch and transaction profile?
- Who owns configuration, training materials, and the chart-of-accounts mapping?
The GOV.UK service guidance on choosing technology makes the same core point: start with user needs, constraints, and outcomes, then select technology that meets them.
Kraal Code can be assessed against this framework as a modular cloud ERP for African organisations. The decision should still be based on a documented workflow pilot, written country requirements, and a clear handover plan. Those three pieces protect the buyer from choosing a system that looks right in a demo but does not fit the work.
Red flags in a vendor response
Be careful when a vendor:
- avoids showing a rejected approval, reversal, duplicate callback, or failed export;
- quotes a custom integration without naming the owner, test environment, support boundary, or renewal cost;
- describes backup as a checkbox without explaining restoration tests;
- cannot explain how a user is removed when they leave the organisation;
- promises country compliance without identifying the applicable authority, version, or customer responsibility; or
- relies on a long implementation before the buyer can test one complete workflow.
These points do not prove that a product is unsuitable. They identify questions that deserve a written answer before the contract is signed.
Use a simple decision scorecard
Give each vendor a score from one to five for each dimension and record the evidence behind the score:
| Dimension | Evidence to request |
|---|---|
| Workflow fit | A pilot of one sale, purchase, receipt, transfer, and close |
| Finance controls | Roles, approval history, period lock, reversal, and reconciliation |
| Operations | Location, stock, order, procurement, and exception workflows |
| Connectivity | Behaviour during slow or unavailable network conditions |
| Security and continuity | Responsibilities, backup, restoration, incident route, and access review |
| Integration | Current provider, country, endpoint, credentials, monitoring, and support |
| Commercial fit | Three-year cost, implementation assumptions, add-ons, and exit export |
| Adoption | Training plan, local support, documentation, and new-user onboarding |
Do not let a high score on visual polish cancel a failed finance-control test. Weight the dimensions according to the risk and work of the organisation. Kraal Code’s reporting capability and contact route can be used as starting points for an evaluation conversation, not as a substitute for the pilot.
Make implementation part of the purchase
Ask for the implementation plan before the purchase order: data owner, chart-of-accounts mapping, configuration decisions, training groups, pilot dates, acceptance evidence, support handover, and rollback or contingency steps. The plan should say what the customer must provide and what the supplier will deliver.
The best decision is sometimes to delay. If the vendor cannot demonstrate the workflow or the business cannot provide a clean starting dataset, a short preparation phase may be cheaper than a rushed launch.
A buyer worksheet for the first meeting
Bring a one-page process map to the vendor. List the people involved, the starting document, the decision points, the system record, the report produced, and the exception that commonly interrupts the flow. Add the approximate monthly volume and the number of locations. This gives the vendor enough context to show the right work and gives the buyer something concrete to compare.
For finance, include one invoice, one receipt, one supplier bill, one payment, one credit note, one bank or mobile-money statement, and one month-end adjustment. For operations, include one stock receipt, one transfer, one return, and one item that is unavailable. Ask where each document lives after the transaction and who can review it.
Do the same exercise with a branch manager and an operator. If the system only works when the most senior person is present, the operating model is not ready. A good evaluation leaves each role with a clear next action and a visible escalation route.
The final decision record should state the chosen option, rejected alternatives, assumptions, unresolved gaps, owner, review date, and implementation evidence required before go-live. That record is useful even when the answer is to keep the current tools for another quarter.
Keep the signed decision with the procurement file. It gives the implementation team a reference when a requested change adds cost, alters a control, or moves the project outside the original workflow and country assumptions.
