Find answers, support paths, and rollout guidance fast
Search the same approved public knowledge source used by AwraIQ. Results stay grounded in published AWRA resources, so buyers, customers, and support teams work from one source of truth.
Product helpImplementationSecurity reviewsBilling & support
Leave is the first thing employees dispute and attendance is the first thing that quietly corrupts payroll. Both are the same problem: a record that either exists when it happened, or gets reconstructed later from memory.
Two things account for most account risk in a small business: passwords one breach away from public, and accounts belonging to people who left. Why an employee record and a user account are not the same object.
The businesses that supply and service mines run the hardest inventory problem in the region — critical spares nobody can quantify, consumables issued without paperwork, and tools that leave with a contractor. Including where calendar maintenance on the register stops and usage-metered plant maintenance begins.
An employee record here does not require a user account, and that is deliberate — in most of the businesses this was built for, a majority of staff have never logged into anything. Every account-shaped feature therefore covers a minority of your people.
An employee assigned to four depots needs to be inside the radius of one, not all. Three numbers decide it — a radius you set, a distance the server computes, and an accuracy the phone reports — and only two of them are yours.
The statutory stack done right, plus the NGO layer: allocating staff costs to grants, paying casuals and enumerators properly, and the monthly reconciliation triangle.
A service on a purchase order is now received by a delivery confirmation, not a check-in. Nothing enters stock, the cost is booked when the work is confirmed, and the people who sign for goods sign for work.
Clocking in requires a registered device, and an employee who has not enrolled one is refused with an instruction rather than let through with a warning. The refusal is recorded, and both routes into the clock run the same check in the same order.
What competes for a system on payroll day and at the close, what a dedicated queue and scheduler change, and what the Dedicated and Dedicated server tiers each do and do not share.
Leave arithmetic and workflow deadlines used to answer the same question differently. They now resolve through one calendar — and the interesting part is what happens when that calendar has no working days in it.
A vendor-honest guide for businesses and groups operating in more than one EAC country — why one system beats a copy per country, what "one ERP across the region" actually requires, and the straight answers on tax, e-invoicing and payroll that no platform automates identically across every border.
One event can leave the building through eight doors at once. What decides whether a chat integration is an asset or a muted channel is the four questions asked before each door.
Payroll here is maintained for one market and configurable for every other. Those are not two grades of the same feature — they are different products, and the difference is who is responsible on the day a rate changes.
HR records which department an employee belongs to. Procurement asks which department a login belongs to. Two columns on two tables — and when HR provisions that employee a login, the department does not travel with it.
Overtime here is requested, approved, locked into a period and — once you switch it on — priced through payroll at a working-day, rest-day or public-holiday multiple. What remains is putting that cost in front of the approver.
Pay from a log and the log starts being written carefully — and creatively, by the same people, for the same reason. What a payout reconciles at the moment of posting, why the direct route records a payment rather than making one, and the lock that does not cover the clock you are paying from.
Four statutory deductions, four sets of rules, and rates that move. What a Kenyan payroll run should do, why date-effective rules matter more than the arithmetic, and the reconciliation that catches errors before the money leaves.
A project here can pay the people who worked on it, through a document with its own reference, approval and posting date. That is a second way of paying somebody, running beside payroll, and neither one knows about the other.
Logging hours tells you what a job cost. It does not pay anybody. Turning unpaid logged time into money that leaves your account — without paying the same hour twice or losing the trail to the bank.
Tanzanian payroll is less about clever software and more about clean discipline: PAYE, NSSF, SDL and WCF handled consistently, records that reconcile, and honest expectations about what any system actually automates. A practical, hedged guide.
PAYE, NSSF and Local Service Tax are where Ugandan payroll gets fiddly. What a system genuinely helps with, what it does NOT automate the way Kenya's statutory payroll is, and why "confirm with URA" is the most honest line in this guide.
PAYE and RSSB contributions are where Rwandan payroll gets exacting. What a system genuinely helps with, what it does NOT automate the way Kenya's statutory payroll is, and why "confirm with RRA/RSSB" is the most honest line in this guide.
IPRES, CSS, CNPS and a collective agreement that varies by sector. The most useful thing a foreign software vendor can tell you about Francophone payroll is where its competence stops.
Page 3 of 13 · 290 articles
Still need a human answer?
For rollout planning, enterprise procurement, billing, security review, or customer support, share the context and we will route it to the right owner.
We use necessary cookies for secure sessions. With your permission, we also use cookies and browser storage for preferences, analytics, and demo engagement. Privacy Policy
AWRA OpsHub
Cookie settings
Cookie Consent Manager
Necessary cookies stay on for login, CSRF protection, and security. You can choose the optional categories below.
Overview
General Information
AWRA uses cookies and browser storage to keep public pages secure, remember selected preferences, measure website performance, and manage demo engagement prompts.
You can choose whether functional and marketing engagement storage apply. Analytics measurement is always active in this AWRA setup.
These settings apply to AWRA public website experiences such as the homepage, feature pages, pricing calculator, blog, help center, and request-demo page. Authenticated dashboard and vendor portal sessions still rely on required security cookies.
Required
Always active
Functional
Optional
Analytics
Always active
Marketing
Optional
For more context on privacy handling, open the Privacy Policy.
Required Cookies
Required Cookies
Always Active
Required cookies and storage support basic website delivery, secure sessions, request protection, and remembering the consent choice itself.
These cannot be switched off from this manager because disabling them would break login/session behavior, form protection, or the ability to remember the privacy choice you save.
Cookie details
Session security: keeps secure server sessions working while browsing AWRA.
CSRF protection: helps verify form submissions and protect requests.
Consent record: stores the preference decision so the banner does not keep asking after a choice is saved.
Examples: Laravel session cookies, CSRF tokens, and the AWRA consent preference record.
Duration: session security can expire with the browser/session; saved consent can last longer so the same browser remembers the choice.
Functional Cookies
Functional Cookies
Functional storage improves the public website experience by remembering interface choices, helper states, dismissed notices, and short-lived interaction preferences.
Turning this off does not stop secure required cookies or analytics. It only limits optional convenience memory.
If disabled, AWRA may show some helper prompts again or forget non-essential display choices. Core public pages, contact forms, and request-demo forms still work.
Cookie details
UI preferences: remembered display choices and helper states where available.
Dismissed notices: session-level or preference-level memory for notices the visitor has closed.
Frequency helpers: optional browser storage that prevents repeated prompts when allowed.
Examples: localStorage or sessionStorage values for dismissed banners, guide/helper states, and lightweight public-page preferences.
Effect when off: AWRA avoids optional convenience memory unless it is also allowed through marketing and engagement preferences.
Analytics Cookies
Analytics Cookies
Always Active
Analytics helps AWRA understand public page performance, traffic patterns, and content usefulness so we can improve the marketing website.
This category does not by itself enable demo popups, exit-intent prompts, or advertising pixels. Those are controlled by Marketing & engagement.
In this AWRA setup, Google Analytics and Google Tag Manager measurement are treated as mandatory website measurement and remain active.
Cookie details
Google Analytics / GTM: measures aggregate traffic and page activity.
Performance insight: helps identify which public pages, docs, and demo paths visitors use.
Operational signal: supports website quality decisions without enabling demo popups by itself.
Examples: Google measurement identifiers such as GA/GTM tags and related browser identifiers set by Google scripts.
Use: page views, source/referrer trends, public content performance, and product education page effectiveness.
Marketing & engagement
Marketing & engagement
Marketing and engagement storage supports demo prompts, exit-intent prompts, campaign attribution, and future advertising pixels.
When disabled, AWRA will not auto-open demo or exit-intent popups. CTA buttons can still open a form because that is a direct visitor action.
When enabled, AWRA can remember that a visitor already saw, dismissed, or submitted a demo prompt so the same popup is not repeated aggressively.
Cookie details
Demo prompt memory: tracks whether an auto prompt or exit prompt was recently dismissed.
Demo submission memory: avoids asking again after a visitor submits a demo request.
Campaign context: keeps source page, referrer, and UTM context available for demo requests.
Examples: popup frequency caps, demo-submitted flags, engagement source fields, and UTM/referrer context.
Effect when off: auto demo prompts and exit-intent prompts stay blocked; normal navigation and manually clicked CTA buttons still work.