What a Biweekly Pay Period Is and the Off Week

A biweekly pay period is a fixed 14-day cycle that pays workers every other week, which produces 26 pay dates in a normal year and 27 in some years. That last part trips people up. If you pay a crew every other Friday and you have never planned for the extra date, the math will surprise you at least once.

The definition is simple, but the edges matter. A biweekly period is not the same as semimonthly. Semimonthly pays twice a month on set calendar dates, usually the 15th and the last day, which gives you exactly 24 checks a year with periods of uneven length. Biweekly locks to a 14-day rhythm regardless of the calendar. Every period is the same length. The pay dates drift across the month.

Where the 27th pay date comes from

A biweekly cycle is 14 days. Multiply 26 periods by 14 days and you get 364 days. A calendar year is 365 days, or 366 in a leap year. That leftover day accumulates. Roughly every 11 years, the drift pushes a 27th pay date into a single calendar year.

The exact year depends on which weekday you pay and when your first period of the year starts. There is no fixed rule that says "it happens in year X." You have to look at your own pay calendar. Line up your pay dates for the year in a row. If the first one lands in the first three days of January, count forward every 14 days and check whether a 27th date squeezes in before December 31.

Why care if you do not run payroll yourself? Because you export the hours that feed payroll, and a 27-period year changes how those hours get grouped. If your reporting assumes 26 buckets, one pay run in that year will either get dropped or merged into another. Both create a mismatch between hours worked and hours paid.

Lining up clocked hours to the correct boundary

The hard part is not counting the periods. It is deciding which side of midnight a given shift belongs to. A biweekly period has a start instant and an end instant. A shift that begins at 11:40 PM on the last night of a period and ends at 2:15 AM belongs partly to two periods if you split at midnight, or entirely to one if you assign by clock-in time. Pick a rule and hold it every period. Inconsistency here is where reported totals quietly go wrong.

Time zones make this worse than it looks. If your records are stored in one zone and read in another, a shift can appear to cross a boundary it never touched. Kangaroo Clock stores every entry in UTC and shows it in the viewer's local time, so a shift that ended at 11:50 PM local stays inside the period it belongs to instead of jumping across a boundary because of a server clock somewhere else.

Forgotten clock-outs distort period totals too. If someone taps their name to start a shift and walks out without ending it, an open entry can balloon and dump 40 phantom hours into whatever period the report happens to close. The auto-close for forgotten clock-outs handles this by ending a stale entry at its start time plus a set cutoff, never at the current moment, so a missed clock-out record cannot inflate the hours that land in a pay period.

How to run a clean biweekly export

When it is time to hand hours to whoever cuts the checks, you want a file that maps cleanly onto the period, with the same columns every time. A stable CSV column layout matters more than most people expect. If the column order shifts between exports, whoever imports the file has to re-map fields every pay run, and that is where a distinct-worker count or a total gets read into the wrong slot.

Here is the difference between the two most common cycles in one view.

Biweekly keeps workweeks intact, which makes overtime calculation simpler because a seven-day week never straddles two periods. Semimonthly splits weeks, so a single overtime week can fall across two pay runs.

For the actual arithmetic, add your period totals with a biweekly hours calculator before you export, so you can spot a bad number while you can still fix it. The full definition, including the semimonthly comparison, lives on the biweekly pay period glossary entry if you want the short reference version.

Set your period once, then let the records fall in place

Decide three things and write them down: which weekday you pay, when the first period of the year starts, and whether shifts are assigned by clock-in time or split at midnight. Once those are fixed, every export lines up on its own. Check your pay calendar each January for the 27th-date year and flag it before the run, not after.

If you track hours for a crew that clocks in without accounts, you can start a free workspace and pull a period export that already accounts for time zones and forgotten clock-outs.