ERP Implementation and Custom Development in Kenya
CloudSpinx implements and extends ERP systems for businesses, SACCOs and institutions in Kenya and across East Africa, on Odoo, ERPNext and Frappe. Implementation and custom development sit with the same engineers here, which matters because the first honest question on any ERP project is how much of what you want is configuration you should not be paying a developer for. Kenyan localization is part of the build rather than an add-on, so KRA eTIMS, VAT, PAYE, NSSF, the Housing Levy and SHIF are handled from day one. Both the implementation and the custom work are quoted per engagement after a discovery call.
Who we build for
- 14organizations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our ERP Service
Every engagement covers the full scope: no hidden extras, no upselling.
Odoo implementation
Accounting, inventory, sales, purchasing, manufacturing, HR and e-commerce configured against how your business actually works, not against the demo data.
ERPNext and Frappe implementation
The open-source route: GPLv3 at the ERPNext layer, no per-user license, and a strong fit where budget is tight or you have developers who want to own the customization.
Custom Odoo module development
Python modules that inherit the standard models instead of editing them, so your logic survives the next major version. The distinction between a module and a fork is the whole difference between an upgradeable system and a dead end.
Odoo customization
Views, reports, approval chains, automated actions and server-side rules built to match how the business actually runs. Most requests that arrive as development work land here, and cost a fraction of a module.
Bespoke business systems
Where no ERP genuinely fits: fleet and logistics operations, out-grower and aggregation schemes, SACCO and member systems, school and institutional management. Built on a framework rather than from nothing.
Kenyan payroll
PAYE bands, NSSF tiers, the Affordable Housing Levy and SHIF at 2.75% of gross with no cap. Payslips, statutory returns and the reconciliation your accountant needs.
KRA eTIMS integration
Invoices transmitted to KRA from inside the ERP rather than re-keyed into a separate portal, with credit notes and the failure cases handled.
M-Pesa reconciliation
Paybill and till transactions matched against invoices automatically, with the unmatched ones surfaced for a human instead of quietly ignored.
Data migration
From QuickBooks, Sage, Tally, spreadsheets or a custom database. Cleaned, validated, reconciled against your trial balance, and signed off before go-live.
Custom reporting and dashboards
The board pack, the regulator return, the daily operational view somebody currently rebuilds by hand every morning. Usually the fastest payback in a custom scope and the first thing we look for.
Upgrade, porting and project rescue
Taking a custom module across a major version, or reading a stalled build and telling you what is salvageable. Both quoted as their own engagements, because both usually are one.
Training and adoption
Department-by-department training, written and recorded, plus supervised go-live. Adoption is where ERP projects fail, so it gets real time rather than a final-week afternoon.
Technologies we use
Configure it, extend it, or build it
Three figures that decide an ERP project before the code does: how much of the system you are actually paying to write rather than inherit, what the platform's license lets you do with a custom module afterwards, and the bill that arrives three years later. Module scope and effort come out of the specification phase.
Three ways to get a custom ERP, and how much of it you end up owning
Most buyers asking for custom ERP development want the middle column and are quoted the right-hand one. The accent blocks are the only parts anyone writes for you. Everything below the seam already exists, is maintained by someone else, and is free. Build from scratch and you have quietly bought the whole stack, including the plumbing nobody demos.
- written for you
- already exists, maintained by others
- yours to carry permanently
The core platform's license decides what you can do with the module you paid for
Nobody raises this before the contract and it is the question that matters if you ever plan to sell the thing. If the module only ever runs inside your own business, all three cores are equivalent and you can stop reading. If you intend to resell it to the next SACCO or the next school, the core you picked on day one has already decided the answer. This is how the licenses read, not legal advice: a lawyer signs off before you productize anything.
- no obligation on you
- permitted, with a condition
- the source goes with it
The bill a custom ERP module sends you three years after you paid for it
Odoo gives each major release three years of support and ships a new one every year, so staying supported means crossing a major version. Its upgrade service is explicit about what happens next: a database containing custom modules cannot be upgraded until a version of your custom modules is available for the target version. That port is not in the build quote you are comparing, and it recurs. Every module you agree to is a permanent line item, which is the real reason we argue you into fewer of them.
- supported, and what you paid for
- unsupported, and what nobody quoted you
Read across the three figures and the argument is one sentence: every block of accent color is a permanent commitment, so the cheapest custom ERP is the one where that block is as small as your business genuinely allows. Our first job on a build is arguing that block smaller, which is a strange thing to sell and the reason clients stay.
What an ERP costs in Kenya, implemented or custom
The software license is usually the smallest line, and on the open-source cores it is zero. What you are actually paying for is the configuration, the data migration, the training and whatever genuinely has to be written, and those scale with how complicated your business is rather than with how many people work there. A ten-person distributor with multi-currency, batch tracking and three warehouses is a bigger job than a forty-person services firm with straightforward invoicing.
What moves the number on an implementation
Module count and how far each is customized, user count on Odoo Enterprise (ERPNext has no per-user fee), the state of the data you are migrating, how many integrations you need built, and how many people need training. Two things surprise buyers: cleaning the data is often the largest single task, and every custom module is a permanent maintenance commitment at every future upgrade.
Odoo licensing, stated plainly
Odoo Community is free and open source. Odoo Enterprise is a paid per-user subscription and includes the modules and the studio tooling most businesses end up wanting. ERPNext is GPLv3 throughout with no per-user cost at all. Any implementer who quotes you Odoo without making clear which edition, and therefore whether you have a recurring per-user bill, has left out the part that decides your five-year cost.
The number the market quotes for custom work, and what it leaves out
Kenyan ERP software development companies do publish bands: one prominent local ERP page quotes basic systems from KES 150,000, mid-range from KES 200,000, and its top band from KES 700,000 upward. Treat those as build-only figures, because that is what they are. None of them price the port at the next major version, and on Odoo that arrives on a schedule you do not control. Compare quotes on five-year cost of ownership or you are comparing the cheap half of the number.
Why we quote a specification first
On anything beyond a single module we sell the specification as its own small piece of work, and you can take it to another developer. That sounds like a way to lose the build. It is actually the only honest way to price one, because a fixed price against a vague scope is either padded to cover the unknown or renegotiated halfway through, and you pay for the unknown either way.
Configure it, extend it, or build it
This is the question we ask first and it is the one that saves clients the most money, so it is worth being blunt about the pattern. Most requirements that arrive described as custom development are a standard module configured differently, a report nobody built, or a process that could be changed more cheaply than it could be automated. Genuinely custom work exists, we do plenty of it, and it is a smaller fraction of what comes in than anybody expects.
- It is configuration if the data already fits the standard models and what you want is different fields, different views, a different approval path or a report. This is most of it, and it is days rather than weeks.
- It is a custom module if the business has an object the ERP has no concept of, or a calculation nobody else in your industry does the same way. An out-grower payment cycle, a member dividend rule, a fleet job costing model.
- It is a bespoke system only when the operation is genuinely not an ERP shape at all, and the ERP would be a shell around your real application. Rarer than the market implies, and when it is true it is obvious within an hour.
- It is a process problem more often than anyone wants to hear. If the requirement exists because two departments will not share a number, software will encode the argument rather than settle it.
Odoo, ERPNext or Frappe, and how we actually choose
We implement and build on all three and hold no reseller incentive in any direction, which is the only position from which this comparison is worth reading. The choice is usually decided by how much standard ERP you actually need underneath whatever is specific to you.
- Odoo when you want a polished interface, a large app ecosystem and manufacturing or e-commerce depth, and can carry a per-user subscription on Enterprise. The deepest pool of ERP developers in Kenya, so you are not locked to one supplier, and LGPLv3 keeps a custom module's licensing flexible.
- ERPNext when you want a complete ERP with no per-user cost and bounded customization. Strong fit for NGOs, member organizations and public bodies where an open license also helps procurement. Adding staff does not add cost.
- Frappe Framework alone when the honest answer is that you are building an application, not extending an ERP. You get the data model, permissions, workflow engine, REST API and admin UI for free, and you skip the ERP you were never going to use.
- None of them if the requirement is really one thing. If you need invoicing and nothing else, an accounting package is cheaper, faster and easier to leave. ERP earns its cost when several functions need to share one set of data.
Kenyan localization that is actually current
This is where most implementations quietly go wrong, because statutory rules here change faster than ERP templates do. NHIF no longer exists. The Social Health Authority took over in October 2024, and the employed deduction is SHIF at 2.75% of gross salary with no upper cap and a minimum of KES 300 a month, taken before tax. If your payroll module, or your implementer's documentation, still says NHIF with income bands, it is out of date and your filings will be wrong.
What custom code inherits the moment you write it
A custom module that touches money in Kenya inherits every statutory rule the standard system was already handling, and this is the most common way a bespoke build goes quietly wrong. Write a custom payroll calculation and you now own PAYE bands, NSSF tiers, the Housing Levy and SHIF. Write a custom invoice flow and you own eTIMS transmission including credit notes and the case where KRA is unreachable mid-invoice. This is the strongest argument for building on a core someone else keeps current: the parts that change by statute should not be the parts you wrote.
- PAYE with current bands and reliefs, and the interaction with pre-tax deductions handled in the right order.
- NSSF tiered contributions under the phased schedule, which has moved repeatedly and needs checking each cycle.
- SHIF at 2.75% of gross, uncapped, pre-tax, replacing NHIF.
- Affordable Housing Levy on gross, employer and employee portions.
- KRA VAT with standard, zero-rated and exempt handled distinctly, because treating zero-rated and exempt the same is the most common configuration error we find.
- eTIMS invoice transmission from inside the ERP, including credit notes and what happens when KRA is unreachable mid-invoice.
The integrations that decide whether an ERP works here
An ERP in Kenya lives or dies on two connections. The first is M-Pesa: paybill and till payments have to reconcile against invoices automatically, or your finance team spends the first week of every month matching statements by hand and you have bought an expensive spreadsheet. The second is eTIMS, because an invoice that exists in the ERP but not at KRA is a compliance problem discovered at audit. Bank statement feeds, Airtel Money and payment gateways follow the same principle: if a transaction has to be typed in twice, the second copy will eventually be wrong. Where the integration needs work on the application side, that runs through our development team rather than being subcontracted out.
The license decides who ends up owning your custom module
Almost nobody raises this before a contract is signed, and it is the detail that decides whether the module you paid for is an asset you can sell or a cost you can only use. The three cores we build on carry three different licenses and they are not interchangeable. Odoo Community is LGPLv3, which permits a separately licensed module alongside it, which is precisely why a market in paid closed-source Odoo apps exists. ERPNext is GPLv3, so a module that is a derivative work carries the same license when you distribute it. The Frappe Framework underneath ERPNext is MIT, which places no obligation on you at all.
When none of this matters
If the module only ever runs inside your own business, no copyleft obligation is triggered by any of the three, and you should pick a platform on fit and on who can maintain it. We say this rather than using the license as a reason to steer you, because for most clients it genuinely is not a factor and treating it as one would be a sales tactic.
When it decides the platform
If there is any chance you will sell the system to the next SACCO, the next school or the next distributor, the core you choose on day one has already answered the question. We ask about it in the first conversation for exactly that reason, and we put the answer in writing before development starts. This is how the licenses read rather than legal advice, and anybody planning to productize should have a lawyer confirm it.
Where a standard ERP genuinely does not fit
These are the sectors where custom development is the right call rather than the expensive one, and they have a shape in common: a core operational process that is the business itself, priced or regulated in a way no global ERP models.
- SACCOs and member organizations. Share capital, member deposits, dividend and interest rebate calculations, guarantor chains and loan appraisal rules. SASRA reporting alone justifies custom work, because the return has to come out of the system rather than out of somebody's spreadsheet at quarter end.
- Fleet, transport and logistics. Trip costing, fuel and driver reconciliation, maintenance scheduling against mileage rather than dates. We have built an operational system at fleet scale and the write-up is on our case studies page.
- Agriculture and out-grower schemes. Collection by weight at multiple points, quality grading that changes the price after the fact, deductions for inputs advanced months earlier, and payment cycles no standard payables module expects.
- Schools and institutions. Fee structures with terms, transport zones, bursaries and arrears that behave nothing like an invoice, plus the reporting a board and a ministry both want in different shapes.
Why ERP projects fail, and what we do differently
The failure pattern is consistent and it is almost never technical. The system gets configured to match a process nobody has questioned in ten years, so it automates the inefficiency. Training happens in the last week when the budget is nearly gone. One department never adopts it and keeps its own spreadsheet, so the data is wrong and everyone loses trust in the reports. Six months later the ERP is a very expensive invoicing tool.
Process first, configuration second
Discovery maps what actually happens, including the workarounds people are not going to mention in front of their manager. Then we ask which of those steps should survive. An ERP is a chance to fix a process, and configuring around a broken one is how you end up paying to make it permanent.
One department at a time
Big-bang go-lives across every module on the same Monday concentrate all the risk into one day, and when something breaks nobody can tell which change caused it. Phasing by function costs slightly more in project management and saves considerably more in disruption. Finance usually goes first because it validates the data everything else depends on.
When we tell clients not to buy, and not to build
A good share of the businesses who ask us for an ERP, or for a custom one, should not buy it yet. Saying so costs us a project and wins the relationship.
- Under about fifteen staff with one main activity, the honest answer is usually a good accounting package plus a decent CRM. ERP overhead is real and it does not pay back at that size.
- When the standard module does it and nobody checked. This is the most common outcome of a first call about custom development. We would rather spend an afternoon showing you the configuration than a month building around it.
- When the real driver is a report. Wanting a number nobody can currently produce is a reporting job, often a week of work. It arrives described as a new system surprisingly often.
- If nobody internally will own it, do not start. An ERP needs a person on your side who can decide how a process should work and make it stick. Without that, the project stalls in configuration and the cost keeps running.
- When you cannot carry the maintenance. Every custom module is a permanent commitment at every future upgrade. If the budget exists for the build and not for the years after it, change the process and keep the system standard.
- If you are mid-restructure, wait. Configuring an ERP, or writing code, against an org chart that is about to change means paying to build it twice.
What you own at handover
The database, the source for any custom module in a repository you control, the commit history, the configuration documentation, the data model, the migration scripts and the training material. All three platforms we work on are open source at the core, so your data and your customizations are portable by construction rather than by our goodwill. We also write down, before development starts, which major version a module was built against and what porting it will involve, because that is the cost nobody quotes and it is the one that decides whether you are still happy with this decision in three years. Handover documentation is written for an unfamiliar developer rather than for us, which is deliberate and occasionally expensive. Ongoing upgrades, minor customization and user support run on a monthly retainer if you want one, and plenty of clients take their own team through it instead. Platform hosting, if you need it, runs through our managed hosting.
Tell us how the business actually runs
Enough for us to size the work honestly and to tell you which parts are configuration rather than development. The questions about process and data decide the price; the one about reselling decides the platform.
Ready to discuss ERP?
A 30-minute scoping call, free, and it commits you to nothing.
How Every ERP Engagement Starts
Discovery and honest triage
What the process actually does today, including the workarounds. Then the split: what is configuration, what is a report, what genuinely needs writing. You get that answer even if it means there is no build in it for us.
Specification and platform choice
Module scope, the data model, the integration contracts, and the platform decision with the licensing consequence stated. On custom work it is priced as its own piece of work, and yours to take anywhere.
Configure, build and reconcile
Core modules built against your processes and custom modules written against the standard models rather than editing them. Data cleaned, imported and reconciled against your trial balance before anything goes live.
Train, launch and plan the port
Department-by-department training, a supervised go-live by function rather than all at once, intensive support through the first month-end close, and the written note of what the next major upgrade will need.