An Hour and a Half Is Still an Hour
Overtime here is requested, approved and locked into a period like any other hour. What never happens is the multiplication — there is no rate factor anywhere in this product, so an approved overtime hour costs exactly what an ordinary one costs.
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.
What it does not do
Multiply. There is no rate factor anywhere in this product — not a global one, not per employee, not per shift type, not per day of the week, not for a public holiday.
An approved overtime hour and an ordinary hour are the same quantity of the same thing. Whatever premium your agreements or local practice require is applied outside the system, by whoever prepares the payroll.
The system knows an hour was overtime, records who approved it, refuses to let it into a closed month — and then values it identically to every other hour.
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
Nothing. No factor, no premium, no differential of any kind.
The premium is visible as a cost
Nowhere. There is no figure for what overtime cost you this month.
The consequence that is not about payroll
The obvious cost is manual work at month end. The larger one is that the person approving overtime cannot see what it costs.
A supervisor approving four hours is approving a number of hours, not an amount of money. If the premium is meaningful, the difference between what they think they authorised and what the business pays is substantial — and it accumulates across every approval, invisibly, 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. It is not primarily about computing the right figure; it is about 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 only and is not a rate this product applies or asserts is required anywhere. The point is the last row: whatever your premium is, it is invisible.
What to do today
-
Export approved overtime hours and apply your factor once
The hours are captured cleanly and are exportable with their approvals. One column in a spreadsheet does the whole job, and doing it in one place beats doing it per employee.
-
Publish the cost back to the approvers, monthly
This is the control the multiplier would have given you, delivered by hand. A supervisor who sees the money figure approves differently from one who sees an hours figure.
-
Keep the classification honest at capture
If your agreements distinguish weekday, rest-day and holiday overtime, capture that distinction in the request reason now — retrofitting it later is impossible, because nothing else records why the hour was outside the norm.
-
Do not use a separate pay element as a workaround
It divorces the payment from the approval and the lock, which are the three things this module does well. Keep the hours where they are and multiply at the end.
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 has none anywhere. It is a short question with a definitive answer.
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.
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.
What it does not do
- Any overtime multiplier or rate factor, global, per employee, per shift or per day type.
- Any distinction in value between weekday, rest-day and public-holiday overtime.
- Any cost figure for overtime anywhere — no report, no dashboard tile, no total.
- Any threshold, cap or alert on overtime hours per employee or per period.
- Any maintained statutory overtime rule for any market.
Not ours, by choice
- The capture, approval and locking around overtime are genuinely well built, and the gap is precisely one arithmetic step at the end. That is why it is sized small and why it is worth naming rather than burying.
- The 1.5 figure used above is illustrative. This product applies no premium and asserts no premium is required anywhere; what your agreements or local practice require is yours to determine.
- Nothing here is Mauritian, Seychellois or Malagasy. 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 is not built for Mauritius today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Mauritius. Kenya's eTIMS integration and its maintained payroll engine exist 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 your own operation needs that the standard one does not have, or a link to a system you already run 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
Whatever system you run, get the cost of approved overtime in front of the people approving it, monthly. It is the single change that reduces the number, and it needs a spreadsheet rather than a feature.
Talk about overtime controlFrequently asked questions
Can I set a multiplier per employee?
No — there is no rate factor at any level in this product, so per-employee is not a narrower version of something that exists. The multiplication happens outside, on the export.
Does the system stop somebody working excessive overtime?
No. There is no cap, threshold or alert on overtime hours, so limits are a matter of the approver knowing what they have already approved this month — which the system will not tell them either.
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.
