Overtime Rate Factors: Turning Approved Hours Into 1.5x
Overtime here is requested, approved and locked into a period like any other hour — and, once you switch it on, priced through payroll at a working-day, rest-day or public-holiday multiple. What the approver still sees at the moment of approval is a number of hours.
Overtime is one of the few costs in a business that is authorised in advance, by a named person, one decision at a time. That makes it unusually controllable and unusually easy to lose track of, because each individual approval is small.
What the product does well here
Overtime is a request. Somebody raises it, somebody approves it, and both actions are enforced against the timesheet period lock — so overtime cannot be added to a month that has already been closed and paid.
The working week is configurable per organisation, and one calendar service answers "is this a working day" for leave, for workflow due dates and for business-hours deadlines alike. So the system can tell which hours fall outside the normal week.
Classification: built. Approval: built. Locking: built. And, since October 2026, the multiplication too.
How the multiplication works
Overtime pay is a switch in HR settings, and it starts off — an organisation that already pays overtime as a pay component turns that off before turning this on, or the hours are paid twice. Once it is on, each payroll run reads the locked timesheet and adds one earning line per kind of day: overtime on a working day, on a rest day and on a public holiday.
Each kind carries its own multiple, set in the same screen. The defaults are 1.5, 2 and 2, and each can be set anywhere from 1 to 10; they are a common starting point, not any country’s law, so the multiples your agreements require are the ones to enter. Rest days come from your working week and holidays from your holiday list, and a holiday that falls on a rest day pays the holiday rate.
The hourly rate is the full basic salary divided by the run’s standard working days times the hours in a working day, which defaults to eight. Full basic rather than the prorated figure, so somebody with unpaid leave in the month earns the same per hour. Overtime is taxable and not pensionable by default, and both are settings, because that treatment depends on your jurisdiction.
One detail for the changeover. A timesheet locked before the split existed carries only a total. It is re-split from the approved records when they still add up to that total, and otherwise paid entirely at the working-day multiple — the locked total is the figure of record, and the lowest multiple is the one that cannot overpay.
The system knows an hour was overtime, records who approved it, refuses to let it into a closed month — and now prices it by the kind of day it was worked.
The hour is captured
Requested, with a reason, against a date and an employee.
The hour is approved
By somebody other than the requester, as a distinct action.
The hour is locked
Both create and approve respect the timesheet month lock.
The hour is classified
The working calendar can say whether it fell outside the normal week.
The hour is multiplied
A working-day, rest-day or public-holiday multiple, each an earning line on the payslip, once overtime pay is switched on.
The premium is visible as a cost when approved
The money appears on the payslip after the run; a cost beside the hours at the moment of approval is the next step.
The consequence that is not about payroll
The multiplication removes the manual work at month end. It does not, on its own, change the larger problem, which is that the person approving overtime is still looking at hours.
A supervisor approving four hours is approving a number of hours, not an amount of money. The premium now lands correctly on the payslip — but that is after the decision, on a document the supervisor never sees. The difference between what they think they authorised and what the business pays accumulates across every approval until somebody looks at the payroll total and asks what happened.
That is the argument for the multiplier being a control rather than a convenience. Computing the right figure is now done; the control is the approver seeing it at the moment they decide.
One month, one department, at an illustrative 1.5 premium
The 1.5 here is illustrative, and happens to be the working-day default — a starting point you replace with your own multiple, not a rate this product asserts is required anywhere. The point is the third row: the approver still sees a quantity.
What to do today
-
Switch overtime pay on and set your three multiples
Working day, rest day and public holiday, from your agreements rather than the defaults. Set the hours in a working day and the taxable and pensionable treatment in the same screen.
-
Retire any overtime pay component first
If overtime used to be paid as a separate pay element or a one-off earning, remove it before the first run with overtime pay on, or the same hours are paid twice.
-
Keep the working week and holiday list current
They decide which multiple an hour earns. A public holiday missing from the list is paid as an ordinary working day, and nothing on the payslip will look wrong.
-
Publish the cost back to the approvers, monthly
The overtime earning lines on the run give you the money figure per person. A supervisor who sees it approves differently from one who sees an hours figure.
Four questions about overtime in any payroll system
Where is the multiplier configured?
A good answer sounds like
A screen, with per-type rates.
What it actually means
Ours is HR settings, with one multiple per kind of day. Ask whether it can vary per employee too — ours is organisation-wide today.
Can rest-day and holiday overtime differ?
A good answer sounds like
Yes, separately.
What it actually means
A single global factor is a simplification most agreements do not permit. Ours carries three, and a holiday on a rest day takes the holiday rate.
Does the approver see a cost or a quantity?
A good answer sounds like
A cost.
What it actually means
The control question rather than the payroll question, and almost nobody asks it.
Can overtime be added to a closed month?
A good answer sounds like
No.
What it actually means
Ours refuses, on both create and approve. This is genuinely well done and worth confirming elsewhere.
What AWRA OpsHub does today
- Overtime as a request with a create and an approve path, approved by somebody other than the requester.
- Both paths enforced against the timesheet period lock, so a closed month cannot acquire new overtime.
- A configurable working week and holiday calendar, resolved through one service for leave, workflow dates and business hours.
- Overtime hours exportable with their approvals.
- Attendance capture across web, kiosk, passkey devices and a manual register, all lock-aware.
- Overtime priced through payroll, switched on in HR settings, as one earning line per kind of day — working day, rest day and public holiday — at multiples you set between 1 and 10.
- An hourly rate of full basic salary over the run’s standard working days times your hours per day, and overtime taxable and pensionable as you configure it.
- Timesheets locked before the change re-split from their approved records, or paid at the working-day multiple when the records no longer match the locked total.
More we can add to your workspace
- Overtime multiples per employee or per contract, on top of the organisation-wide three.
- An overtime cost figure beside the hours at the moment of approval, and an overtime cost report across the month.
- A threshold, cap or alert on overtime hours per employee or per period.
- Time off in lieu as an alternative to overtime pay.
- A maintained statutory overtime rule for any market.
Where we point you to a specialist
- The capture, approval, locking and pricing of overtime are now all built, and what remains is putting the money in front of the approver. That is why it is worth naming rather than burying.
- The 1.5 figure used above is illustrative, and the defaults in the settings screen are a starting point. We assert no premium is required anywhere; what your agreements or local practice require is yours to determine and yours to enter.
- This is market-neutral. The Indian Ocean hub carries this because tourism and processing operations there run heavily on shift patterns, which is where overtime stops being occasional.
What we can build for Mauritius on top of the standard product
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point for Mauritius, not a limit on what AWRA OpsHub can do there. Kenya's eTIMS integration and its maintained payroll engine are in the product because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a certified EBS fiscalisation connection, a Mauritian payroll engine, a bank or mobile money feed, a statutory return format, a rule specific to how your operation runs, or a link to a system you already have is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
Real-time fiscalisation, through certification we do not hold
Invoice fiscalisation against the Revenue Authority in real time — structured invoices, a validation response held on the transaction, retries, a failure queue and a daily report of invoices carrying no reference. Stated precisely, because precision is the whole value of saying it here: this requires becoming a certified Electronic Billing System, which is an accreditation rather than an integration. We are not certified and hold no connection today. If you are in scope, choose your EBS first and fit everything else around it.
Banks, cards and genuinely multi-currency settlement
Bank statement feeds and card acquirer settlement into the Payments Register, across the several currencies a Mauritian entity actually operates in rather than one reporting currency with conversions bolted on. There is no exchange control to work around here, which makes this the ordinary version of a problem that is difficult almost everywhere else on the continent.
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.
Payroll and statutory returns
PAYE, National Pensions Fund and National Savings Fund contributions and the associated returns, computed on live records and produced in the layout each body expects. Not built today — our maintained engine covers Kenya only, and the local providers here are good.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedShow the approvers the money
Overtime is now priced on the payslip by the kind of day it was worked. Get that cost in front of the people approving it, monthly — it is the single change that reduces the number.
Talk about overtime controlFrequently asked questions
Can I set a multiplier per employee?
Not yet. The multiples are organisation-wide — one each for working-day, rest-day and public-holiday overtime, set in HR settings — and per-employee or per-contract rates are something we can add on top of them.
Is overtime pay on by default?
No. It is off until an organisation switches it on in HR settings, so nobody is paid twice where overtime already reaches pay through a separate component. With it off, approved hours are still recorded on the payslip.
Does the system stop somebody working excessive overtime?
Not today. A cap, threshold or alert on overtime hours is one of the things we can add, so for now limits are a matter of the approver knowing what they have already approved this month.
Is the approval separation enforced?
Create and approve are distinct actions and both respect the period lock, which is the part of this that is properly built. Who may approve is governed by how you grant permissions rather than by a rule specific to overtime.
