Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Any payroll that treats them as one is wrong in a way nobody notices until an audit. AWRA OpsHub keeps basic salary on the contract, layers a package of allowances, benefits and deductions over it, and lets every component decide independently whether it is cash, whether it is taxed, and whether it counts towards pension.
Five contract types · Currency derived, never typed · Fixed or percentage-of-basic components · Statutory kept out of your hands
One number, one home. Everything else is a layer on top of it — which means there is never a question about which of two salary figures is the real one.
Your own contract reference, a start date, and an optional end date that cannot fall before the start.
The base figure payroll pro-rates against days actually paid. The only source of truth for base pay.
Free text for the substance of the agreement and anything internal you need beside it.
The signed document itself, counted on the list so a contract with no paperwork behind it is visible.
Contracts are a list per employee — a renewal is a new contract, so the sequence of what somebody was employed under survives.
Reaching a contract through the wrong employee's URL returns nothing found rather than somebody else's terms.
Reading a contract and changing one are separate permissions. Viewing takes the employee-view grant; adding, editing or removing takes the employee-edit grant. That split matters more here than on most records, because a contract is simultaneously an HR document and the number payroll multiplies.
Every other field on the contract is yours. This one is resolved by the platform, and any value arriving in a submission is discarded.
The reason is what sits downstream. Payroll runs are organised by work country, and each run derives its currency from the contracts inside it. If a contract's currency could drift from its country — through a crafted submission, or simply somebody picking the wrong item from a dropdown at four in the afternoon — you would get a payroll run that pays a Kenyan employee in the wrong unit, and the payslip would look entirely plausible.
This is the sort of guard that is invisible when it works, which is exactly why it is worth stating on a page like this. Nothing you do in the interface will ever tell you it is there. It only shows up in the payroll runs that did not go wrong.
Pay components are your own reusable types — three kinds, two calculation bases, three independent flags. Build the catalogue once and an employee's package becomes a matter of picking from it.
| Component | Kind | Basis | Cash | Taxable | Pensionable | In use |
|---|---|---|---|---|---|---|
House allowanceHOUSE | Allowance | Fixed | Yes | Yes | Yes | 48 |
Travel allowanceTRAVEL | Allowance | Fixed | Yes | — | — | 31 |
ResponsibilityRESP | Allowance | 5% of basic | Yes | Yes | — | 9 |
Medical coverMEDICAL | Benefit | Fixed | — | — | — | 52 |
Staff saccoSACCO | Deduction | Fixed | — | — | — | 27 |
Union duesUNION | Deduction | 2% of basic | — | — | — | 14 |
The "in use" count is not decoration. Retiring a component when you cannot see how many packages depend on it is how a payroll loses an allowance for forty people in one afternoon. Components are archived rather than deleted for the same reason: the payslips that referenced one need it to keep existing.
Two calculation bases cover most of what an organisation needs: a fixed amount, or a percentage of basic salary between nought and a hundred. Which one a component uses is set on the component itself, and the package item then asks for whichever figure applies — so you cannot accidentally enter a percentage where an amount belongs.
This is the part of the design that earns its keep. Each flag feeds a different running total, and payroll builds all three in parallel from the same list of components.
Starts at pro-rated basic salary, and each cash allowance or benefit adds to it and appears as its own earning line on the payslip.
A non-cash benefit does not inflate gross, which is right — a medical scheme is real value and is not money the employee received.
Ad-hoc earnings queued into the period — a project payout routed through payroll, for instance — add here too, each carrying its own flags.
Also starts at pro-rated basic, and grows only by the components carrying the taxable flag. This is the figure income tax bands are applied to.
A tax-free travel allowance therefore lifts what somebody is paid without lifting what they are taxed on — which is the entire point of having it as a separate allowance.
A third independent total, grown by components carrying the pensionable flag, and used for social security contributions.
It genuinely diverges from the taxable base in practice, which is why it is not derived from it. A responsibility allowance that is taxed but not pensionable is completely ordinary.
Pro-rating is done in the order that keeps the cents. Basic salary is multiplied by days paid and then divided by standard working days — rather than the more obvious way round — because dividing first turns something like twenty twenty-seconds into a repeating fraction that gets truncated, and the lost remainder becomes a payslip that is a few cents adrift every month. Small, and the sort of small that people notice on their own payslip and never notice on anybody else's.
And then net pay is simply gross, less statutory, less voluntary. Three subtractions, from three totals that were each built for their own purpose.
A deliberately simple model, and the reason it is safe to be simple is worth explaining rather than assuming.
Each employee has a single current compensation package, opened automatically the first time you go to edit one and tied to their active contract. You add and remove items from it freely: pick a component, give it its amount or its percentage, add a note if the reason needs recording.
There is no version-history interface, no effective-date picker, no "supersede this package" workflow. For a system that computes pay, that would normally be alarming — and here it is fine, for one specific reason.
A payslip freezes its own figures at the moment it is calculated. Every line item, every base, every deduction and the exact statutory rule versions used are stored on the payslip itself. The package is referenced only for traceability. So editing a package after payroll has used it cannot retroactively change a single past payslip — the arithmetic has already been written down.
That is a different situation from statutory rules, where changing a published rate genuinely would rewrite history if it were allowed, which is why those are frozen once used and can only ever be superseded by a new version. Two layers, two different safety rules, each matched to what the layer can actually damage.
A new package records which contract it was opened against, and takes its currency from that contract — so the package cannot be denominated differently from the salary it sits on top of.
The package carries an effective-from date, an effective-to and a status. The dating is in the data; what is not yet built is the interface for managing several packages over time. That is a change we can make.
Seeing somebody's package takes the employee-view grant; adding or removing an item takes the employee-edit grant.
Income tax, social security, health insurance and levies are versioned law data in a separate layer. Nobody can edit a tax band while editing an allowance, because the two are not in the same place.
This is the data pay is computed from, so precision matters more here than anywhere else on the site.
What AWRA OpsHub does today
More we can add to your workspace
Where we point you to a specialist
Dated compensation history and a salary review workflow are the two most-asked items here, and both build straight onto data that already carries effective-from, effective-to and status fields. Tell us your review cycle and approval chain and we will come back with a written spec, a timeline and a price.
One behaviour to know when you build your catalogue: a component only reaches gross, taxable or pensionable pay when it is flagged as cash. A non-cash benefit is recorded on the package and shown for completeness, and valuing it into the taxable base is the second item in the middle column above.
Basic pay on the contract, allowances and deductions from your own catalogue, and gross, taxable and pensionable pay each computed for their own purpose rather than assumed to be the same figure.