The pay period that belongs to two months
A pay period runs from 27 April to 10 May and pays on 15 May. April owns four of its ten working days, May owns six, and the ledger sees nothing at all until pay day, unless somebody accrues. This page does the split on purpose.
◆ Why the ledger is blind until pay daycost happens daily, posting happens on pay date.
People earn pay every working day, but the payroll run posts once, on the pay date. Without an accrual, April closes carrying none of the cost its last four working days created, and May carries all of it. Neither month is wrong twice the same way: a month with three pay dates overstates, the next understates.
The monthly numbers in the labor cost report are on the work-date basis precisely because of this: cost belongs to the days that created it, not to the Friday the bank file went out.
◆ The split, workedten working days, four April, six May.
| Period 27 Apr to 10 May | Working days | Share |
|---|---|---|
| April share, 27 to 30 Apr | 4 | 841,700.00 |
| May share, 1 to 8 May | 6 | 1,262,550.00 |
| Full period gross cost | 10 | 2,104,250.00 |
The split runs on working days from the shared date table, not calendar days: 27 April 2026 is a Monday, so April contributes Monday through Thursday and May contributes Friday the 1st plus the full week of the 4th. Each share is days over ten times the period cost, to the cent. Sample values are illustrative, never client data.
◆ The three entriesaccrue, reverse, post; May nets to its own share.
| Date and entry | Amount |
|---|---|
| 30 Apr, accrue the April share into April | 841,700.00 |
| 1 May, reverse the accrual | -841,700.00 |
| 15 May, the pay run posts the full period | 2,104,250.00 |
| Net cost landing in May | 1,262,550.00 |
The reversal is what makes the pattern safe: the run posts the whole period without anyone splitting the actual pay lines, and the two May entries net to exactly the May share. April keeps its 841,700.00, May keeps its 1,262,550.00, and nothing was booked twice.
◆ The owned answerthe calendar does the split, every period, no judgement calls.
The build keeps pay periods and the working-day calendar as tables, so the straddle share is a query result, not a controller's estimate. When a holiday moves a working day, the split moves with it, and the ledger tie proves the accrual and reversal both landed.
-- Working-day split for any straddling period
SELECT p.period_id, d.month_key, COUNT(*) AS work_days,
ROUND(p.gross_cost * COUNT(*) * 1.0 /
(SELECT COUNT(*) FROM dim_date x
WHERE x.date_key BETWEEN p.start_date AND p.end_date
AND x.is_working_day = 1), 2) AS month_share
FROM fct_pay_period p
JOIN dim_date d
ON d.date_key BETWEEN p.start_date AND p.end_date
AND d.is_working_day = 1
GROUP BY 1, 2
The same date table serves every module in this catalog, which is the quiet point: an accrual is only as defensible as the calendar underneath it.
- accrual
- Cost booked into the month that earned it, ahead of the actual payment.
- reversal
- The equal, opposite entry on the first of the next month.
- pay period
- The date range a run pays for, here 27 April to 10 May.
- pay date
- The day the run posts and the money leaves, here 15 May.
- work date
- The day cost was actually earned; the basis the reports use.
- straddling period
- A pay period whose date range crosses a month end.
- working day
- A weekday the calendar counts for the split; ten in this period.
- close
- The point where a month's books are finalized, here 30 April.