Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
Contracts & compensation
Gross pay, taxable pay and pensionable pay are three different numbers.
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
= Basic salary from the contract 62,000.00
+ House allowanceCASHTAXPENS 15,000.00
+ Travel allowanceCASH 8,000.00
+ Responsibility 5% of basicCASHTAX 3,100.00
Gross pay88,100.00
− Statutory deductions law data, versioned 19,842.40
− Staff sacco contribution voluntary 4,000.00
Net pay64,257.60
Look at the travel allowance. It is cash, so it lifts gross pay — but it carries neither the tax nor the pension flag, so it changes neither of those bases. One component, three independent decisions, and none of them inferred from the other two.
The foundation
Basic salary lives on the contract, and nowhere else.
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.
Contract types
Permanent Fixed term Casual Internship Probation
Statuses
Draft Active Expired Terminated
Reference & dates
Your own contract reference, a start date, and an optional end date that cannot fall before the start.
Basic salary
The base figure payroll pro-rates against days actually paid. The only source of truth for base pay.
Terms & notes
Free text for the substance of the agreement and anything internal you need beside it.
Attachments
The signed document itself, counted on the list so a contract with no paperwork behind it is visible.
A history, not a field
Contracts are a list per employee — a renewal is a new contract, so the sequence of what somebody was employed under survives.
Ownership checked
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.
One field you are not allowed to set
A contract's currency is derived, not typed.
Every other field on the contract is yours. This one is resolved by the platform, and any value arriving in a submission is discarded.
Employee's work countryfirst choice
Your base currencyfallback
KESlast resort
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.
The catalogue
Define a component once, use it on everybody.
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.
The three flags
Three questions, asked separately, because the answers differ.
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.
The package
One open package per person, edited in place.
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.
Tied to the active contract
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.
Effective dating exists underneath
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.
Viewing and changing are separate
Seeing somebody's package takes the employee-view grant; adding or removing an item takes the employee-edit grant.
Statutory is not here at all
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.
Straight answers
What contracts and compensation do today — and what we can add to yours.
This is the data pay is computed from, so precision matters more here than anywhere else on the site.
What AWRA OpsHub does today
- Basic salary held on the employment contract as the single source of truth for base pay, with everything else layered on top
- Five contract types — permanent, fixed term, casual, internship, probation — across four statuses, with reference, dates, terms, notes and file attachments counted on the list
- Contracts kept as a history per employee, so a renewal is a new contract and the sequence of terms survives
- Contract currency derived from the employee's work country, falling back to your base currency — never user-controllable, so it cannot diverge from the country payroll runs by
- An ownership check on nested records, so reaching a contract through the wrong employee's URL returns nothing found rather than somebody else's terms
- Your own pay component catalogue — allowances, benefits and voluntary deductions — each with a code unique to your workspace
- Two calculation bases per component: a fixed amount, or a percentage of basic between nought and a hundred, with the package item asking only for the figure that applies
- Three independent flags per component — cash, taxable, pensionable — feeding three separate running totals rather than one collapsed setting
- Gross pay, the taxable base and the pensionable base built in parallel from the same component list, so a taxed-but-not-pensionable allowance behaves correctly
- Ad-hoc period earnings — such as a project payout routed through payroll — carrying their own taxable and pensionable flags
- Pro-rating that multiplies before dividing, so a partial month does not lose cents to a truncated repeating fraction
- An in-use count on every component, and archiving rather than deletion, so retiring one cannot silently strip an allowance from dozens of packages
- A package tied to the active contract and taking its currency from it
- Statutory deductions kept in a separate versioned layer, so a tax band cannot be edited from a compensation screen
- Package edits that are always safe for history, because every payslip freezes its own figures and rule versions at calculation time
- Separate permissions for viewing and for changing, on both contracts and packages
More we can add to your workspace
- A compensation version history in the interface — several dated packages per employee, with the effective-from picker and supersede flow that the underlying data already supports
- Non-cash benefits in kind valued into the taxable base, so a company car or housing affects PAYE without affecting cash gross
- More calculation bases: tiered and banded components, a percentage of gross, per-hour and per-unit rates, and a formula editor
- A salary review workflow — proposed, approved, effective-dated — with the increase applied on its own date rather than immediately
- Backdated compensation changes with retro-pay, calculating and paying the difference for periods already run
- Contract templates and generated contract documents, produced from the record and sent for electronic signature
- Contract expiry and renewal alerts, so a fixed-term contract reaching its end date raises a task before it lapses
- Bulk compensation changes — an across-the-board increase, or a new allowance added to a whole grade in one action
- A total cost of employment view, adding employer contributions and non-cash benefits to give the real cost per head
- Loan and advance schedules as a recurring deduction with a running balance and an end date
- Multiple concurrent contracts for secondments and dual roles, with payroll treating them correctly
- Multi-currency components within one package, for allowances genuinely paid in another currency
- A package comparison across employees on the same grade, for spotting inconsistency before somebody else does
Where we point you to a specialist
- Which allowances are taxable and which are pensionable is a question of law and of your own reward policy. We build exactly the flags you set; we will not ship defaults that imply we have assessed your tax treatment.
- Whether a benefit is a taxable benefit in kind is a tax judgement with consequences, so it stays with your accountant or tax adviser. Tell us the treatment and we will apply it identically every time.
- We will not draft your employment contracts or advise on their terms. That is legal work. We will hold them, version them, attach them and generate them from a template you supply.
- Salary levels and grading bands come from your own reward decisions. We will enforce the bands you set and warn on breaches; we will not suggest a number.
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.
Either side of a package
What feeds this, and what it feeds.
Statutory & Payout Details The versioned law layer this page deliberately does not touch, plus encrypted payout details and P9 certificates. Payroll The run that consumes all of this, and the payslip that freezes its own arithmetic. Timesheets & Overtime The locked month that decides days paid — which is what basic salary gets pro-rated against. Positions & Structure Where a grade lives, and where salary bands would attach. Employee Management The record contracts and packages hang off, and the work country that decides currency. Document Vault Where signed contracts and supporting paperwork are held and permissioned.
Questions, answered
Contracts & compensation FAQ.
Why can I not choose the contract currency?
Because payroll runs are organised by work country and derive their currency from the contracts inside them. If a contract's currency could drift from its country — through a mis-click or a crafted submission — you would get a plausible-looking payslip paying somebody in the wrong unit. So it is resolved from the employee's work country, then your base currency, then a final fallback, and any submitted value is discarded.
What happens if I edit somebody's package after payroll has run?
Nothing happens to the past. Every payslip stores its own line items, bases, deductions and the exact statutory rule versions it used, and only references the package for traceability. So package edits are always safe for history — which is why the model can afford to be simple.
Can I have a taxable allowance that is not pensionable?
Yes, and that is the whole reason the flags are separate. Cash, taxable and pensionable are three independent switches feeding three independent running totals, so any combination behaves correctly.
Can I keep a history of somebody's salary changes?
Contracts already give you that for base pay — a renewal is a new contract, so the sequence survives. For the package on top, the effective-dating fields exist in the data but there is no interface for managing several dated packages yet. That is the first item in the middle column above.
How do I handle a company car or subsidised housing?
Record it as a non-cash benefit component so it appears on the package and on the record. Today a non-cash component does not add to gross, taxable or pensionable pay; valuing benefits in kind into the taxable base is work we can add, and it is listed above.
Where do PAYE and social security rates come from?
A separate versioned layer of law data, deliberately outside your reach — so nobody can edit a tax band while editing an allowance. Published versions are frozen once real payslips have used them and can only be superseded by a new version with its own effective date.
Can I give the whole workforce a five per cent rise in one action?
Not yet. Bulk compensation changes, and adding a component to a whole grade at once, are on the list above. Today it is a per-employee edit.
Can I generate a contract document from the record?
Not yet — you attach the signed document to the contract record. Templates that generate a contract from the data and send it for electronic signature are work we can add, and the signature capability already exists elsewhere in the platform.
Ready when you are
Build the package once. Let three bases look after themselves.
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.