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.

The headline shape of that schedule is straightforward enough to commit to memory. Pension is 7% in total per Specified Worker per contribution week, split 4.2% employer and 2.8% employee, with Death-in-Service rolled into the percentage rather than added on top. Sick Pay is a fixed weekly amount per Specified Worker, currently €0.63 deducted from the employee and €2.37 paid by the employer, a split that has been in force since the 5 August 2024 Sectoral Employment Order uplift. The schedule lists each Specified Worker, the worker's monthly Pension contribution aggregated across the four or five contribution weeks of the month, and the worker's monthly Sick Pay contribution aggregated the same way. The schedule total has to equal the movement on the GL CWPS control account for the period and equal the bank payment to CPAS, and all three have to be in the trustees' hands within 21 days of month-end.

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, per the Pensions Authority FAQs on remittance of contributions. 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 rather than forwards from the close.

If the broader Irish payslip extraction task itself is unfamiliar territory and you are coming to construction payroll month-end CWPS schedule preparation from a non-construction PAYE background, it is worth reading the more general primer on how to extract Irish payslip data to Excel before going further. The construction-specific work in this article assumes you can already lift PAYE, USC, PRSI, gross pay, and net pay off a standard Irish payslip without help.

The work the rest of this article walks is the chain that turns the stack of PDFs into a remitted, reconciled monthly submission. Weekly payslip PDFs become a structured per-worker per-week dataset. That dataset aggregates, by worker, across the contribution weeks of the month into a per-worker monthly view. The per-worker monthly view populates the CPAS member schedule. The schedule total reconciles to the GL CWPS control account and onward to the bank payment to CPAS within the 21-day window. The same three artefacts that close the reconciliation also close a CPAS audit when one comes asking: the schedule, the bank-payment evidence, and the underlying weekly payslip dataset. Two practitioner traps run through every step of the chain, and they are the reason the work cannot be a copy-paste from a payroll-software report into a CPAS template, regardless of which payroll product the firm runs.

The CWPS Contribution Mechanic And The Full-Week Rule

Two contributions are payable per Specified Worker per contribution week, and they behave differently from each other on the payslip and on the schedule.

The Pension contribution is a percentage. Seven per cent of the worker's basic-rate weekly pay is payable in total — 4.2% by the employer and 2.8% by the employee. The Death-in-Service benefit the scheme provides is funded out of that 7% rather than charged separately, so a payslip that shows 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 — which is the lever the 4 August 2025 SEO step pulled when it last changed CWPS rates, covered later in the article.

The Sick Pay contribution is not a percentage. It is a fixed weekly amount per Specified Worker: €0.63 deducted from the employee and €2.37 paid by the employer, on top of the Pension line. The amount does not move with the worker's gross pay for the week, and there is no per-week proration of it for hours worked. A worker who appears on payroll for the week incurs the full weekly Sick Pay split; a worker who does not, does not.

This is where the first practitioner trap surfaces. CWPS contributions are payable for a full week irrespective of how many days the Specified Worker actually worked in that week. There is no proration to days, half-days, or hours. A worker who turns up for one shift and then is off for the rest of the week is on payroll for that week, and the full week's Pension percentage and the full week's Sick Pay split both apply. Bookkeepers coming from a PAYE/USC/PRSI world where partial-week proration is normal — and for Irish weekly construction payroll, almost all bookkeepers come from that world — routinely assume CWPS works the same way and prorate it down. It does not, and the schedule that results comes in short.

The full-week rule sounds like a small footnote until it lands on the schedule. A firm with thirty Specified Workers and a handful of partial weeks across the month can be thousands of euro short on the CPAS submission because every prorated week loses a Pension contribution against the SEO basic rate and a €3.00 combined Sick Pay contribution. That shortfall is also the most common single source of GL-versus-schedule mismatches at month-end, and it is the cleanest one to prevent at the per-worker per-week stage rather than chase down on the reconciliation.

Every contribution week the worker appears on payroll therefore produces one full Pension contribution and one full Sick Pay split, which the monthly schedule aggregates against that worker's row across the four or five contribution weeks of the month.

Why CWPS Appears As Two Deductions On The Payslip

Open any Specified Worker's weekly payslip and CWPS will not be on a single line. There will be two CWPS-related deductions, usually labelled along the lines of CWPS Pension (or just Pension) for the 7% Pension-and-Death-in-Service line, and CWPS Sick Pay (or Sick Pay Trust, or CWPSPT) for the €0.63 weekly Sick Pay line. Different payroll products use different label conventions, but the two-line structure is consistent across them, and there is a tax-code reason for it that the schedule has to respect. (For a reader newer to Irish payslip layouts in general — gross pay, PAYE, USC, PRSI, the two CWPS lines, net pay — the line-by-line primer on how to read an Irish payslip is the right reference to keep open alongside this section.)

The Pension contribution — and the Death-in-Service rolled into it — is PAYE-allowable. It is deducted from the worker's gross pay before income tax is calculated, so the worker gets income-tax relief at source on their 2.8% employee share. The Sick Pay contribution is not PAYE-allowable. It is deducted from the worker's net pay after income tax has been applied, so the €0.63 employee share comes out of after-tax money with no PAYE relief. The two cannot share a payslip line because they sit on different sides of the income-tax calculation, and a payroll product that consolidated them would lose its PAYE-allowability evidence on a Revenue review.

That mechanic is the second practitioner trap. The trap is in aggregation, not in calculation. A bookkeeper who is used to summing one payroll deduction line per worker per week may, when building the monthly view, collapse the two CWPS lines into one combined CWPS figure per worker. The schedule total may still reconcile back to the GL — both lines are payables to CPAS — but two things break. First, the CPAS member schedule reports Pension and Sick Pay separately and cannot be populated cleanly from a single combined number. Second, the audit trail that defends the PAYE-allowable share against a Revenue review is gone, because there is no longer a record of which portion of the monthly contribution was deducted pre-tax versus post-tax.

The aggregation that the schedule needs is therefore two separate sums per worker per month, kept distinct end to end. The per-worker monthly Pension total is the sum of the weekly Pension lines across the four or five contribution weeks; the per-worker monthly Sick Pay total is the sum of the weekly Sick Pay lines across the same weeks. Those two totals go into different columns of the CPAS schedule and trace back to different lines on the underlying weekly payslips. Where the firm's accounting practice supports it, this is also the reason 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 CWPS 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 schedule cycle and the rest of the work — aggregation, schedule population, GL tie-out, audit retention — runs off it. Skip it and the bookkeeper ends up reading off PDFs into a spreadsheet by hand, which is where most of the avoidable errors enter.

The dataset is a two-stage move. The first stage is extraction: every Specified Worker's weekly payslip across the closed month becomes a row of structured data, with each CWPS line broken out as a separate column rather than collapsed into a payslip-deduction blob. The second stage is aggregation: those weekly rows roll up by worker across the four or five contribution weeks of the month into a per-worker monthly view that the schedule is populated from.

The column shape that makes the rest of the chain work is fixed by the article's earlier mechanics. One row per Specified Worker per pay-period week, with at minimum the worker identifier (PPS number or internal worker ID, plus the worker's name as held on the CPAS member record), the pay-period week-ending date, gross pay for the week, the four CWPS columns kept separate (CWPS Pension employee, CWPS Pension employer, CWPS Sick Pay employee, CWPS Sick Pay employer), and the PAYE, USC, and PRSI lines 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; collapsing them here would force the bookkeeper to derive the split back from the payslips at audit time, which is the slowest possible way to defend it.

Before aggregating, validate every weekly payslip in the dataset. 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 per-payslip audit framework that walks this in detail is published separately, and 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 the source remains wrong when it is aggregated; pushing the validation upstream of the aggregation is what keeps the schedule defensible.

Aggregation itself is mechanical once the weekly dataset is clean. For each Specified Worker who appeared on payroll during the contribution month, sum the weekly CWPS Pension employee column, the weekly CWPS Pension employer column, the weekly CWPS Sick Pay employee column, and the weekly CWPS Sick Pay employer column across all weeks the worker appeared. The result is one row per worker carrying four monthly contribution totals, ready to populate the schedule. Workers who joined or left mid-month appear in the aggregate for exactly the weeks they were on payroll for; their week count flows through the sum naturally as long as the weekly dataset records it accurately.

The volume reality of this step is what makes the manual route untenable at any reasonable size. A firm with thirty Specified Workers running weekly payroll produces around 120 to 150 weekly payslip PDFs per month. A bureau with three or four construction clients can be looking at 400 to 600 PDFs across the same window, with different payroll products generating different layouts on the underlying documents. Doing the extraction by retyping fields into a spreadsheet means the audit trail starts with whatever errors the typist made, and the cross-software bridge — what makes the reconciliation chain work regardless of whether the firm is on BrightPay, Thesaurus, Sage IE, Payback, or anything else — becomes the structured dataset, not any individual payroll product's report screens.

This is where extracting CWPS contributions from payslips becomes the load-bearing step rather than a chore alongside the schedule build. Invoice Data Extraction takes the batch of weekly payslip PDFs as a single upload and returns a structured Excel, CSV, or JSON file with one row per worker per week, with the columns named in the bookkeeper's prompt. The tool can extract 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, and the output keeps the CWPS Pension and CWPS Sick Pay columns broken out exactly as the aggregation needs them. Payroll documents are the second most common document type the platform processes after invoices, and the extraction does not depend on which payroll product produced the PDFs — the prompt names the columns and the same structured output emerges across formats.

What the tool does and does not do at this step is worth being precise about. It produces the structured per-worker per-week dataset from the PDFs. It does not build the CPAS member schedule, apply the full-week rule on the bookkeeper's behalf, decide whether a worker is a Specified Worker under the SEO definition, or pick the correct rate for an SEO-boundary week. Those rules are the bookkeeper's to apply against the extracted dataset, and the next sections walk that side of the work.

Building The CPAS Member Schedule From The Aggregated Dataset

The deliverable that goes to the trustees is a per-worker roster for the contribution month. 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 that template from the per-worker monthly aggregate produced in the previous section. Each Specified Worker appears as one row, identified by the worker identifier on the CPAS member record. Against that row sit the worker's monthly Pension contribution and the worker's monthly Sick Pay contribution, with the employer and employee components either combined or shown as separate columns depending on the schedule template version in use.

Population is straightforward where the aggregated dataset is clean. The per-worker monthly Pension total from the aggregate goes into the Pension column on the schedule row; the per-worker monthly Sick Pay total goes into the Sick Pay column on the same row. The contribution month and the firm's submission reference go into the schedule header. The CWPS pension and sick pay aggregation work has been done at the dataset stage, and the schedule build itself is mostly a copy across with the worker identifiers reconciled to CPAS's member record.

The cases that need active handling are the ones that fall outside a clean copy across, and they are where the schedule diverges from a straight read-off of the aggregate.

Workers who joined or left mid-month sit on the schedule for exactly the contribution weeks they appeared on payroll for. The aggregate carries the right week count if the weekly dataset recorded each worker's pay-period weeks accurately, but the schedule line is the place to confirm it. A joiner's first contribution week is the week ending after they started; a leaver's last contribution week is the week ending after their final shift. Missing a joiner's first full-week contribution at the edge, or carrying a leaver into a week they were no longer on payroll for, both surface on the GL tie-out in the next section as a per-worker mismatch.

Workers who appeared on payroll during the month but are not Specified Workers under the SEO definition for the construction sector should not appear on the CPAS schedule at all. Office staff, certain administrative roles, and workers outside the SEO scope are common cases. Misclassification at the schedule line — a non-Specified Worker carried onto the schedule, or a Specified Worker omitted — 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 on rates other than the SEO basic rate — typically more senior staff, or workers on a contractually higher 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 the percentage against actual gross pay rather than against the SEO baseline, the per-worker monthly Pension figure on the aggregate will not match the figure the schedule expects, and the row needs adjusting before submission.

The schedule total is the sum of every per-worker Pension contribution and every per-worker Sick Pay contribution across the month — the figure that has to equal the GL CWPS control-account movement and the bank payment to CPAS. Compute it once from the aggregate, carry it through to the schedule footer, and treat it as the single number the next section reconciles against.

The schedule plus the bank payment together constitute the monthly submission package. Returning the completed schedule to CPAS 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. CPAS monthly contribution submission is a two-part act, and both parts have to be in the trustees' hands inside the 21-day window.

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 — gross of the employer share, with 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 bookkeeper signs off on that identity before submission, and the same identity is what closes a CPAS audit query when one comes asking. CWPS reconciliation in Ireland is not a separate exercise on top of the schedule build; it is the schedule build's terminal check.

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, with the employer share recognised as a payroll expense and the employee share recognised as a payable accrued from gross pay (Pension) or net pay (Sick Pay). On a GL set up that way, the trial balance shows four numbers for the period — Pension employer expense, Pension employee payable, Sick Pay employer expense, Sick Pay employee payable — that aggregate cleanly to the schedule total without any further analysis. Where the firm's GL collapses everything into a single CWPS payable, the reconciliation still works, but the split has to be derived from the underlying ledger postings rather than read off the trial balance, and the work expands accordingly.

When the four numbers on the GL do not agree with the schedule total, the mismatch is almost always one of four things rather than a calculation error inside the aggregate.

The first is 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 — and the GL carries a contribution that does not appear on the schedule. Or the inverse: a Specified Worker has been set up without the CWPS lines, the schedule expects them but the GL has nothing posted for them. Both surface at the per-worker level, and the structured per-worker per-week dataset is the fastest way to find which worker is on which side of the disagreement.

The second is missed full-week contributions during partial-week payroll runs. The full-week rule named earlier in the article shows up downstream as a schedule total that runs short of the GL, because payroll has prorated CWPS down on a partial-week pay run that should have carried the full week's contribution. A scan of the weekly dataset for any worker week where the Pension or Sick Pay figure is below the expected weekly amount, against any worker week where the worker appeared on the gross-pay column, surfaces them.

The third is rate-uplift weeks straddling a Sectoral Employment Order step. The next section walks the SEO mechanics in detail; the reconciliation note is that any contribution month containing an SEO effective date is a candidate for a per-week rate mismatch, where one or more weeks were calculated against the wrong baseline and the GL and schedule disagree by the rate delta. August and September month-ends in particular need the SEO date pinned before the tie-out is signed off.

The fourth is Sick Pay applied for the wrong number of weeks. This usually attaches to workers who joined or left mid-month, where the contribution-week count on the schedule does not match the contribution-week count carried in the payroll runs and the GL — typically by one week, in either direction. It is the cheapest mismatch to find because 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 for the period equals the schedule total and reaches the trustees' account within the 21 days from month-end set by Section 58A. The bookkeeper retains the bank-payment evidence — 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 payslip dataset. Three artefacts in total: the schedule itself, the bank-payment evidence, and the structured per-worker per-week dataset that the schedule was built from. Those three together are what closes the reconciliation, and the same three are what closes a CPAS audit on the period.

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

CWPS contribution rates do not move on their own clock. They move with the Sectoral Employment Order basic rate for the construction sector, which is what the 7% Pension calculation is run against and what the fixed weekly Sick Pay amounts are reset alongside. Two recent SEO steps frame the work a bookkeeper is most likely to encounter on current and back-records.

The 5 August 2024 Sectoral Employment 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. Any contribution week ending on or after 5 August 2024 runs on those rates; weeks ending before that date run on the prior set. The 4 August 2025 SEO step shifted the basic-rate baseline again, with CWPS Pension moving in lockstep and Sick Pay weekly amounts reset to the figures in force from that effective date forward. A bookkeeper preparing a current schedule is on the post-4-August-2025 rates; a bookkeeper preparing or reviewing a back-record needs the right rates for the relevant period and may need both.

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, and 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 the 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 the contribution months where this matters in practice, because they are the months where an SEO effective date lands inside a single CPAS submission window. The schedule still produces one monthly Pension total and one monthly Sick Pay total per worker — the deliverable shape does not change — but the per-week working underneath those totals has to use the prior rate for weeks ending before the effective date and the new rate for weeks ending on or after it. Aggregation runs the same way it does in any other month; what changes is the rate the per-week figures were calculated against in the first place, and the structured per-worker per-week dataset is what makes that visible across the boundary.

Three recurring mistakes attach to SEO-boundary months, and each shows up differently on the reconciliation.

Applying the new rate to the whole month retrospectively is the most common. Payroll software updates after the effective date and the bookkeeper, working backwards from the post-step rates, recomputes the prior weeks at the new figures. The schedule comes in over the GL by the rate delta on every pre-effective-date week, and the tie-out fails until the prior weeks are restored to the prior rate.

Applying the old rate across the boundary is the inverse. The payroll software was not updated in time for the first post-effective-date pay run, the prior rate was carried into a week ending after the SEO date, and the schedule comes in under the GL once the GL is corrected. Where this is not caught at the schedule build, it surfaces on a CPAS audit query against the post-effective-date weeks.

Collapsing the rate working into a single combined figure without retaining the per-week evidence is the third. The schedule may pass submission because the totals are right, but a CPAS audit asking "show me the rates you used for the 4 August week and the 11 August week" cannot be answered from the schedule alone, and the answer has to be reconstructed from payslips after the fact. Retaining the per-week working as part of the structured dataset closes that loop in advance.

All three of these are versions of the same reconciliation mismatch the previous section flagged: rate-uplift weeks straddling an SEO step are the third named mismatch source on the schedule-to-GL tie-out. 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 remember and reconstruct.

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, and it sits alongside those on the month-end calendar.

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, the validation, the aggregation, the schedule populate, the GL tie-out, and the sign-off, and 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, when one comes asking, does not ask for the payroll software's CWPS report or the pay-run summary. It asks for three things, and they have to tie to each other.

First, the CPAS schedule submitted for the contribution month, exactly as it left the firm. Second, the bank-payment evidence: the payment confirmation from the firm's bank, the bank-statement line that carries the debit, and the matched remittance reference quoted on both. Third, the underlying weekly payslip dataset — the structured per-worker per-week rows with the CWPS Pension and CWPS Sick Pay lines broken out as separate columns, and where the contribution month crossed an SEO boundary, the per-week rate evidence that shows which baseline was used for which contribution week. The schedule footer total has to equal the GL movement has to equal the bank payment, and every line on the schedule has to trace to a row in the dataset and onward to the source weekly payslip PDF.

The practical consequence is that the firm that retains the structured per-worker per-week dataset alongside the schedule and the bank-payment evidence closes audit queries faster than the firm that retains only the schedule and the underlying PDFs. With the dataset, every line on the schedule traces in seconds to the rows it was aggregated from, and every row traces to its source payslip. Without it, the same audit query becomes a manual rebuild of the dataset under time pressure, and the schedule's defensibility depends on whoever does the rebuild reconstructing the same numbers a second time.