Forty Hours in Which Seven Days?
American overtime is owed above forty hours in a workweek — a fixed seven-day period the employer picks, which need not start on Monday and need not match the pay period. Our attendance records have no workweek in them at all, and the boundary they do enforce is the calendar month.
Forty hours is the most widely known number in American employment, and it is only half a rule. The other half is the period it is measured over, and that period is not the calendar week, not the pay period, and not whatever your software happens to draw on a chart. It is a thing the employer chooses once and then keeps. Software that has never heard of it can still show you a number of hours; it just cannot tell you whether any of them were overtime.
Nothing here is employment-law advice, and this post deliberately does not say who is covered by the rule it describes. Whether a particular job is exempt is a determination about that job and that employer. What follows is about the shape of a record, which is a question you can settle without a lawyer and which decides whether the lawyer's answer can be applied at all.
The workweek, stated exactly
The Department of Labor defines it in one line: a workweek is "a fixed and regularly recurring period of 168 hours, or seven consecutive 24-hour periods." Four things follow from that sentence and each one is a schema requirement in disguise.
-
It may begin on any day, and at any hour
Not Monday, not Sunday — any day the employer designates, and any hour of it. A workweek can begin at six on a Wednesday morning and that is an ordinary choice, not an exotic one. Shift operations pick the boundary that falls in their quietest hour precisely so it does not cut a shift in half.
-
It need not coincide with the calendar week
Which means a system that computes "this week" from a calendar is computing something else. It may be a useful number. It is not the number the rule is about.
-
It need not match the pay period
This is the one that surprises people. A business can pay twice a month and still owe overtime by the workweek, so the pay run has to reach across a boundary that is not its own. The two periods are independent by design.
-
Once set, it stays set
The point of the word fixed is that the boundary cannot move to suit a particular week's hours. A permanent change is allowed; a convenient one is not. So the designation is a durable fact about the employer, which means it belongs in a settings record with a history rather than in a report filter.
Why this is a data question before it is a payroll question
You can outsource the payroll calculation. Plenty of businesses do, and the calculator will happily take a list of hours and return an overtime figure. What it cannot do is reconstruct which hours fell inside which workweek if the system that recorded them never knew where the weeks began. The boundary has to exist at the point of recording, not at the point of computing — and that is the half of the problem no payroll bureau can take off you.
What our own records know, and what they do not
We use ourselves as the worked example throughout this corpus, and here the answer is short.
Our organization-level HR settings hold which days are the weekend and the start and end of the business day. Both are real and both are useful. Neither is a workweek. "Saturday and Sunday are not worked" tells you which days are off; it does not tell you where the seven-day period begins, and the two are not the same fact — an operation that works every day still has a workweek, and an operation that rests on Sunday may still designate its week as beginning Thursday.
There is no field anywhere that holds a workweek start. Not on the organization, not on the employee, not on the shift.
Meanwhile every "this week" the product draws — in procurement, in reports, in accounting, in assets, in inventory — comes from the date library's own idea of where a week starts. It is consistent, it is defensible for a dashboard, and it is a library default rather than a decision anybody made about your business. There is no setting it could read even if it wanted to.
The boundary we do enforce is the wrong one
This is the part that turns an absence into a complication, and it is the reason this post is worth more than a line in a feature matrix.
Our timesheets are organised into monthly periods. A period is identified by a year and a month, it can be approved, and it can then be locked — at which point a snapshot is frozen, edits are refused, and payroll consumes the locked figures. That design is genuinely good and we have said so elsewhere: the boundary between a period that still recomputes and one that is settled is exactly what most attendance systems lack.
But it is a calendar month boundary, and a workweek does not respect it. Any workweek containing the last day of a month is split across two periods — and one of those periods can be locked while the other is still open. So the seven days over which overtime is owed sit either side of a line the system treats as final, in two records with different statuses, one of which will not accept a correction.
| What the rule uses | What our record uses | |
|---|---|---|
| The unit | A fixed seven-day workweek the employer designates | A calendar month |
| Where it starts | Any day, any hour, chosen once and kept | The first of the month |
| Whether it can move | Only permanently, and not to suit a week | Fixed by the calendar |
| What happens at the boundary | Nothing — the next week begins | A snapshot can be frozen and edits refused |
Read the last row twice. The disagreement between the two units would be a nuisance if both were merely reporting periods. One of ours is an enforcement point, and that is what makes this a design problem rather than a formatting one.
There is a second, narrower interaction with something we have written about before: a shift that crosses midnight also crosses a day boundary, and our attendance record stores its clock times without dates, so its duration comes back empty. A workweek boundary at an hour rather than at midnight makes that worse rather than better. That is a separate defect with its own post, and the two would need fixing in the same piece of work.
What would have to change
-
A designated workweek, stored on the organization
A day and an hour, with a history, because the rule cares that the designation is durable and a change has to be datable. This is one small table and it is the prerequisite for everything else on this list.
-
Weekly aggregation that reads it
Hours totalled over the designated period rather than over a library default. Once the setting exists this is arithmetic, and it should replace the calendar week everywhere the product currently draws one for an HR figure.
-
A period boundary that does not cut a workweek
The harder of the four, and the one worth arguing about before it is built. Either the approval period becomes weekly, or a locked month has to tolerate an adjustment reaching into it from the week that straddles its edge. Both are defensible and they have different consequences for what a lock means.
-
Overtime as a computation, last
Deliberately last. It is the visible feature and it is the least of the four, because it is a rule applied to a total that the first three exist to make correct. Quoting it first is how a system ends up with an overtime column nobody can defend.
Questions worth asking any workforce system
Where do I set the day and hour my workweek begins?
What you will hear
A named setting, shown to you.
How to read it
If the answer is a report filter, the boundary is a view rather than a fact and every historical figure was computed against whatever the filter said that day. Ours has no such setting at all.
Is that the same setting as the one that says which days are the weekend?
What you will hear
No, and a clear explanation of why not.
How to read it
Conflating the two is the most common version of this error. Non-working days and the start of the period are different facts and a system needs both.
What period do you approve and lock, and does it line up with the workweek?
What you will hear
An honest answer about where the two disagree.
How to read it
A lock on a boundary the rule does not use means an adjustment can be needed on the far side of something the system considers settled. Ours locks by calendar month.
Show me a week that straddles a month end, with the hours totalled over it.
What you will hear
One number, over seven days, across the boundary.
How to read it
This is the ninety-second version of everything above. Ask to watch it rather than to be told.
If my pay period is semi-monthly, how do you compute overtime?
What you will hear
By workweek, reaching across pay periods, with an explanation of how the adjustment lands on a pay run.
How to read it
A system that computes overtime per pay period has substituted its own convenient unit for the required one, and the error is invisible because both produce a plausible number.
What AWRA OpsHub does today
- Daily attendance records per employee with clock-in, clock-out, status and how the record was captured.
- Organization settings for weekend days and business hours.
- Shifts with start, end, break and grace, assignable per employee and overridable per date.
- Monthly timesheet periods that approve and then lock, freezing a snapshot that payroll consumes.
- Labour cost attribution to projects and cost centres.
What it does not do
- Any workweek designation — no day, no hour, nowhere to put one.
- Any weekly aggregation of hours that reads a business setting rather than a library default.
- Any approval or lock boundary other than the calendar month, so a workweek straddling a month end sits in two periods with different statuses.
- Any overtime computation, premium rate or regular-rate calculation, for the United States or anywhere else.
- Any American payroll engine — no federal or state withholding, no contribution calculations, no returns.
Not ours, by choice
- Nothing here is employment-law advice and this post does not say who is covered by the rule it describes. Which employees are exempt is a determination about particular jobs and it is yours and your adviser's.
- We have no reference customer in the United States.
A designated workweek stored on the organization with a history, and weekly aggregation that reads it, are small and are the prerequisite for anything else here — they are also the two that would improve every market rather than one, which is the argument for doing them properly rather than for one country. A period boundary that does not cut a workweek is the piece with real design in it and the one worth settling before it is built, because it changes what a lock means. An American payroll engine is a genuine build and we would scope and price it on the usual terms: a written specification, a timeline and a price agreed before anything starts, and no dates on a public page. The precedent that we finish statutory payroll work is Kenya, where a maintained engine runs in production.
The first two on that list are close to a defect fix rather than a feature, because a product that draws a week from a library default in five different controllers has not made a decision about weeks anywhere.
Our take
Forty hours is the half of the rule everybody knows. The half that decides whether your records can answer it is the seven days it is measured over, and that is a field rather than a feature. Ask where it is set. If the answer is a chart filter, or the weekend setting, or nothing, then whatever overtime figure comes out the other end was computed over a period nobody chose — and ours would be, because the field does not exist.
If you run shifts in the United States
Tell us your workweek and your pay period and we will tell you exactly where our records stop being able to answer the question. If that is a blocker for going live, we would rather establish it now.
See plans & pricing