eTIMS, PAYE, NSSF & SHIF: Compliance Features Your ERP Must Have
eTIMS, PAYE, NSSF, SHIF, housing levy, withholding — the compliance features that must be built into your ERP, what each one actually requires, and the test questions for vendors.
Kenyan compliance is not a report you print at year-end; it is a property of every invoice you issue and every payslip you run. When compliance is built into the system, it happens as a by-product of normal work. When it is bolted on — spreadsheets beside the system, manual portal entry, "we'll file it later" — every deadline is a scramble and every rule change is a risk. Here is what "built in" concretely means, feature by feature.
eTIMS: electronic invoicing
KRA's eTIMS regime means sales invoices are transmitted electronically and buyers increasingly refuse non-compliant invoices — they can't claim the input VAT without them. Your system must:
- Generate compliant invoices from normal sales flow — POS and invoicing alike, not a separate re-entry step.
- Handle credit notes and corrections through the compliant channel too, since reversals are where manual processes break.
- Keep working when connectivity fails and transmit when it returns — a till that stops selling when the internet drops is not a solution.
- Reconcile what was transmitted against what was sold, so gaps surface before KRA finds them.
Payroll: the statutory stack
Four deductions, each with its own rules and its own history of mid-year changes: PAYE (graduated bands, taxable-benefit rules), NSSF (tiered contributions that have changed repeatedly), SHIF (percentage of gross, replacing NHIF logic), and the affordable housing levy (both sides, employer and employee). The system requirements:
- Current rates maintained in the product and shipped as updates — you should never edit a tax band yourself.
- Rates versioned with effective dates, not overwritten. When a band changes mid-year, a payslip computed under the old version must stay computed under it, or every historical payslip silently changes when the rate does.
- Outputs that reconcile to what you file, in a form your accountant can work from.
- The reconciliation triangle: payroll register, filings, and ledger postings agreeing monthly — the discipline covered in our NGO payroll guide applies to every employer. The Kenya-specific walkthrough is in PAYE, NSSF and SHIF payroll.
The versioning point in that list is the one nobody asks about and the one that causes the most damage. Ask a vendor what happens to a payslip you ran in March when a rate changes in July. If the answer is that the March payslip recomputes, they are storing a single current rate rather than a dated version of it — and every payslip you have ever issued is a function of today's settings rather than a record of what you actually paid.
Withholding tax
Paying certain suppliers — professional services, rent, and others — makes you a withholding agent. The system should flag withholding-liable supplier payments, compute the deduction at source, and produce the remittance schedule. Manual withholding is the quiet penalty generator: nobody forgets to pay a supplier, everybody forgets to withhold.
The records layer
- Seven-year retention of transaction records, retrievable — not archived into oblivion.
- Audit trails: who created, edited, approved, and deleted, with timestamps.
- Statements and reports that agree with filings, because they come from the same data.
The vendor test
Ask any vendor three questions: "Show me an eTIMS credit note, end to end." "When NSSF bands last changed, how did customers get the update, and when?" "Show me the withholding report for a mixed supplier payment run." Fluent answers mean built-in; hesitation means bolted-on.
Where we stop, stated plainly
This article is a specification for any ERP, and it would be unreasonable to write one without saying where our own product meets it and where it does not. The most important line is between computing a statutory figure and submitting it.
What AWRA OpsHub does today
- eTIMS integration, with POS sales and invoices mapped and transmitted from the sale record rather than re-entered, configured with your own credentials.
- Statutory payroll computed for PAYE with graduated bands and personal relief, NSSF tiers, SHIF and the housing levy, from real pay data.
- Rates versioned with effective dates rather than overwritten, so a payslip stays computed under the rules in force when it was run.
- P9 certificates produced for employees.
- VAT-aware records with net, tax and gross separated per line, on purchases as well as sales.
- Returns as documents linked to the original sale, and adjustments recorded rather than edited silently.
More we can add to your workspace
- A portal submission for payroll statutory returns. An iTax, NSSF or SHA filing integration, on the pattern eTIMS already follows. Today the figures are computed and exported, and somebody files them. If you read "compliance built in" as "it files for us", that is the distinction, and it is the one worth checking with every vendor.
- A VAT return filing. eTIMS transmission and VAT filing are different things; filing stays with your accountant.
- eTIMS is Kenya-only and does not travel to any other market you operate in — see eTIMS at the point of sale.
Where we point you to a specialist
- We do not interpret KRA rules for you, and nothing here is tax advice.
Rates, thresholds and filing requirements change with Finance Acts and regulation. The Kenya figures in the product were last cross-checked against a real employer payslip in July 2026; re-verify your own position with KRA or your tax adviser rather than inferring it from a software setting.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsCompliance capability should weigh heavily in your selection — it is the feature set you cannot postpone. Fold these checks into the ten questions for choosing a provider, and pressure-test the pricing implications with our ERP pricing guide: compliance sold as paid add-ons changes the three-year math. The deadline rhythm itself is mapped in the statutory compliance calendar, and the records layer above is treated properly in what an audit trail has to reconstruct.
Compliance as a by-product
eTIMS transmitted from the sale record, statutory payroll computed from real pay data on versioned rates, and VAT-aware records throughout — with the filing itself still yours.
See ERP built for KenyaFrequently asked questions
Does every business need eTIMS?
The mandate has expanded to cover VAT-registered businesses broadly, and non-compliant invoices cost your buyers their input VAT claims — which means even where edges exist, commercial pressure closes them. Assume you need it and verify your specific situation with your tax advisor.
Can we keep payroll in a separate system from operations?
You can — many do — but you inherit the integration gap: statutory costs missing from project budgets, payroll journals retyped into the ledger, and two systems to reconcile against filings. If both live on one platform, the triangle reconciles itself.
Our accountant handles compliance. Why does the system matter?
Your accountant files what your records support. When records are reconstructed monthly, the accountant's time goes into reconstruction instead of review — and errors ride along. Good systems make your accountant faster and your filings defensible.
What penalties are we actually exposed to?
Late or missing statutory filings carry per-return penalties and interest that compound monthly; eTIMS non-compliance costs you customers before it costs you fines. The bigger exposure is an audit that finds systematic gaps — that reopens prior years. Current penalty figures change; the structural fix doesn't.
Does "compliance built in" mean the system files our returns?
Not here, and this is the distinction worth pressing every vendor on. eTIMS is transmitted from the sale record, and PAYE, NSSF, SHIF and the housing levy are computed from real pay data on versioned rates — but there is no iTax, NSSF or SHA portal submission. The figures are computed and exported; somebody files them. Computing a statutory figure and submitting it are different capabilities, and "compliance built in" is routinely used to describe the first while implying the second.
What happens to an old payslip when a rate changes mid-year?
It should stay exactly as it was, because rates are versioned with effective dates rather than overwritten. This sounds like a technicality and is not: if a vendor stores a single current rate, then every payslip you have ever issued is a function of today's settings rather than a record of what you actually paid, and a mid-year Finance Act change silently rewrites your history. Ask what happens to a March payslip when a July rate lands.
