ERP Business Analyst Kenya

Writing eTIMS into the requirement register

Tax invoicing through eTIMS changes what a Kenyan ERP has to do with every sales document, yet tender documents often reduce it to a single line asking whether the product "supports eTIMS". That question invites a yes and reveals nothing. In my ERP requirements gathering work, I break it into statements a vendor has to answer specifically:

• which document types leave the system for transmission, including credit notes, returns and invoices in foreign currency
• which customer and item fields must be complete before a document can be submitted, such as the customer's PIN where your advisor says it is required
• where the validation details returned are stored and how they appear on the printed or emailed document
• what a user sees when transmission fails, who is alerted and how the document is resubmitted without duplication
• which report shows documents still pending, rejected or accepted for a chosen period

The applicability and technical rules are set by KRA and can change, so the tax content of each line is confirmed with your tax advisor; I do not interpret tax law. My contribution is precision: each line gets an owner plus a matching test case, so the integration route chosen for Zoho, Odoo, ERPNext or Dynamics 365 is proven with your own documents.

Specifying how mobile money and bank receipts are handled

Collections in Kenya rarely follow one neat path. A distributor may settle part of a statement through a business pay number, top up by bank transfer and leave a phone number in place of an invoice reference. If those cases are not described in the BRD, the vendor configures the textbook case and your finance team keeps its daily matching spreadsheet.

I document receipts as rules, not as a feature request. The BRD states which collection numbers and bank accounts belong to which entity or branch, which reference format customers are asked to use, how incoming payment data reaches the ERP and how often, when the system may allocate automatically and when a person must decide. It also describes the exceptions: overpayments, reversed transactions, payments from a third party on a customer's behalf and receipts nobody can identify.

Outgoing payments get the same treatment. Agent commissions, supplier payouts and customer refunds through mobile money each need an approval path and a record that finance can reconcile. Every rule ends up in a test script with sample transactions, so acceptance testing proves the receipt flow before go-live instead of after the first month-end. The method is described further on my ERP business analysis page.

Requirements for route sales, depots and weak coverage

Many Kenyan companies run part of their business away from the office: sales reps visiting shops, drivers delivering to rural customers, depot staff receiving stock in towns where mobile data drops in and out. A requirement document written from head office tends to miss these users, and they are often the ones who decide whether the system is actually adopted.

I interview field and depot staff directly, by video or phone, and record what they need to do and where they are when they do it. The analysis covers which tasks must work with no signal, such as taking an order, confirming a delivery or counting stock; how long a device may stay offline before data is at risk; what the user sees when a price or credit limit has changed since the last sync; and how conflicts are flagged when two people update the same record.

These needs become explicit requirements in the BRD and scored lines in the fit-gap matrix, because mobile and offline capabilities differ between products and between editions of the same product. Hosting location and the handling of personal data under Kenya's data protection law are logged as open points for your IT lead and legal counsel, so the platform decision takes them into account rather than discovering them later. For delivery beyond the analysis stage, see the Kenya ERP consultant page.

Currency, group entities and the reports management expects

Reporting requirements are usually written last and tested least, which is how a new system can go live while management still rebuilds figures in Excel. For Kenyan businesses that buy or sell in dollars, or that report on sister companies in neighboring countries, the reporting requirement deserves early attention.

I start from the reports directors already use and ask what decision each one supports. From there the BRD records which figures must appear in shillings, which in the original transaction currency, which exchange rate source applies, and how realized and unrealized differences are presented. Your accountant sets the policy; the requirement makes the ERP follow it consistently. For groups, I list the entities in scope, shared and local master data, intercompany transactions and the consolidated views head office expects, flagging where another country's tax or invoicing rules may need separate local advice.

Each report gets a short specification: purpose, audience, filters, layout and the source of every column. That level of detail lets a vendor show the actual report in a demonstration rather than a generic dashboard, and it gives testers something concrete to sign off. My ERP process mapping service covers how the underlying processes are drawn.

The document set you receive, and language on the ground

At the end of the analysis you own a complete, platform-neutral document set: current and target process maps, a numbered requirement register, a business requirements document, master data definitions for customers, suppliers and items, a fit-gap matrix for every shortlisted product, a scope note for migrating data from your current accounting tool, and acceptance scripts tied back to requirement numbers.

Everything is written and discussed in English. If some field or warehouse staff prefer Kiswahili for training notes or quick guides, your own team can adapt those materials, and I keep the step-by-step instructions plain enough to translate without losing meaning.

Remote delivery shapes how the documents are produced. Workshops are recorded where you agree, drafts sit in a shared folder, and comments are resolved in writing rather than in corridor conversations. When the implementer later asks why a requirement exists, or a new finance manager joins mid-project, the reasoning is there to read. For a wider view of my work with Kenyan businesses, including growth and lead generation, visit the Kenya page.