CWPS Monthly Schedule from Construction Payslips (Ireland)

It is the first working day after month-end. On a construction firm running weekly payroll, that means a stack of weekly payslip PDFs across every Specified Worker for the closed month, an empty CPAS-format member schedule template waiting to be populated, and a 21-day clock that started running at midnight on the last day of the month. The deliverable is a CWPS monthly schedule from construction payslips: a per-worker roster for the contribution month showing each Specified Worker's total Pension contribution and total Sick Pay contribution, signed off, paid to the trustees, and tied back to the GL.

That 21-day window is statutory, not a service-level commitment from CPAS. Section 58A of the Pensions Act 1990 requires that contributions deducted from employees' wages, and employer contributions to a defined-contribution scheme, be remitted to the trustees within 21 days from the end of the month in which the deduction was made. The schedule and the payment both have to land inside that window, which is why most practitioner CWPS work is organised backwards from day 21.

The Two CWPS Lines And The Full-Week Rule

Two contributions are payable per Specified Worker per contribution week. Pension is 7% of the worker's basic-rate weekly pay — 4.2% employer, 2.8% employee — with Death-in-Service rolled into the percentage rather than charged separately, so a payslip showing a DIS line on top of a 7% Pension line is double-counting. The 7% applies to the basic-rate baseline set by the Sectoral Employment Order in force for the worker's category. Sick Pay is not a percentage: it is a fixed weekly amount per Specified Worker, currently €0.63 deducted from the employee and €2.37 paid by the employer, on top of the Pension line.

Open any Specified Worker's weekly payslip and the two contributions sit on two lines — typically labelled CWPS Pension and CWPS Sick Pay (or CWPSPT, depending on the payroll product). Labels vary; the two-line structure does not, because the lines sit on opposite sides of the income-tax calculation. Pension and its embedded Death-in-Service are PAYE-allowable — deducted from gross pay before income tax, with tax relief at source on the 2.8% employee share. Sick Pay is deducted from net pay, post-tax, with no PAYE relief. A payroll product that consolidated them would lose its PAYE-allowability evidence on a Revenue review. (For a reader newer to Irish payslip layouts in general — gross pay, PAYE, USC, PRSI, the two CWPS lines, net pay — keep the line-by-line primer on how to read an Irish payslip open alongside this section.)

Two practitioner traps run through this. The first is the full-week rule: CWPS contributions are payable for a full week irrespective of how many days the worker actually worked in that week, with no proration to days, half-days, or hours. A worker who turns up for one shift and is off for the rest of the week is still on payroll for the full week's Pension percentage and the full week's Sick Pay split. Bookkeepers coming from a PAYE/USC/PRSI world where partial-week proration is normal routinely assume CWPS works the same way and prorate it down. It does not, and the schedule comes in short — a firm with thirty Specified Workers and a handful of partial weeks can be thousands of euro short on the CPAS submission, and this is the most common single source of GL-versus-schedule mismatches at month-end.

The second trap is in aggregation. A bookkeeper used to summing one deduction line per worker per week may, when building the monthly view, collapse the two CWPS lines into one combined figure per worker. The schedule total may still reconcile back to the GL — both lines are payables to CPAS — but the CPAS member schedule reports Pension and Sick Pay separately and cannot be populated cleanly from a single combined number, and the audit trail that defends the PAYE-allowable share against a Revenue review is gone. The aggregation the schedule needs is two separate sums per worker per month, kept distinct end to end. Where accounting practice supports it, the GL is best set up with separate sub-accounts or sub-analyses for CWPS Pension and CWPS Sick Pay rather than a single combined payable.

From Weekly Payslip PDFs To Per-Worker Monthly Rows

The bridge between the closed month's payslips and the CPAS schedule is a structured per-worker per-week dataset. Build it once at the start of the cycle and aggregation, schedule population, GL tie-out, and audit retention all run off it. (This article assumes the bookkeeper can already lift PAYE, USC, PRSI, gross pay, and net pay off a standard Irish payslip; the general primer on how to extract Irish payslip data to Excel covers that ground for anyone coming from a non-construction PAYE background.)

The column shape is fixed by the mechanics above. One row per Specified Worker per pay-period week, with the worker identifier (PPS number or internal worker ID, plus the name as held on the CPAS member record), the week-ending date, gross pay, the four CWPS columns kept separate (Pension employee, Pension employer, Sick Pay employee, Sick Pay employer), and PAYE/USC/PRSI retained for the Revenue cross-tie. The Pension and Sick Pay columns staying broken out at this stage is what carries the PAYE-allowability split through aggregation.

Validate every weekly payslip in the dataset before aggregating: the full-week rule has to be honoured on every contribution week the worker appears for, the rates applied to the Pension and Sick Pay lines have to match the SEO baseline in force for that week, and gross pay minus statutory deductions minus CWPS Pension minus CWPS Sick Pay should reconcile to the net pay on the payslip. The bookkeeper should validate CWPS deductions on each weekly payslip before any of those rows is summed into a monthly view — a weekly figure that is wrong at source remains wrong when it is aggregated.

Aggregation is mechanical. For each Specified Worker on payroll during the contribution month, sum the four weekly CWPS columns across every week the worker appeared. The result is one row per worker carrying four monthly contribution totals, ready for the schedule. Joiners and leavers appear in the aggregate for exactly the weeks they were on payroll for, as long as the weekly dataset records the week count accurately.

Volume makes the manual route untenable at any reasonable size. A firm with thirty Specified Workers running weekly payroll produces 120 to 150 weekly payslip PDFs per month; a bureau with three or four construction clients sees 400 to 600 across the same window, with different payroll products generating different layouts on the underlying documents. Invoice Data Extraction takes the batch as a single upload and returns a structured Excel, CSV, or JSON file with one row per worker per week, the columns named in the bookkeeper's prompt and the four CWPS lines broken out exactly as the aggregation needs them. The platform extracts structured payroll data from construction payslip PDFs in batches large enough to cover a full month's payroll for a multi-client bureau in one job. The tool produces the dataset; the bookkeeper still applies the full-week rule, the SEO-baseline rates, and the Specified Worker classification.

Building The CPAS Member Schedule From The Aggregated Dataset

CPAS issues a schedule template to the member firm — typically pre-populated with the firm's active member list as CPAS holds it — and the bookkeeper completes the template from the per-worker monthly aggregate. Each Specified Worker appears as one row identified by the worker identifier on the CPAS member record, with the monthly Pension and Sick Pay totals against it (employer and employee components combined or separated by template version). Where the aggregate is clean, the build is mostly a copy across with worker identifiers reconciled to the CPAS member record.

The cases that diverge from a clean copy-across are where the schedule needs active handling.

Joiners and leavers sit on the schedule for exactly the contribution weeks they appeared on payroll for. A joiner's first contribution week is the week ending after they started; a leaver's last is the week ending after their final shift. The aggregate carries the right count if the weekly dataset recorded the pay-period weeks accurately, but the schedule line is the place to confirm it — missing a joiner's first full-week contribution, or carrying a leaver into a week they were no longer on payroll for, both surface on the GL tie-out as a per-worker mismatch.

Workers on payroll during the month who are not Specified Workers under the SEO construction-sector definition — office staff, certain administrative roles, workers outside SEO scope — should not appear on the CPAS schedule at all. Misclassification at the schedule line is one of the named mismatch sources the reconciliation handles, and it is much cheaper to spot at the schedule build than after submission.

Workers paid above the SEO basic rate need their Pension percentage confirmed against the right baseline before the row goes on the schedule. The 7% applies to the SEO basic rate for the worker's category; if payroll has been calculating against actual gross pay rather than the SEO baseline, the per-worker monthly Pension figure on the aggregate will not match the figure the schedule expects.

The schedule total — the sum of every per-worker Pension and every per-worker Sick Pay across the month — has to equal the GL CWPS control-account movement and the bank payment to CPAS. Compute it once from the aggregate and carry it through to the schedule footer as the single number the next section reconciles against. The schedule plus the bank payment together constitute the monthly submission package; returning the schedule without a matching bank payment, or paying without the schedule, both leave the firm out of compliance with Section 58A even if one half of the package arrives on time.

Reconciling The Schedule To The GL Control Account And The Bank Payment

The reconciliation that proves the schedule before remittance is a single identity in four parts. The sum of the weekly payslip CWPS deductions across the contribution month — Pension and Sick Pay separately analysed — equals the monthly CPAS schedule total, equals the movement on the GL CWPS control account or accounts for the period, equals the bank payment to CPAS that clears within the 21-day window. The cleanest GL structure to run the tie-out against has separate control accounts (or sub-analyses on a single account) for CWPS Pension and CWPS Sick Pay; on a GL set up that way, the trial balance produces four numbers — Pension employer expense, Pension employee payable, Sick Pay employer expense, Sick Pay employee payable — that aggregate to the schedule total without further analysis.

When the GL does not agree with the schedule total, the mismatch is almost always one of four things:

• Misclassified workers. A non-Specified Worker has had a CWPS line posted to their payslip and into the GL — possibly because the payroll record was set up as Specified at hire and never corrected — so the GL carries a contribution that does not appear on the schedule. The inverse also occurs: a Specified Worker set up without the CWPS lines means the schedule expects them but the GL has nothing posted. Both surface at the per-worker level in the structured dataset.
• Missed full-week contributions during partial-week payroll runs. Payroll has prorated CWPS down on a partial-week pay run that should have carried the full week's contribution, and the schedule comes in short of the GL. A scan of the weekly dataset for any worker week where the Pension or Sick Pay figure is below the expected weekly amount surfaces them.
• Rate-uplift weeks straddling a Sectoral Employment Order step. Any contribution month containing an SEO effective date is a candidate for a per-week rate mismatch — one or more weeks calculated against the wrong baseline, with GL and schedule disagreeing by the rate delta. August and September month-ends in particular need the SEO date pinned before the tie-out is signed off (the next section walks the mechanic).
• Sick Pay applied for the wrong number of weeks. Usually attaches to mid-month joiners and leavers, where the contribution-week count on the schedule differs from the count carried in the payroll runs and GL by one week in either direction. The per-worker week count is visible in the weekly dataset and on the schedule line, and the two simply have to agree.

The bank-payment leg closes the chain. The payment to CPAS equals the schedule total and reaches the trustees' account within the 21 days set by Section 58A. The bookkeeper retains the payment confirmation, the bank-statement line that carries the debit, and the matched remittance reference quoted on both, alongside the schedule and the underlying weekly dataset. Those three artefacts — schedule, bank-payment evidence, weekly per-worker dataset — close the reconciliation, and they close a CPAS audit on the period.

SEO 2024 And The 4 August 2025 Step: Handling Rate-Transition Boundaries

CWPS contribution rates move with the Sectoral Employment Order basic rate for the construction sector, which is what the 7% Pension calculation runs against and what the fixed weekly Sick Pay amounts are reset alongside. Two recent SEO steps frame current and back-record work: the 5 August 2024 Order (formally S.I. 620/2024) introduced the Sick Pay weekly split now in force (€0.63 employee, €2.37 employer) and reset the SEO basic-rate baseline that Pension is calculated against; the 4 August 2025 step shifted the basic-rate baseline again, with CWPS Pension moving in lockstep and Sick Pay weekly amounts reset for periods from that effective date forward.

The practitioner mechanic at a week that contains an SEO effective date is to pin the rate to the contribution-week-ending date rather than to a calendar mid-week split. The new rate applies to weeks ending on or after the effective date; the prior rate applies to weeks ending before it. A pay-week ending on 4 August 2025 runs on the prior rate; a pay-week ending on 11 August 2025 runs on the new rate. There is no proration of rates within a single contribution week — the same logic that gives the full-week rule its bite gives the rate boundary its sharpness.

August and September month-ends are where this matters in practice. The schedule still produces one monthly Pension total and one monthly Sick Pay total per worker, but the per-week working underneath has to use the prior rate for weeks ending before the effective date and the new rate for weeks ending on or after it. The structured per-worker per-week dataset is what makes the per-week rate visible to the reconciliation rather than something the bookkeeper has to reconstruct from payslips after a CPAS audit query lands.

Working Backwards From The 21-Day Clock And What A CPAS Audit Pulls

The whole month-end runs against the 21 days from month-end set by Section 58A, and the cleanest way to plan against it is backwards from the deadline rather than forwards from the close. The 21-day remittance window for CWPS is the same kind of statutory clock the bookkeeper already runs against for the Revenue payroll submissions and the RCT period close — the latter has its own 23rd-of-the-month deadline, walked in detail in the practitioner guide to reconciling and amending the monthly RCT Deduction Summary on ROS — and it sits alongside those on the month-end calendar. The QS-side equivalent — the 21-day Payment Schedule the firm has to issue in response to a subcontractor's Payment Claim Notice under the Construction Contracts Act 2013 — runs on the same statutory cadence and is worth pinning to the same calendar where the back office handles both.

The backwards plan, with each step backsolved from day 21:

• Day 21 from month-end. Schedule has been submitted to CPAS and the bank payment has cleared into the trustees' account. This is the date the firm has to be able to evidence the schedule and the payment landing — not the date the firm initiated either of them.
• One to two working days earlier. Payment initiated by the firm's bank. SEPA Credit Transfer typically clears in one to two working days under normal conditions; non-standard remittance routes can take longer. Whoever owns the bank instruction needs the payment ready to release on a date that gets it to the trustees inside the window with a working-day buffer.
• Earlier still. Schedule signed off by the responsible person and the bank-payment instruction prepared. Sign-off is the final check that the schedule total, the GL movement, and the payment instruction all carry the same number, and that the worker roster on the schedule matches the firm's Specified Worker list for the contribution month.
• Earlier again. Schedule reconciled to the GL CWPS control account, the four-part reconciliation identity confirmed, and any mismatches resolved at the per-worker level. This is the work the previous two sections walk.
• Earliest. Weekly payslips for the closed month extracted into the structured per-worker per-week dataset, validated against the full-week rule and the SEO-baseline rates in force for each week, and aggregated into the per-worker monthly view that populates the schedule.

For a contribution month with five pay weeks closing on a Friday, the practical effect is that the bookkeeper has roughly two weeks of working days from month-end to do the dataset build, validation, aggregation, schedule populate, GL tie-out, and sign-off, with roughly a working week between sign-off and payment-clear. Firms running tight on the schedule build typically squeeze the wrong end — they delay the dataset work and find themselves doing reconciliation against an unrecoverable bank-clearing deadline. Pushing the dataset build to the first working day after the close is what gives the rest of the chain room to land cleanly.

A CPAS audit asks for the same three artefacts the reconciliation already required: the schedule submitted for the contribution month, the bank-payment evidence (payment confirmation, bank-statement debit, matched remittance reference), and the underlying structured per-worker per-week dataset with the CWPS Pension and Sick Pay lines as separate columns and the per-week rate evidence for any SEO-boundary weeks. Every line on the schedule has to trace to a row in the dataset and onward to a source weekly payslip PDF. The firm that retains the dataset alongside the schedule and the bank-payment evidence closes audit queries in seconds; the firm that retains only the schedule and the PDFs ends up rebuilding the dataset under time pressure.