There is a conversation happening in boardrooms, finance offices, and IT departments across Kenya right now. Business owners and operations managers are asking the same question: which software should we use to run our company?
It sounds like a technology question. It is not. It is a compliance question, a payments question, a payroll question, and ultimately, a business survival question. And the way most businesses approach it is quietly costing them more than they realise.
The standard process looks something like this. A company evaluates a few systems based on a demo, a sales pitch, and a pricing sheet. They pick the one with the cleanest interface or the most familiar name. They go live, and for the first few months, everything feels manageable. Then reality sets in. The system does not talk to KRA. The POS does not understand M-Pesa. Payroll is being computed in a spreadsheet because the software has no concept of SHIF, the Affordable Housing Levy, or the NSSF tiered structure that Kenya moved to. The company is now running three or four systems where they expected to run one, with someone spending their days reconciling records between them.
This is not a rare story. It is the norm for businesses that choose software without asking the harder question first.
The harder question is not "which software has the most features?" It is "which software was actually built for how Kenya works?"
What It Means When a Feature Is "Available in Standard"
Before going further, this phrase deserves a serious explanation because it is one of the most misunderstood terms in enterprise software.
When something is available in standard, it means the vendor built it, owns it, maintains it across upgrades, and supports it as part of the core product. It is not a third-party connector. It is not a marketplace add-on that a developer built two years ago and has not touched since. It is not middleware that sits between two systems, passing data back and forth and failing unpredictably every time either system updates.
Standard functionality is the difference between a feature you can rely on in year three of your implementation and a workaround that falls apart the moment your vendor releases a new version.
For Kenyan businesses specifically, this distinction is enormous. The country has a compliance environment that changes regularly, payment infrastructure that is unlike anywhere else in the world, and a payroll landscape that has shifted dramatically over the past two years alone. A system that handles these things in standard is doing something genuinely different from one that requires you to bolt on integrations, hire developers to maintain connectors, or manually bridge the gap between your ERP and your obligations.
Odoo is not the only ERP available in Kenya. But it is, at this moment, the most complete answer to the question of what a Kenyan business actually needs out of the box.
Here is why, with the evidence to back it.
eTIMS: The Compliance Layer You Cannot Ignore
In March 2024, the Kenya Revenue Authority reached a milestone that changed the business software landscape in this country permanently. All businesses, whether VAT registered or not, were required to have onboarded eTIMS by 31 March 2024. Failure to comply means locking away your customers' expense claims, leaving them unable to deduct input costs when filing income tax returns.
Let that sink in. If your business issues invoices, as every business does, and those invoices are not going through a compliant eTIMS channel, your customers cannot claim the associated expenses. You are not just creating a compliance problem for yourself. You are creating a financial problem for every business that buys from you. That is the kind of thing that ends relationships with serious clients.
KRA has implemented the Electronic Tax Invoice Management System for tax collection. To submit documents through eTIMS, a business can use an OSCU that integrates with the existing Trader Invoicing System, such as the one provided by Odoo. The OSCU is used to validate, encrypt, sign, transmit, and store tax invoices.
What Odoo built here is not a surface-level workaround. It is a deep, technically rigorous integration with KRA's systems. Odoo 18 supports integration with eTIMS through the OSCU device in both Test and Production modes, and the system automatically generates a unique OSCU serial number based on the company's VAT number, ensuring the system is tied to the right business entity.
The practical implications of this for a business go well beyond just sending invoices. Kenya's tax system requires businesses to register products with KRA before they can sell or move stock. Once the product information is complete, Odoo automatically sends this data to eTIMS when a related operation, like a stock movement or invoice, is executed. This means product compliance is built into the normal workflow of selling and moving goods. It does not require a separate step, a separate system, or a separate person.
For businesses with multiple locations, the architecture goes even further. KRA requires independent invoice sequences per branch. Odoo manages these sequences individually per branch, so a retailer with three locations in different towns is not fighting to reconcile numbering schemes or manually segregate compliance data.
On the purchasing side, when goods are purchased, Odoo can automatically fetch the vendor bill from the eTIMS API servers daily and matches it with existing purchase orders. Once the bill is matched and validated, the user sends it to eTIMS, and KRA invoice number is then displayed directly in Odoo.
Think about what that means operationally. Your accounts payable process is integrated with your compliance process. The two things that most businesses run in completely separate workflows, invoicing and tax compliance, are the same action in Odoo.
For businesses that previously had this integration built by a third party, the maintenance cost and reliability risk were constant concerns. When Odoo owns this in standard, they maintain it every time KRA updates its API, changes its requirements, or shifts to a new protocol. That is not your problem to manage.
M-Pesa at Point of Sale: This Is Not a Nice-to-Have
Kenya's payment infrastructure is genuinely unique in the world, and anyone who has tried to implement a POS system here without accounting for M-Pesa has learned an expensive lesson.
The numbers are not subtle. Safaricom PLC's M-Pesa processes transactions that represent a significant share of Kenya's GDP on a daily basis. It is how Kenyans pay for everything from groceries to professional services to rent. Telling a customer at your point of sale that you do not accept M-Pesa is, in most retail and service contexts, turning away a substantial portion of your potential customers.
But the problem with M-Pesa at POS is not just accepting payments. It is what happens operationally when the payment is not integrated with the system. Without integration, the cashier receives the M-Pesa notification on a separate phone, manually confirms the payment in the system, and the transaction is logged against a cash or mobile money drawer with no direct link to the actual M-Pesa confirmation. The reconciliation happens later, sometimes much later, by a finance team combing through M-Pesa statements and matching them to system records one by one.
With proper integration, as soon as the customer authorises the payment on the mobile phone by entering the M-Pesa PIN, payment details are transmitted directly to the Odoo system and made available in POS instantly. From that point, the cashier can validate the customer order in a single click.
The downstream effects of this are real and significant. End-of-day reports are accurate because every payment is confirmed in the system the moment it is made. Cashier fraud becomes much harder to execute because no manual payment confirmation step exists. Reconciliation between the POS and the bank requires no manual matching. And for businesses with multiple POS stations or multiple branches, all of this happens consistently across every location.
Ecommerce and Getting Paid Online: The Missing Piece for Kenyan Digital Commerce
Ecommerce in Kenya has grown enormously over the past few years, but the growth has been uneven. Many businesses have beautiful online stores that quietly fail at the most critical moment, the checkout. A customer wants to buy, reaches the payment page, sees only options that do not work in Kenya or require steps that are unfamiliar, and abandons the cart.
The reason this happens so often is that many eCommerce platforms and ERPs were built for Western payment infrastructure. Visa, Mastercard, PayPal. These work for some customers in Kenya, but they exclude a large segment of the market. And they do not include mobile money at all.
DPO Pay by Network enables online payments for thousands of businesses across the continent, serving as a trusted solution for small and medium enterprises looking to digitise their operations. Following consistent feedback from clients and partners, Odoo identified seamless local payment processing as a key requirement, especially with the rapid growth of ecommerce and online transactions across Africa. DPO Pay is now fully embedded into the standard Odoo system, simplifying payment processes and enhancing the overall customer experience.
This is a formal partnership between Odoo and Network International, with DPO Pay becoming a native payment provider built directly into the Odoo platform. The integration eliminates the need for third-party connectors entirely. Through DPO Pay, a Kenyan business running Odoo ecommerce can accept M-Pesa, Airtel Money, credit and debit cards, and a wide range of mobile money options used across the continent, including MTN and PayFast, all in multiple currencies, without a single additional module or developer engagement. It is genuinely plug and play in the most literal sense of that phrase.
For a Kenyan business, the practical implication is that when a customer completes a purchase on your Odoo-powered online store, they can pay using cards or mobile money through a gateway that understands the African payment landscape, and everything that follows, the order confirmation, the stock reservation, the invoice, the accounting entry, happens automatically within a single system. The business does not need to check a separate payment dashboard to see if the money arrived. The ERP knows.
Payroll: The Compliance Landscape Has Changed Dramatically
There is no area of Kenyan business compliance that has shifted more significantly in recent years than payroll. Anyone running a business with employees in 2026 and relying on a system or process that was not updated to reflect the 2024 and 2025 legislative changes is already non-compliant in ways that carry real penalties.
Here is the current landscape in plain terms.
NSSF contributions in Kenya now operate under a tiered system. SHIF, which replaced NHIF effective October 2024, is charged at 2.75% of gross monthly salary from employees, with employers responsible for deducting and remitting these contributions to the Social Health Authority. The Affordable Housing Levy, introduced in March 2024, requires contributions of 1.5% of gross monthly salary from both the employee and the employer, totalling 3% per employee.
Effective February 2026, under Year 4 of the phased NSSF Act 2013 implementation, the maximum employee NSSF contribution rose to KES 6,480 per month, with the employer matching the same amount, bringing the total monthly maximum contribution per employee to KES 12,960. This is a significant increase from the earlier phases and directly impacts both net pay and employer payroll costs. SHIF contributions that are not remitted on time attract a penalty of 2% of the unpaid amount for each month they remain unpaid.
As of December 2024, contributions to both the Affordable Housing Levy and SHIF became allowable deductions in the calculation of taxable employment income. This means these amounts reduce the gross salary before PAYE is computed, lowering the overall tax liability for employees but also changing the calculation sequence that payroll software must follow.
This is not a trivial set of changes. PAYE calculations are now more layered than they were two years ago. The sequence in which deductions are applied, the rates for each statutory obligation, the deadlines for remittance, and the penalties for non-compliance, all of these have shifted. A business relying on static spreadsheets or software that has not been updated is computing payroll incorrectly, and the exposure grows with every month of continued non-compliance.
What Odoo provides is a payroll module with Kenyan localization that can be configured to reflect these rates and structures. For a Kenyan business, having payroll within the same system as HR, accounting, and operations means that a salary change, a new hire, or a payroll run updates the accounting records without manual journal entries. The statutory deductions are computed against the correct gross amounts, remittance reports are generated for the iTax portal and NSSF systems, and the financial impact is reflected in the accounts immediately.
For businesses that have historically kept payroll in one system and accounting in another, the cost of that separation is most visible at month-end: the time spent reconciling the payroll summary against the GL, tracing discrepancies, and recreating reports that both systems should have generated automatically.
Accounting Localisation: Starting from Kenya, Not from a Generic Template
When a new company implements an ERP in Kenya using a system without local accounting localisation, the first months of the project are spent building the chart of accounts from scratch, configuring tax codes for VAT and withholding tax, setting up report formats that make sense for Kenyan regulatory filings, and generally adapting a generic system to local reality.
Odoo introduced the Kenyan chart of accounts as part of its localised offering for the market. This means an implementation in Kenya starts from a structure that already reflects local accounting norms, not from a blank ledger that needs to be rebuilt before any real work can begin.
The VAT configuration, the tax codes that feed into eTIMS, the withholding tax structures, all of these are already part of the localisation package. That does not mean every configuration is perfect out of the box, because every business has nuances, but it means the baseline is set correctly from the start. The implementation team spends time on the business, not on rebuilding accounting fundamentals.
For multi-branch operations, the financial consolidation is handled within the same Odoo instance. The parent company can view all branch financials, inter-company transactions are managed within the system, and eTIMS compliance is maintained at the branch level as described earlier. Businesses running multiple entities or locations in Kenya can manage everything without additional software or complex export-import routines between systems.
Data Protection: The Compliance Conversation Most Businesses Are Not Having
When businesses evaluate ERP systems in Kenya, data protection compliance rarely makes the shortlist of evaluation criteria. This is a mistake that is becoming more expensive to make.
The Data Protection Act came into effect in Kenya in November 2019, ushering the country into a new data privacy dispensation that aimed at ensuring Kenyans had enforceable privacy rights over their personal information, while providing clear guidelines for private and public institutions to handle user data with care.
Section 18 of the Data Protection Act, 2019 and the Data Protection (Registration of Data Controllers and Data Processors) Regulations, 2021 require that all public and private organisations and individuals processing personal data register with the ODPC. Any data controller or processor that processes personal data without registering, or provides false or misleading information, or fails to renew a certificate of registration and continues to process personal data after its expiry, commits an offence and is liable to imprisonment for a term not exceeding 10 years or a fine not exceeding three million shillings or both.
This is serious legal exposure, and most Kenyan businesses either do not know about it or have not applied it to how they think about their software infrastructure.
Your ERP is one of the highest concentrations of personal data in your business. It holds employee records, customer information, payment histories, contact details, and in many cases, health and financial data. The question of who has access to that data, where it is hosted, how it is protected, and whether the software vendor and implementation partner handling it are operating within a compliant framework is not a theoretical question. It is a legal one.
This is precisely why Odoo's official registration with Kenya's Office of Data Protection Commissioner, announced in March 2025, matters for any Kenyan business considering the platform. Odoo is on the ODPC's register of compliant data handlers, which you can verify directly at odpc.go.ke/registered-data-handlers.
That registration has a direct legal implication for your business. The ODPC explicitly identifies CRM and ERP solution providers with access to personal data as data processors, subject to the same registration and compliance requirements as any other entity handling personal data in Kenya. When your vendor is registered, the compliance chain is intact. When they are not, you as the data controller are directly accountable for the gap, regardless of whether you knew about it.
Choosing an ERP partner that is registered with the ODPC, that builds access controls, role-based permissions, and audit trail capabilities into the implementation, and that can demonstrate active compliance rather than just claiming it, is part of your own compliance posture. Registration alone does not make data safe, but it is the minimum threshold that establishes whether your vendor takes the obligation seriously at all.
For businesses that want to be able to demonstrate to their clients, their employees, and any regulatory inspection that their data environment is managed responsibly, the choice of ERP platform and implementation partner is not separate from data compliance. It is central to it. And on this specific point, Odoo has done the work.
The Real Cost of Running Disconnected Software
There is a conversation about software cost that most businesses have incorrectly, because they frame it as a question of license fees. The license fee is the visible part of the cost. The invisible part is usually far larger.
Think about what it actually costs to run five systems that do not talk to each other.
There is the staff time spent entering the same information in multiple places. A customer record created in CRM needs to be recreated in accounting software. A purchase order in procurement needs to be manually matched to an invoice in accounts payable. A payroll run computed in one system needs to be reflected as a journal entry in another. None of this creates value. All of it consumes time, and the time has a real cost that never appears on the technology invoice.
There is the cost of errors. Every time data crosses a system boundary manually, the probability of an error increases. A wrong amount, a mismatched date, a duplicated record, these are not trivial annoyances. They cascade. A reconciliation error in accounts receivable affects cash flow forecasting. A payroll computation error affects an employee's take-home pay and potentially triggers a statutory compliance issue. A stock discrepancy between the inventory system and the accounting system means neither figure can be trusted.
There is the cost of reporting delays. A business running multiple disconnected systems cannot produce a real-time view of its financial position, its stock value, or its sales pipeline without someone first assembling the data from each system into a spreadsheet. By the time that report is ready, the data is stale and the decisions it informs are based on a picture that no longer reflects reality.
And there is the cost of integration maintenance. Every connection between two systems needs to be built, tested, and maintained. When either system updates, the integration may break. When the integration breaks, data stops flowing between the systems, and the business may not even notice immediately. By the time the problem surfaces, the impact has compounded.
An ERP that genuinely unifies operations does not eliminate these costs by adding more technology. It eliminates them by removing the system boundaries that create them in the first place. One database. One customer record. One inventory figure. One set of accounting entries. One source of truth for the entire business.
Odoo's Commitment to the Kenyan and African Market
There is a practical question worth asking about any ERP localisation: who is maintaining it, and how close are they to the market it serves?
For Kenya, the answer matters because the compliance environment here does not sit still. KRA updates eTIMS requirements. The SHA replaced NHIF and introduced new contribution structures. The Affordable Housing Levy arrived with its own calculation rules and remittance deadlines. A vendor that relies on external partners to relay these changes, or discovers them months later through customer complaints, is always one statutory update behind.
Odoo KE LTD operates out of Nairobi as the company's African headquarters. That physical presence is what produced the Kenya-specific investments described throughout this article: eTIMS integration, Kenyan payroll localisation, DPO Pay, M-Pesa at point of sale, and the local chart of accounts. These did not come from a product team building features in the abstract. They came from being in the same market, talking to the same businesses, and facing the same regulatory changes that you are facing.
For a business evaluating whether to build its operations on a platform, the question of vendor proximity to your compliance environment is not a minor consideration. It is part of the long-term cost of ownership.
Asking the Right Question
The ERP conversation in Kenya has changed. It used to be "which software is most affordable?" or "which one does our accountant already know?" Those were reasonable starting points when the compliance environment was simpler and payment infrastructure was more uniform.
In 2026, the starting question has to be: can this software handle Kenya out of the box?
Can it submit invoices to eTIMS natively, across multiple branches, for both sales and purchases, including stock movements? Can the POS accept M-Pesa with an STK push that confirms directly in the system? Can the ecommerce checkout accept mobile money and cards through a gateway that works across Africa? Does payroll compute PAYE, NSSF tiers, SHIF at 2.75%, and the Affordable Housing Levy in the correct sequence, with the correct allowable deductions applied before PAYE, against a deadline calendar that matches the 9th of each month? Is the vendor registered appropriately under Kenya's data protection framework?
If the answer to any of those questions is "we have a connector for that" or "we can build that," the cost of the software just went up. The visible cost, in time and money, of building and maintaining what should already be there.
For businesses evaluating their options honestly and asking these questions with the seriousness they deserve, Odoo answers them all from within a single, unified platform.
That is the argument. Not that Odoo does everything. But that for Kenyan businesses, it does the important things together, in standard, and with a team in Nairobi that understands why those things matter.
If Your Business Is Evaluating ERP Right Now, Here Is the Honest Starting Point
Do not start with a demo. Start with a checklist of the things your business cannot compromise on. eTIMS. M-Pesa. Payroll compliance. Online payments. Data protection. Then ask every vendor on your shortlist to show you, not tell you, how each of those things works in their system, natively, today.
If the answer involves a third-party module, a connector, a developer quote, or a promise that it is "on the roadmap," you have your answer.
At ABN Consulting Group, we implement Odoo for businesses across Africa as an official Odoo Partner, and this exact conversation is one we have at the start of every engagement. The compliance requirements are not abstract. They are specific, they are dated, and they carry real penalties. Our job is to make sure the system you go live on is already built for Kenya, and that the implementation itself does not leave gaps between what the software can do and what your business actually needs it to do.
If you are running a Kenyan business and want an honest assessment of where your current systems stand against the compliance requirements outlined in this article, reach out. The conversation costs nothing. The cost of continuing with the wrong system, however, keeps compounding every month.