How to Build a Payroll Calendar for Semi-Monthly vs Biweekly

Building a payroll calendar sounds like spreadsheet work until you hit real payroll friction: benefits deductions that assume specific pay dates, accruals that need consistency, reimbursements that arrive late, and employees who notice every pattern shift. The calendar is the quiet engine that drives everything else. If it is wrong, payroll does not just look messy, it creates downstream problems in HRIS imports, accounting close, and employee trust.

There are two common approaches for wage payroll in the US and Canada, among other places: semi-monthly and biweekly. They can look similar at first glance, but they behave very differently across a year, especially when you deal with holidays, mid-year starts, and approvals that miss internal deadlines.

This guide walks through how to build a payroll calendar for both methods, how to compare them, and how to make decisions that hold up when the year gets complicated.

The two schedules, in plain terms

Semi-monthly payroll pays employees twice each month, usually on the 15th and the last day (or the 30th and the 15th in shorter-month patterns depending on your policy). Biweekly payroll pays every 14 days, usually anchored to a specific “first pay period start date” and then repeated.

That difference, “twice per month” versus “every 14 days,” drives most of the trade-offs.

A semi-monthly calendar is tidy for monthly accounting. It lands predictably within each month, and employees often appreciate the stable rhythm. The cost is that pay periods do not align neatly with calendar weeks. Accrual and timesheet coverage can get awkward because the number of workdays between the 15th and month-end changes month to month.

A biweekly calendar is tidy for payroll processing because it repeats in a strict 14-day cycle. The cost is that it can drift relative to months, and you end up with pay periods that straddle month boundaries in ways that your accounting and HR reporting may need to accommodate. Biweekly also creates 26 paychecks in a typical year, while semi-monthly creates 24.

Those differences affect everything from overtime calculations to how you present earnings statements.

Decide what “pay period coverage” means for your organization

Before you generate any dates, you need a policy-level answer to a question that HR, payroll, and finance sometimes phrase differently:

Do your pay periods represent work performed, or do they represent a fixed set of pay dates?

Most organizations mean “work performed,” but then they define it with varying conventions. In practice, you will need three pieces of information for each schedule:

1. The pay date, which is when the payment posts.
2. The pay period start date, which is when time begins counting.
3. The pay period end date, which is when time stops counting.

Then you layer in processing time. Many companies set an internal deadline like “timesheets must be approved by X business day before pay date.” If you build the calendar without mapping approval lead time, you will eventually create situations where you have no realistic cut-off for a holiday week.

This is where experience matters. I have watched teams generate a beautiful calendar for 12 months only to discover that the payroll vendor’s submission deadline does not line up with how the company expects to finalize time. When that mismatch shows up, you either rush reviews or start moving pay dates ad hoc. Both are avoidable if you bake processing lead time into the calendar logic from day one.

Map holiday and weekend rules early

Most calendars do not just “move payday if it falls on a holiday.” They move it when it falls on a non-processing day for your payroll system.

You need explicit rules, for example:

• If pay date falls on a weekend, process on the preceding business day.
• If pay date falls on a company holiday (or payroll vendor holiday schedule), move to the preceding business day.
• If the move crosses into the previous month or accounting period, determine whether you still attribute earnings to the work dates or the check date.

Do not leave that last part ambiguous. It matters for journal entries, especially if you use a standard “payroll expense recognized by pay date” approach. Some companies recognize expense based on work performed, not the check date. Either can be valid, but the calendar needs to be consistent with the accounting policy you follow.

A practical approach is to separate “pay date” from “earnings attribution.” Your calendar can list both: adjusted pay date for processing, and the pay period for work attribution. That prevents chaos when one pay date moves.

Build the semi-monthly calendar (and decide your anchoring)

Semi-monthly calendars often look simple, until you notice months are not uniform. You still need to define what happens in February and how you handle payroll if the 15th is on a weekend or holiday.

Standard semi-monthly pattern

A common semi-monthly pattern is:

• Pay period 1 ends on the 15th, pay date is typically the 15th or shortly after (depending on approval lead time and whether the 15th itself is treated as a pay day).
• Pay period 2 ends on the last day of the month, pay date is typically the last day or the day shortly after.

Some policies treat the 15th and end-of-month as the pay dates and treat the day after as the start of the next period. Others treat pay periods as inclusive/exclusive differently. The important part is consistency.

In systems terms, pick a convention and stick to it:

• Time worked from [start date] inclusive to [end date] inclusive belongs to that pay period.
• Next period starts the following day.

Then for processing, you generate an adjusted pay date using your weekend and holiday rules.

February and the “last day” problem

February is where semi-monthly calendars show their teeth. If you anchor to “last day,” the second pay period ends on Feb 28 in non-leap years and Feb 29 in leap years. That means the coverage days change. It is not wrong, but you need to communicate it and ensure any accrual logic knows it.

Also confirm how your timesheet system calculates day ranges. Off by one errors often hide in inclusive end-date logic. For example, if you accidentally treat the end date as exclusive in one part of the system, your second semi-monthly period will overlap or leave a gap.

A semi-monthly calendar needs a separate “timesheet cut-off” view

Payroll departments rarely operate with perfect timing. Approvals, audits, exceptions, and vendor submission typically require lead time.

So instead of only listing pay dates, build two layers:

• A payroll calendar layer with pay periods and pay dates.
• A processing layer with cut-off dates for timesheets and final payroll submissions.

These can be derived. For example, if you need timesheets approved 2 business days before pay date, you can calculate cut-off dates once you know adjusted pay dates and your company’s holiday/weekend logic.

This reduces scrambling in December when every week includes a holiday.

Build the biweekly calendar (anchor it once, then repeat)

A biweekly payroll calendar starts with a single anchor date, usually the start date of the first pay period. From there, everything repeats every 14 days.

Pick the anchor date carefully

Your anchor date determines whether the calendar matches existing payroll cycles in your payroll system and whether your first pay period is short or full.

Common scenarios:

• You already have a vendor payroll schedule and want your calendar to match it.
• You are switching from semi-monthly to biweekly, and you need a “bridge” for the first partial period.
• New company start, where you set the first pay period to cover a reasonable onboarding window.

If you pick the anchor date casually, you may create a first pay period that is shorter than expected. That can affect bonus eligibility, retro pay allocations, or expectations around when employees “see” their first regular check.

Generate pay periods as 14-day blocks

For each pay period:

• Start date = anchor + (n * 14 days)
• End date = start date + 13 days (if end is inclusive)
• Pay date = end date + processing lead time (or the next scheduled processing day)

Then adjust pay dates using your weekend and holiday rules.

You will have 26 pay periods in most years, but it is not the same as “every other week on the first Monday.” Biweekly calendars move relative to months and sometimes relative to the same weekday in a human-friendly way.

A key judgment: decide whether pay dates should always land on a specific weekday (for example, every other Friday) once adjusted. Some organizations like consistent weekday patterns for employee predictability. Others prioritize “preceding business day” adjustments even if the weekday shifts due to holidays.

Either works, but document it.

The year-end and “missing week” feeling

In biweekly schedules, people sometimes feel like there is a missing week around year-end. That is usually the mental mismatch between calendar year months and the fixed 14-day cycle. Your calendar may show two pay dates close together in a month, and a long stretch in the next. That is not a failure. It is a property of biweekly.

The most important thing is that your internal reporting and accruals should not rely on a simplistic “one pay period per month.” If finance builds accrual entries expecting that rhythm, you will get surprised.

Semi-monthly vs biweekly: where the decisions show up

You can build either calendar mechanically, but your choice affects real workflows.

Employee experience and paycheck expectations

Semi-monthly is predictable within a month. If employees are paid on the 15th and last day, many people can plan rent and bills without looking anything up. Biweekly employees also learn the cadence, but they often think in weekly terms, so they notice the month-to-month variation.

When an organization has a large hourly workforce with tight budgeting patterns, semi-monthly stability can reduce payroll questions.

Accounting close and accruals

If you close accounts monthly, semi-monthly can look cleaner because there are exactly two pay events per month. Biweekly means some months have 3 pay periods and some have 2. In a 12-month year with 26 pay periods, the distribution is not perfectly even.

That affects your accrual method. Some companies accrue payroll expense based on work dates. Others accrue based on pay date and then true up. Either way, you will need to map the pay period end dates to the accounting period.

A good calendar spreadsheet includes a “work attribution period” mapping. Even if you do not use it for payroll processing directly, it prevents finance from having to reconstruct the mapping under pressure.

Payroll system behavior and reporting cycles

In many HRIS and payroll setups, the pay period is the unit for deductions, earnings statements, and benefit eligibility. Some systems expect pay period changes on consistent boundaries. Semi-monthly often fits well because those boundaries are the 15th and month-end. Biweekly can be just as compatible, but you must verify how the system handles employees joining mid-period.

That is an edge case you will hit repeatedly, especially in fast-growing companies.

Practical edge cases you should plan for

No payroll calendar survives contact with reality without exceptions. The trick is deciding what counts as an exception and what counts as normal variation.

Mid-period hires and terminations

When an semi monthly vs bi weekly pros and cons employee starts mid pay period, you typically pro-rate based on work dates. The calendar needs to support partial coverage.

For semi-monthly, because periods end on the 15th and month-end, new hires often start mid-period and then roll over on the 15th. For biweekly, roll over happens every 14 days, which can feel less predictable but is mathematically consistent.

Terminations need more attention than people assume. If an employee terminates near the end of a pay period, you may need to run an off-cycle payroll or at least ensure final pay is included correctly in the next scheduled run.

Your calendar should include a flag for whether a “final pay” event is eligible for inclusion in the next regular run based on your off-cycle rules and approval lead times.

Retro pay and correcting time

Retro pay is where calendars can quietly cause errors. If you correct time from a previous pay period after payroll has run, you need to determine:

• Which pay period earnings bucket it belongs to.
• Whether deductions should be recalculated for that period or applied in the next cycle.
• How to represent it on pay statements.

This is less about date selection and more about how your payroll configuration treats earnings retro. Still, the calendar is the map you will use when you decide where the correction lands.

Holidays that fall inside a work period

A holiday does not necessarily change pay period dates, but it does change workdays. If you are using an hours-based timesheet, holidays can reduce total billable hours. If you are using salaried rules, holiday handling may be simpler, but adjustments can still occur for differential pay or scheduled overtime rules.

The calendar should separate pay period coverage from workday calculation. In other words, the calendar lists dates, not worked hours assumptions.

A simple way to structure your calendar file

You can build a payroll calendar in a spreadsheet, but make it easy to audit. The calendar should answer three questions quickly for any date:

1. What pay period does this date belong to?
2. What is the adjusted pay date for that pay period?
3. What are the key internal deadlines?

If your spreadsheet only lists pay dates, you will end up cross-referencing internal policies and changing the sheet mid-year, which is a recipe for conflicting versions.

A practical layout uses columns for each concept, not just dates. For example, include:

• Pay period number
• Pay period start date
• Pay period end date
• Unadjusted pay date
• Adjusted pay date
• Pay date reason code (for example, “weekend move,” “company holiday move”)
• Timesheet cut-off date
• Payroll submission deadline

You do not need fancy automation to get value. You do need clarity.

Inputs you should confirm before you start generating dates

To build a reliable calendar, you need a few fixed inputs. Treat these like assumptions you can sign off on with HR and finance.

• Scheduled pay day preference (for example, last day of month for semi-monthly, Friday for biweekly)
• End-of-period convention (inclusive vs exclusive end date)
• Processing lead time (timesheet approval deadline and payroll submission deadline)
• Weekend and holiday adjustment rules
• Accounting attribution policy (by work date vs by pay date)

That set of inputs prevents the most common calendar disputes. People argue about one-off discrepancies because the rules were never pinned down.

Worked examples, showing how the difference feels

Example 1: semi-monthly around a short month

Imagine a semi-monthly employee has pay periods ending on the 15th and the last day. In February of a non-leap year, the second semi-monthly period ends on Feb 28. In March it ends on Mar 31. So even if you keep the same pay schedule structure, the second period length changes by several workdays.

That affects:

• timesheet totals
• accrual calculations, if you compute per-day rates
• expectations for employees who equate “pay period length” with “workload”

If you use fixed monthly salary division, you may not pro-rate by days. But if you allocate hours-based earnings, the day count difference matters.

Example 2: biweekly straddling month-end

Consider a biweekly payroll period that starts on the last week of January and ends in early February. You get a pay date in February, but the work includes dates from January.

If finance records expenses based on pay date only, February will show payroll expense for work performed in January. If finance records based on work date, the payroll system outputs need to map back across months.

This is why biweekly calendars typically require better reconciliation discipline than semi-monthly calendars.

Testing your calendar before you trust it for payroll runs

The calendar might be correct mathematically, but it still needs operational validation. Test it using scenarios you know will happen.

A good test suite is not complicated. You are looking for off-by-one errors, misapplied adjustments, and misaligned deadlines.

Here is what I typically validate in the first pass:

• The first 2 to 3 pay periods match the payroll system’s expected start and end logic.
• Any pay date that falls on a weekend moves to your defined preceding business day.
• Any pay date that falls on a holiday moves according to the correct holiday list.
• Month-end and February behavior do not create overlapping or missing coverage.
• Employee join dates and term dates on the boundary (for example, exactly on the 15th or exactly on the pay period end date) land in the correct pay period.

If you do semi monthly vs bi weekly this before the year begins, you reduce the odds of a late-year scramble when a holiday cluster hits.

Common pitfalls (and how to avoid them)

Even well-run teams stumble in predictable ways. These pitfalls are not about competence, they are about assumptions that feel “obvious” when you are building the sheet alone.

• Using one set of holiday rules in payroll but another set in HR, so pay dates adjust but time approval deadlines do not.
• Confusing pay period end date with the “last day worked,” causing overlaps or gaps when a system treats dates as inclusive differently.
• Forgetting to add processing lead time to the calendar, so cut-off dates fall on weekends or holidays without an override rule.
• Treating semi-monthly periods as identical lengths for accrual or per-day computations, leading to minor but real pay discrepancies.
• Anchoring a biweekly calendar to the wrong initial date during a transition period, creating a one-off shift for the rest of the year.

A lot of these mistakes can be caught by reviewing boundary dates visually, not just relying on formulas.

Choosing between semi-monthly and biweekly: judgment calls

If your organization is deciding which schedule to adopt, the choice is rarely purely technical. It is also about your workforce, your payroll workflow, and your accounting practices.

Semi-monthly tends to fit well when you want consistent monthly cadence and you have HR workflows built around the 15th and month-end. It can also reduce calendar questions from employees who prefer stable paycheck timing.

Biweekly tends to fit well when payroll processing workflows already assume a 14-day cycle, and when you want time worked windows to be consistent across pay periods. It can be a better match for organizations with strong timesheet systems and clear approval rhythms that repeat every two weeks.

One practical rule of thumb from experience: if your operation is already stable and your finance team is comfortable with monthly reconciliation across pay period boundaries, biweekly can work smoothly. If your finance team expects exactly two payroll events per month and relies on that assumption for accruals, semi-monthly may reduce rework.

If you are unsure, run a parallel calendar for one quarter. Track where adjustments and cut-offs fall, and look at how many times you would have needed to handle exceptions differently.

Putting it all together: an end-to-end workflow

A payroll calendar is more than a date generator. It is a living document that supports payroll runs, deadlines, and reporting.

A sensible workflow looks like this in practice:

First, confirm your policy rules: how you treat inclusivity of dates, what “pay date” means operationally, and what holiday move logic applies. Next, build the calendar in two layers, pay periods and processing deadlines. Then, generate the unadjusted dates and apply adjustments systematically. Finally, validate boundary scenarios and compare the first few pay periods against your payroll system settings.

Once you are confident, lock the structure and update only the inputs you must, such as holiday lists if they change. Resist the temptation to tweak individual pay dates after the year starts. When you do that, you change the meaning of the calendar and create a reconciliation gap.

If you need changes mid-year, document them and adjust downstream deadlines and accounting mappings to match the new truth.

How to keep it maintainable year after year

Calendars become unmaintainable when each year is rebuilt from scratch with new formulas and new assumptions. A better approach is to treat the calendar as a template and update only what changes.

What typically changes year to year:

• specific holiday dates
• the leap year status affecting semi-monthly “last day” in February
• any internal policy changes to deadlines or weekend adjustment rules

What usually should not change:

• your end-of-period date convention
• your definition of the pay period coverage
• your approach to payroll processing deadlines relative to pay date

If you keep those stable, your spreadsheet becomes a tool rather than a re-creation.

Final reality check: the calendar should match how payroll actually runs

The most effective payroll calendar is not the one that looks neat on paper. It is the one that matches the way people do approvals, submit files, and handle exceptions.

When you build the calendar for semi-monthly versus biweekly, the core work is not the date math. It is aligning policy decisions with operational deadlines and making sure finance and HR use the same definitions.

If you do that, you will spend fewer late nights adjusting “just this one pay date” and more time addressing the real payroll issues that show up in every organization, like staffing changes, timesheet compliance, and retro corrections.

And that is the goal.