Reconcile CWPS Deductions from Irish Construction Payslips

To reconcile CWPS deductions from Irish construction payslips, treat each payslip as a row that has to carry the deduction broken into its working parts. For every pay period, capture the employee CWPS Pension, Death-in-Service and Sick Pay components as separate columns; capture ER CWPS as the same three components, again in separate columns; capture ER PRSI as its own column; and carry PAYE, USC, PRSI EE, gross and net alongside for the per-period tie-out.

The CWPS deduction line on the slip is not a single number. The employee Pension and Death-in-Service portions come off gross pay before PAYE is calculated. The Sick Pay portion (and the Health Trust portion where it appears) is a net deduction taken after PAYE. That asymmetry is what governs whether a recomputed figure ties to the gross-pay column or the net-pay column, and it is the single most common point of failure when the figures are rebuilt from PDFs by hand.

Any reconciliation that crosses 4 August 2025 has to apply two rate sets. The SEO-aligned weekly contribution rates changed on that date, so periods on or after 4 August 2025 reconcile against the new rates and earlier periods reconcile against the previous ones. A spreadsheet that applies a single rate set across the whole period will tie out cleanly on one side of the date and drift uniformly on the other.

Why you are reconciling from the payslip PDFs in the first place

The payroll system is normally the source of truth, and where it is, this work happens inside the payroll product. The job in front of you here is the case where the payroll system is not available as the source. A few patterns repeat:

• A migration to a new payroll product, with the old system retired or read-only, and historic figures that have to land in the new system as openings or comparatives.
• An outsourced bookkeeper or small-firm accountant inheriting a client whose payroll provider has changed, with no clean export available from the previous run.
• A finance team reconciling CWPS scheme returns where the payroll export is gone, corrupted, or simply will not tie out against what was submitted to the scheme.
• Project- or site-level labour-cost review against historic spend by SEO occupational category, where the only consistent record per pay period is the payslip itself.

In every one of those scenarios, the payslip PDF is the artefact that survives. It was produced once and signed off, it sits in the file share or the archive folder, and it carries the figures the scheme and Revenue saw at the time. The reconstruction job is to turn a stack of those PDFs back into structured data faithful to what the payroll run produced — not to re-run payroll, and not to re-derive anything that was not already on the slip.

This is a different job from reading a payslip as the employee whose name is on it. Employee-side reading is single-document, line-by-line, and asks "what is this deduction and why is it this size for me this month". The reconstruction job is many-document, column-by-column, and asks "what does this dataset have to look like so that it ties out per period, rolls up per employee and per CWPS week, and matches scheme returns at the member level". If you do need the line-by-line read of an Irish payslip itself before you can reconstruct it across a batch, our companion piece on reading the deduction lines on an Irish payslip covers that ground.

The angle this article fills is the gap between what the search results actually offer and what the working accountant needs. Payroll-vendor documentation is detailed but reversed: it tells you how to configure a CWPS deduction inside the product so that data flows in and a payslip comes out. The official CWPS pages tell you what the deduction is, what the rates are, and what the scheme expects from employers. Neither tells you how to take the figures back out of a finished payslip when the payroll system is no longer the source. That reverse direction is the work this article describes.

---

What to capture from each payslip, in priority order

The reconciliation only stands up if the column structure is right before any figures go into it. The list below is the working specification — what a careful reviewer would write down before opening the PDFs. Each group exists for a specific reason; nothing is on the list as decoration.

Employee CWPS components — each as its own column

• Employee CWPS Pension
• Employee CWPS Death-in-Service
• Employee CWPS Sick Pay (and the Health Trust component where the slip carries it)

Never collapse these into a single "Employee CWPS" total. The pre-tax versus post-tax treatment differs across them — the Pension and Death-in-Service portions reduce gross pay before PAYE, the Sick Pay (and Health Trust) portion is a net deduction after PAYE — and a single combined column makes the per-period tie-out impossible.

Employer CWPS components — each as its own column

• ER CWPS Pension
• ER CWPS Death-in-Service
• ER CWPS Sick Pay

Again, never a single "ER CWPS" lump. The employee-versus-employer split differs by component (the Sick Pay portion is heavily employer-weighted, the Pension portion less so), so a total ER CWPS reconciled against any single rate produces close-but-wrong figures every time. Extracting ER CWPS components from construction payslips as separate columns is what makes per-component employer-cost reconstruction defensible.

Other employer-side cost

• ER PRSI as its own column

ER PRSI is not a CWPS field, but it belongs on the same row. Employer-side labour-cost reconstruction needs ER PRSI alongside ER CWPS for any per-period or per-project total to mean anything, and rebuilding it later from a separate file is more work than capturing it once.

Statutory employee deductions for tie-out

• PAYE
• USC
• PRSI EE
• PRSI class

The PAYE, USC and PRSI EE figures are what the per-period tie-out is built against. PRSI class belongs alongside them because the class affects the PRSI rate and therefore what a recomputed PRSI EE figure should be when one is missing.

Earnings and totals for tie-out

• Gross
• Net
• Tax basis (cumulative, week 1, or month 1)

Tax basis is the field most often dropped in a manual rebuild and the one most likely to make a recomputed PAYE figure look wrong when it is not.

Construction-specific cues

• SEO occupational category
• Hourly rate or rate band
• Non-pensionable components flagged distinctly: overtime premium portion, travel allowance, subsistence
• CWPS scheme or membership reference number when shown

These are not optional metadata. The SEO occupational category drives the hourly rate band and therefore the contractual hours figure that the pensionable base is built from. The non-pensionable components have to be flagged because, on the slip, they sit alongside pensionable earnings — once they are aggregated into a "gross" column without that distinction, anyone re-deriving the pensionable base will fold them in by mistake. The CWPS scheme or membership reference is what lets the row match back to a CWPS member return later; without it, the reconciliation can complete arithmetically and still fail the audit it was built to support.

Period anchors

• Pay period start
• Pay period end
• CWPS calendar week

The CWPS calendar week is what makes the rate-transition logic auditable per row, because CWPS rates apply per calendar week rather than per Revenue tax week. Capture it as a separate column even when it can be derived from the period dates.

The reason every column is on the list is that the per-period tie-out depends on all of them: gross, minus the pre-tax CWPS components (Employee Pension and Death-in-Service), minus PAYE, minus USC, minus PRSI EE, minus the post-tax CWPS components (Employee Sick Pay and Health Trust where applicable), should equal net. If any of those columns is missing or merged into another, the residual loses its diagnostic value.

The construction overlay above is what distinguishes this list from a generic Irish payslip extraction. If you are working with non-construction Irish payslips and want the broader sector-agnostic field model rather than the CWPS reconciliation specifically, our piece on extracting Irish payslip data into Excel covers that case.

The pre-tax versus post-tax split inside the CWPS deduction line

The CWPS deduction line on a construction payslip looks like one number; arithmetically, it behaves like two. The employee Pension and Death-in-Service portions reduce gross pay before PAYE is calculated — they sit on the same side of the slip as the pension-relief mechanism, and they take their PAYE relief at the marginal rate by lowering the figure that PAYE is applied to. The Sick Pay portion (and the Health Trust portion where the slip carries it) is a net deduction taken after PAYE — it comes off the take-home figure once tax has already been calculated, like a post-tax voluntary deduction would.

That asymmetry is the rule that makes the rest of the reconciliation arithmetic work. Knowing it is the difference between a recomputed figure that ties out and one that drifts in a way no one can explain.

Reconstructing a missing field from the slip is where the asymmetry shows up. If the slip carries gross but the taxable-pay figure is gone, taxable pay is gross minus the employee Pension amount minus the employee Death-in-Service amount — not minus the full CWPS deduction. Subtracting the whole CWPS line will under-state taxable pay and, with it, every figure derived from taxable pay further down the slip. If the slip carries net but PAYE is missing or smudged, the reconstruction has to add the post-tax CWPS portion back to net before any PAYE arithmetic lines up, because PAYE on the original slip was applied to a figure that did not yet have Sick Pay (or Health Trust) deducted from it.

Pre-2010 reconciliations carry one extra wrinkle worth flagging for migration work. PRSI relief on the employee Pension and Death-in-Service portion was removed from January 2010 — payslips dated before that point reduced PRSI-able pay using the pension-relieved figure, payslips from January 2010 onward use the full gross figure for PRSI. The taxable-pay mechanics did not change, only the PRSI side.

Checking the Pension and Death-in-Service portions on the payslip, then, is not a question of whether the figure looks plausible against the contribution rate. It is a question of whether the figure ties to the gross-pay-before-PAYE column on the slip — meaning the value used as the PAYE base equals gross minus those two components. Checking the Sick Pay portion is the symmetric question on the other side of PAYE: it should reconcile against the take-home figure, taken off net rather than off the PAYE base. If both ties hold for a given period, the CWPS line on that payslip is internally consistent. If either drifts, the residual tells you which side of the deduction the problem sits on.

---

The 4 August 2025 SEO-aligned rate transition

Effective 4 August 2025, the standard CWPS weekly contribution is split into a Pension component of €53.14 (€21.27 employee, €31.87 employer), Death-in-Service of €2.34 (€1.17 each side) and Sick Pay of €3.00 (€0.63 employee, €2.37 employer); the employee Pension and Death-in-Service amounts are deducted from gross pay before PAYE is calculated. Those figures and the pre-tax treatment behind them come from the official CWPS weekly contribution rates effective 4 August 2025 published by the scheme.

The operational consequence for any reconciliation that crosses 4 August 2025 is that two rate sets apply, not one. Pay periods on or after that date reconcile against the new rates above; pay periods before it reconcile against the previous rate set. Apply a single rate set across the whole spreadsheet and the rows will tie out cleanly on one side of the date and produce a uniform offset on the other.

The case worth thinking through before it bites you is a single weekly pay period that straddles the transition itself. Where this happens — for example, a pay week that starts in the last days of July 2025 and ends in early August 2025 — the rate that applies is the rate for the CWPS calendar week the period sits in, not the calendar month the payslip was issued in. The CWPS calendar-week column on each row is what makes that decision auditable per period, because anyone reviewing the reconciliation can see at a glance which CWPS week the row maps to and therefore which rate set should have been applied.

That is also the cleanest signal that capturing the CWPS calendar week as its own column — rather than deriving it on the fly from the period dates — earns its place. A row that carries the week explicitly can be filtered, sorted, and rate-joined per period; a spreadsheet that derives the week inside a formula loses that auditability the moment the formula breaks or someone re-sorts the data.

---

Construction-specific cues that change the calculation

A construction payslip is not a generic Irish payslip with a CWPS line bolted on. Several fields show up that change either the pensionable base or the way the row reconciles back to scheme returns, and each one needs to be captured deliberately.

SEO occupational category. The Sectoral Employment Order (Construction Sector) 2023 sets minimum hourly rates by occupational category — the category, in effect, decides which weekly base the contractual hours sit against, which then decides what the pensionable earnings figure is for the period. Capture the category as its own column on every row. It is what lets per-category labour-cost rollups stand up later, and it is what makes any SEO-compliance reporting possible from the same dataset without re-keying anything.

Hourly rate banding and non-pensionable components. The pensionable base for CWPS is built from contractual hours at the standard hourly rate. What sits outside that base is what causes most of the trouble — the overtime premium portion (the uplift above the standard rate, not the hours themselves), travel allowance, and subsistence are typically not pensionable. They appear as separate lines on the slip, and they need to stay separate in the spreadsheet. Once they are folded into a single "gross" figure without the distinction, anyone re-deriving the pensionable base will pull them in by accident, the recomputed contribution figure will overshoot the slip, and the reconciliation will drift in proportion to how overtime-heavy the period was.

CWPS scheme or membership reference number. Where the slip carries the scheme or membership reference, capture it on every row. This is the field that lets the reconciliation match back to a CWPS member return at the individual employee level — not at the employer-aggregate level. A row missing the reference is a row that cannot be tied to a scheme submission without going back to the source PDF, which means the reconciliation can complete arithmetically and still fail an audit. It is one of the cheapest things to capture and one of the most expensive to omit.

Employee versus subcontractor. CWPS applies to construction-sector employees on payroll. A worker engaged as a subcontractor is paid under the Relevant Contracts Tax (RCT) regime instead and will not have a CWPS deduction at all. This matters at the column-design stage because what looks at first glance like a "payslip" for a subcontractor is more likely an RCT-regime payment record — different headings, different deductions, no CWPS line, no scheme reference. Forcing a CWPS column structure onto data that does not belong in it produces empty columns and a misleading reconciliation. If the records you are reconstructing turn out to be subcontractor-side rather than employee-side, Ireland's RCT subcontractor invoicing rules are the relevant reference for what those documents actually contain and how they reconcile.

---

Where reconciliations from payslips typically break

A CWPS contribution audit from payslip PDFs almost always fails in one of a small number of patterns. Each pattern has a recognisable symptom, a specific test, and a fix that goes back into the spreadsheet design rather than into the figures themselves. Run the list against your dataset before assuming an individual row is wrong.

Non-pensionable overtime or allowances rolled into the pensionable base. Symptom: the recomputed CWPS Pension figure consistently overshoots the figure on the slip, and the size of the overshoot tracks how overtime-heavy the period was. Test: filter the dataset to overtime-free weeks and check whether those rows reconcile cleanly while overtime-heavy weeks drift. If they do, the pensionable base is being inflated by overtime premium, travel allowance, or subsistence that should have been flagged separately. Fix: the overtime premium portion, travel allowance, and subsistence go in their own columns from the start, and the pensionable base is computed without them.

Weekly versus monthly base mismatched against the SEO weekly figure. Symptom: monthly-paid employees drift uniformly against the slips while weekly-paid employees on the same site reconcile cleanly. Test: take a monthly period and check whether the per-period CWPS amount equals a single weekly rate divided by twelve, or equals the weekly rate multiplied by the number of CWPS calendar weeks the period covers. The first will produce the drift; the second will tie out. Fix: derive every per-period figure from the CWPS calendar weeks the period actually contains, never from a flat monthly conversion.

Employer contribution reconciled against the wrong rate component. Symptom: total ER CWPS reconciles to roughly the right number but never exactly, and the residual moves around as the relative weight of Pension, Death-in-Service, and Sick Pay shifts week to week. Test: split the ER CWPS total on a sample row into its three components and reconcile each against its own rate; if each component ties when the total does not, the issue is the per-component employer-versus-employee ratios — Pension, Death-in-Service, and Sick Pay carry different splits, so a single combined rate cannot reproduce the slip. Fix: the per-component ER CWPS columns from the field-capture section. Reconcile each component against its own rate, then sum.

Missing CWPS scheme or membership reference. Symptom: nothing. The per-period figures all tie out, the per-employee rollup looks clean, and the reconciliation appears finished — and then the rows cannot be matched to the scheme submission at the member level. Test: count how many rows in the dataset are missing the scheme or membership reference. If any are, those rows have to be re-matched manually against the source PDFs. Fix: capture the reference on every row at the field-capture stage, before the rest of the reconciliation runs. Surface this breakpoint separately because, unlike the others, the per-period numbers will not flag it.

Periods crossing 4 August 2025 with a single rate set applied. Symptom: rows on one side of 4 August 2025 reconcile cleanly and rows on the other side carry a uniform offset that is the same size for every employee on every site. Test: split the dataset by pay period start, run the reconciliation for each side separately, and check whether each half ties out on its own. If the pre-4-August half reconciles and the post-4-August half drifts (or vice versa), a single rate set is being applied across the transition. Fix: rate-join per row using the CWPS calendar week, as covered in the rate-transition section above.

Spreadsheet structure: rows, rollups, and the tie-out column

The Irish construction payslip reconciliation spreadsheet has three structural decisions that decide whether everything above holds together: what a row represents, what dimensions it rolls up against, and where the tie-out lives. Get those three right and the rest of the design follows.

Row grain. One row per pay period per employee, keyed on the composite (employee identifier, pay period start, pay period end, CWPS calendar week). Every other column on the row attaches to that key. A single payslip — weekly, fortnightly, four-weekly, or monthly — becomes a single row, regardless of pay frequency, and the period dates plus the CWPS calendar week disambiguate which scheme period the row belongs to. The composite key is what stops two rows for the same employee colliding when a re-run, an adjustment, or a back-dated correction lands in the dataset.

Rollup dimensions. The row design has to support three rollups from the same dataset, because each one answers a different question:

• Per employee — used for member-level scheme reconciliation. This is what ties a year's worth of CWPS contributions for one named person back to what was submitted for that person to the scheme.
• Per CWPS calendar week — used for weekly scheme submissions and for handling the rate transition cleanly. Aggregating to the CWPS week is what lets the pre- and post-4-August-2025 rate sets be applied in the same spreadsheet without the two halves contaminating each other.
• Per SEO occupational category — used for labour-cost reporting and for SEO-compliance review. This is the rollup that answers "what did this category of worker cost the project this month, and were the rates compliant".

A spreadsheet designed for one rollup but not the others usually has to be rebuilt when the second question is asked. Designing the rows so all three rollups work from the same dataset costs nothing extra at row-design time and is the difference between a working file and a one-shot output.

Tie-out column. On every row, the tie-out is:

gross − (Employee Pension + Employee Death-in-Service) − PAYE − USC − PRSI EE − (Employee Sick Pay + Health Trust where applicable) = net

A non-zero residual is the immediate signal that one of the captured fields on that row is wrong. Because each component is in its own column rather than buried in a combined deduction, the residual also tells the reviewer where to look — a residual that matches the magnitude of the Sick Pay portion points at the post-tax side, a residual that scales with the Pension figure points at the pre-tax side. Without the per-component columns, the residual is just a number and the reviewer has to open the PDF to find out why.

ER CWPS components and ER PRSI sit on the same row but do not enter the employee tie-out — they have no role in deriving net. They live alongside the employee columns so that per-period employer-cost rollups can be produced from the same dataset without rebuilding the join, which is what lets the per-CWPS-week and per-SEO-category aggregations carry employer-side cost as well as employee-side deductions.

---

Running this across a batch of payslips

The field-capture model and the spreadsheet structure are the difficult part. Once they are decided, applying them to a single payslip is a transcription exercise. Applying them across a folder of two hundred or two thousand payslips is where the manual rebuild stops being viable — every column has to be picked off the slip in the same way, every row has to carry the same composite key, and the source-file reference has to survive intact for any of it to be defensible later.

A workable approach is to run the extraction itself with a prompt that translates the field-capture list directly into the column structure. Concretely, that prompt asks for one row per pay period per employee, with every employee CWPS component as a separate column (Pension, Death-in-Service, Sick Pay, and Health Trust where present); every ER CWPS component as a separate column (Pension, Death-in-Service, Sick Pay); ER PRSI as its own column; PAYE, USC, PRSI EE, gross, net, tax basis, and PRSI class for the per-period tie-out; SEO occupational category and hourly rate or band; non-pensionable components (overtime premium portion, travel allowance, subsistence) flagged separately so they do not contaminate the pensionable base; the CWPS scheme or membership reference; and pay period start, pay period end, and CWPS calendar week. The prompt is the column structure — once it is right, the same prompt rebuilds ER PRSI and ER CWPS from payslips consistently across the whole batch instead of being re-invented per file.

The audit-trail piece is what keeps the dataset defensible. Every row in the output should carry a reference back to the source file and page it came from, so that any disputed figure can be checked against the original payslip in seconds rather than minutes. That reference is what lets a reviewer push back on a single number without re-opening the whole reconciliation, and it is what lets a year-end audit confirm the dataset against the underlying records without the auditor having to trust the spreadsheet on its own.

This is the role our own product plays in the workflow — AI extraction of payroll PDFs into structured data where the prompt above is the spreadsheet specification and the output is the dataset, with each row carrying its source file and page reference. The same prompt that handles ten payslips handles several thousand without rewriting, which is what turns the field-capture model from a per-file checklist into a batch operation. For the broader vendor-evaluation lens on what to look for in payroll OCR software, the sibling piece covers the category as a whole rather than the construction-CWPS workflow specifically.

What the workflow leaves on the reviewer's desk is the dataset the rest of this article has been describing: one row per pay period per employee, with the CWPS deduction broken into its pre-tax and post-tax components, ER PRSI sitting alongside the per-component ER CWPS columns, the tie-out column populated and pointing at any row whose figures do not balance, the SEO occupational category and CWPS calendar week attached to every row for the rollups, and a source file and page reference on each row for any figure that has to be checked back against the original.