The Pay Period Your Software Assumes
Twenty-six pay days do not fit into twelve months, and the two that do not fit arrive on a schedule rather than by accident. Most finance systems store a payroll period as a month and never say so.
Ask a payroll system how many pay runs it will accept in a calendar month and you will usually get a puzzled look, because the question sounds like it has an obvious answer. It does have an obvious answer in most of the world: one. That is correct wherever people are paid monthly, and it is wrong wherever they are not — which includes every fortnightly and weekly payroll on earth, and a statutory tax table in more countries than the people building the software tend to assume.
The failure has a particular character. It does not error. It does not refuse. It produces a year in which some pay events were recorded and some were folded into their neighbours, and the difference is found much later by somebody reconciling a bank account to a payroll ledger and finding two months where the two do not describe the same thing.
Twenty-six is not twenty-four
This is the first place the reasoning goes wrong, and it goes wrong in conversation rather than in code. "Fortnightly" and "twice a month" sound like the same arrangement and are not. Twice a month is twenty-four pay days a year and always exactly two per month. Every fortnight is twenty-six, and twenty-six does not divide by twelve.
A year of fortnights
Which two months depends entirely on where the cycle starts, so no calendar can be printed in advance. That it is two is fixed. A weekly cycle is the same problem with sharper edges: fifty-two pay days, and four months a year containing five.
And because 26 and 12 share a factor of two, the collision is not random. The two clocks realign every six months, so the third pay day arrives on a rhythm — twice a year, indefinitely, in whichever pair of months your cycle happens to produce.
"Fortnightly" and "twice a month" differ by two pay runs a year. That is the entire bug, and it is usually introduced in a requirements conversation rather than in code.
Why a fortnight is not half a month
If a pay period were only a scheduling preference, the fix would be administrative: run the third pay day as an adjustment and move on. It is frequently not a preference. In several jurisdictions the statutory deduction tables are published per pay period — fortnightly tables, weekly tables — and the tax on a fortnight is what the fortnightly table says it is.
That matters because income tax is progressive nearly everywhere, and a progressive scale applied to a period is not the same as the same scale applied to a longer period and divided. The bracket boundaries land in different places. Take a monthly gross, halve it, and look up the result in a fortnightly table and you will usually get a different number than the fortnightly table gives for the actual fortnightly earnings — sometimes higher, sometimes lower, depending on the employee and on where their pay sits relative to a threshold. It reconciles at the year only if somebody reconciles it at the year.
| Pay frequency | Pay days a year | Does a calendar month always hold a whole number of them? | What breaks in a month-shaped system |
|---|---|---|---|
| Monthly | 12 | Yes — exactly one | Nothing. This is the case every system is built for. |
| Semi-monthly (twice a month) | 24 | Yes — exactly two | Only that two runs per month must be possible at all. Many systems will not allow it. |
| Fortnightly (every 14 days) | 26 | No | Two months a year need three runs. The extra ones are merged, journalled or lost, and the deduction is computed on the wrong unit. |
| Weekly | 52 | No | Four months a year need five runs. Everything above, four times as often. |
The question that separates the two
Not "do you support fortnightly payroll" — almost everyone says yes to that. Ask: "how many payroll runs will your system accept for one company in one calendar month?" If the answer is one, the product stores a payroll period as a month, whatever the sales sheet says. And ask it as a data question rather than a feature question, because a system can display a fortnightly schedule perfectly well while storing the result in twelve monthly buckets.
Where the assumption actually hides
It is rarely one setting. A calendar month tends to get baked in at several layers independently, by different people, each of whom was reasonably assuming the layer below them. In our own product we found it in five places, and the shape will be familiar to anyone who has looked:
- The period column itself — a short string holding a year and a month, which cannot represent a span that is not a month no matter what is written into it.
- A unique constraint on the period, which turns "we have not built that" into "the database refuses it".
- The timesheet or attendance lock that payroll consumes, keyed on the same month, so fixing the payroll table alone changes nothing.
- The period-end date derived as the last calendar day of the month, which is what every "as of" lookup resolves against — pay in force, statutory rules in force, employment status.
- The input validation, accepting a year and a month, so there is no way to express a fortnight even if everything beneath it could store one.
The list matters more than any single item on it, because it tells you what a fix costs. One of those five is a column change. All five together is a data-model change with a migration, and any vendor who quotes a fortnightly pay cycle as a configuration option has looked at exactly one of them.
Our own answer, since we are the ones raising it
What our schema does today
Our payroll run is one calculation per organization, per calendar month, per country of work. The period is a seven-character string holding a year and a month, and there is a unique key on organization, period and country of work — so a second run inside one month is refused at the database rather than missing from a backlog. The month is then assumed again in the timesheet lock (which payroll will not calculate without), in the period-end resolution, in the attendance window and in the run form's validation. Which means we do not support a fortnightly pay cycle, and the honest description of that is a schema limitation rather than a gap in a feature list. It is published with the constraint quoted on our Papua New Guinea page, and pinned by a test so that changing it has to be a deliberate act.
We are writing this up rather than quietly shipping a fix for a reason worth stating. A pay period is not a field you widen — it is the unit that a dozen other calculations resolve against, and getting it wrong in the other direction would produce a system that accepts a fortnight and then computes leave accrual, statutory rules and compensation-in-force against a boundary that no longer exists. That is a worse outcome than the current honest refusal.
What to do if you are on the wrong side of this
The first move is measurement rather than procurement, and it takes an afternoon.
-
Count last year's pay events, then count last year's payroll records
Not the schedule — the records the system actually holds. Twenty-six against twenty-four is the whole finding, and the two months where they diverge are where every downstream difference is hiding.
-
Open the two crowded months
Find what happened to the third pay day. Merged into the second run, posted as an adjustment, entered as a manual journal, or handled in a spreadsheet outside the system. Each of those has a different cost and only one of them is recoverable cheaply.
-
Check which unit the deduction was computed on
If your jurisdiction publishes per-period tables, was the fortnightly table used on fortnightly earnings, or was a monthly figure derived and split? This is the part that is a tax question rather than a bookkeeping one, and it is the part to take to your accountant rather than to your vendor.
-
Only then ask a vendor the storage question
One calendar month, one run? Then you know the answer regardless of what the demo showed you, and you can price the difference instead of discovering it.
The short version
A pay period is a unit of time that somebody else decided, and a great deal of software stores it as a calendar month without ever saying so. Twenty-six pay days into twelve months leaves two over, on a six-monthly rhythm, forever. Before you evaluate anything else about a payroll module, ask how many runs it will accept in one month — and if the honest answer is one, at least you are choosing rather than finding out.
Count the runs, not the schedule
If your pay cycle is not monthly, the number of payroll records your system produced last year is the only diagnostic that matters. We will tell you plainly what ours does and does not do with it.
Talk to us