Ireland RCT Deduction Summary: Monthly ROS Filing Guide

It is the third week of the month. ROS is open on the Ireland RCT Deduction Summary screen, the pre-populated lines are already there, and a folder of subbie invoices and Deduction Authorisation PDFs from the period sits beside the keyboard. The 23rd is ahead.

Revenue pre-populates the Deduction Summary on ROS from the principal contractor's payment notifications during the period. Amendments must be made on ROS before the 23rd of the month after the period ends. If nothing is changed by that date, the pre-populated summary is deemed the principal's return for that period — that is the position Revenue's eRCT notifications guidance for principal contractors sets out, and it is the position the bookkeeper is working against on the screen.

The implication of that default matters more than the deadline itself. Doing nothing is not "no return for the period" — it is filing the pre-populated draft as it stands, line by line, with the principal's name on it. The monthly RCT return ROS deadline is the moment that draft becomes the return. Everything that follows in this article walks the work of getting that draft right before then: reconciling the pre-populated lines against the principal's own record of the period, amending or cancelling notifications where they do not match, handling the non-resident edge cases, and tying the period's RCT figure back to the GL before the next VAT3.

How the Pre-Populated Deduction Summary Is Built

The pre-populated lines on screen are not Revenue's record of what happened — they are Revenue's record of what was notified. Reading the chain of cause and effect that built the draft makes the rest of the reconciliation work obvious.

Before paying a subbie during the period, the principal files a Payment Notification on ROS. The notification specifies the subbie's tax reference and the gross payment about to be made. Revenue responds with a Deduction Authorisation specifying the rate to apply to that payment — 0%, 20%, or 35% — and the Authorisation lands in the principal's ROS inbox as a PDF. The principal pays the subbie net of the deduction, holds the RCT amount, and the Authorisation goes into the RCT file for that subbie. Through the period, this happens payment by payment, subbie by subbie. At period end, ROS pre-populates the Deduction Summary line items from the Deduction Authorisations that Revenue issued during the period.

What that mechanic means for the reconciliation: the pre-populated draft reflects every Payment Notification the principal filed and Revenue issued an Authorisation for. That is its entire scope. It does not reflect payments the principal made without filing a notification. It does not reflect notifications the principal should have cancelled because the work didn't issue. It does not reflect amount errors that were carried through from a wrong figure on the original notification. The draft is faithful to what was notified, not to what actually happened on the principal's side.

The gross figures on Payment Notifications themselves come from upstream, on the QS side of the firm. The values that flow into a Payment Notification are the certified figures from the QS-side Payment Claim Notice and Payment Schedule workflow under CCA 2013. In larger firms a separate QS team produces those certifications and the bookkeeper takes the figures as given; in smaller firms the same person runs both sides and any discrepancy upstream surfaces here.

One other moving part to note before walking the reconciliation: subcontractor rates can change mid-period when a Bulk Rate Review reassigns a subbie from 20% to 0% (after improved compliance history) or from 20% to 35% (after a compliance issue). Deduction Authorisations issued before the change carry the old rate; those issued after carry the new rate. The pre-populated Deduction Summary reflects this on a line-by-line basis, which is the correct behaviour — the rate at the time of notification is the rate Revenue authorised for that payment.

The Three-Way Reconciliation: Building a Single Source-of-Truth File

The Revenue eRCT period end review is, in practical terms, a three-way match. Three artefacts have to agree before the principal can confirm the return:

1. The principal's own log of Payment Notifications filed during the period. This lives in the firm's bookkeeping system, in a manual notification log, or in a hybrid of the two. It is what the principal believes happened in the period.
2. The Deduction Authorisation PDFs delivered to the ROS inbox during the period. One PDF per notification, each carrying the rate Revenue authorised. This is what Revenue confirmed back to the principal.
3. The pre-populated Deduction Summary line items now visible on ROS. This is Revenue's draft of the period return, built from the Authorisations in (2).

The reframing this article is built on: the pre-populated Deduction Summary is a draft to verify, not a faithful record. Treat it as Revenue's view of what should have happened given what was notified — not as an authoritative log of what actually did happen on the principal's side. The three-way match is the discipline that catches the gap.

Running that match by eye against a folder of PDFs and a screen of pre-populated lines is the failure mode. It is also, in honest terms, the reason the bookkeeper at 3pm on the 22nd reaches for the "fix it next month" decision. What the work actually requires is line-level detail from the period's subbie invoice PDFs and the corresponding Deduction Authorisation PDFs in one workable file — a structured spreadsheet with per-line gross, RCT rate, RCT amount, and net payable, that can be sorted by subbie, by date, by amount — sitting alongside the ROS screen so the bookkeeper compares row to row, not folder to screen.

Getting to that file fast is what changes the calculus. The product behind this article is the tool we built for that step: extract subcontractor invoices and Deduction Authorisation PDFs into a structured reconciliation spreadsheet by uploading the period's batch of PDFs and prompting for the columns the reconciliation needs. The interaction is a single prompt field with a file upload area — the same shape as a chat with ChatGPT or Claude — handling up to 6,000 files in one batch and individual PDFs up to 5,000 pages. Output is Excel (.xlsx), CSV, or JSON, with each row carrying a reference back to the source file and page so any line on the reconciliation can be traced to the specific Authorisation or invoice it came from. The product produces the reconciliation-ready data; ROS is where the return is filed. That is the whole division of labour.

One precondition worth naming. The cross-check between subbie invoice and Deduction Authorisation only works cleanly if the subbie invoices arriving from the period actually carry the RCT-required fields — the RCT rate applied, the gross, the amount of RCT deducted, the net payable. If invoices arriving from subbies are not in order, the upstream fix is intake-side: subbies need to be sending invoices that meet what an RCT-compliant subcontractor invoice must contain. That is a separate problem to solve at intake, not in the period-end reconciliation, but if it is the source of mismatches showing up here, fixing it once upstream removes a category of problem permanently.

Walking the Typical Mismatches

Four patterns cover the mismatches a bookkeeper will see when the reconciliation file sits alongside the pre-populated draft. Knowing them by name makes the work tractable inside the amendment window.

Mismatch 1: cancelled payments where the work didn't issue. A Payment Notification was filed earlier in the period and Revenue issued the Deduction Authorisation, but the payment never ran. The subbie didn't deliver, the contract was paused, an invoice was withdrawn after a dispute. The line shows up on the pre-populated draft as if a payment was made, because from Revenue's view the notification said one would be. The reconciliation file shows no corresponding subbie invoice or settlement. The action before the 23rd is to cancel the Payment Notification on ROS so the line drops from the draft.

Mismatch 2: missed Payment Notifications. A payment ran during the period but no Payment Notification was filed beforehand. The reconciliation file shows the payment and a subbie invoice; the pre-populated draft has nothing for that subbie on that date. This is not a clerical mismatch — it is a compliance defect. The obligation under the regime is to notify before paying, and the absence of a Deduction Authorisation when payment ran means the principal applied either the wrong rate or no deduction at all. The action is to add the notification on ROS now and accept the exposure: the principal carries the difference between whatever rate was actually applied to the payment and the rate Revenue would have authorised, plus any interest Revenue charges on the late notification.

Mismatch 3: amount corrections. The original Payment Notification was filed with the wrong gross, the wrong subbie tax reference, or a tax/net split that did not match the underlying invoice. The Deduction Authorisation was issued on that wrong basis, and the pre-populated line carries the wrong figure. The reconciliation file shows the correct gross from the subbie invoice and what was actually paid; the pre-populated line does not. The action is to amend the Payment Notification on ROS so the corrected gross flows through to the line.

Mismatch 4: subcontractor rate changes mid-period from Bulk Rate Reviews. A subbie's rate moved during the period — typically 20% to 0% on registration improvement, or 20% to 35% after a compliance issue. The check here is the opposite of the others: confirm each line carries the rate that was in force at the time the notification was filed, not the subbie's current rate. A line that looks wrong because the subbie is now on 0% but the line carries 20% is not a line to amend — it correctly records what Revenue authorised for that payment.

One adjacent compliance line is worth noting in passing: VAT reverse-charge applies to most Irish construction services between principal and subbie, and the subbie's invoice should carry the reverse-charge wording. That is a separate compliance check at invoice intake — see the reverse-charge wording required on Irish construction VAT invoices — and it does not flow through the RCT Deduction Summary. The two are separate returns; mismatches in VAT wording on subbie invoices do not surface here, but they need fixing at intake all the same.

Amending on ROS Before the 23rd, and the Silent-Acceptance Cliff

Each mismatch above maps to a specific path on ROS. Three actions cover almost everything the bookkeeper will need to do.

To amend an existing Payment Notification, open the notification on ROS and correct the gross, the subbie tax reference, or any other field that was wrong on the original. This is the path for amount corrections under Mismatch 3. Revenue re-issues the Deduction Authorisation against the corrected figures, and the pre-populated line on the Deduction Summary updates to match.

To add a Payment Notification for a payment that already ran without one, file the notification now using the actual payment date and gross. This is the path for missed notifications under Mismatch 2. The notification carries the late-filing flag implicitly — the payment date precedes today — and the principal accepts whatever consequence flows from notifying after the fact rather than before.

To cancel a Payment Notification for a payment that didn't issue, open the notification on ROS and cancel it. This is the path for Mismatch 1. The Deduction Authorisation is withdrawn and the line drops from the pre-populated Deduction Summary.

There is no path to correct a Deduction Summary line directly on the summary screen. Every correction is a correction to the underlying Payment Notification, and the summary line follows.

Now the operationally important fact none of the SERP leaders cleanly state. Line items can be amended on the Deduction Summary up to the 23rd of the month after the period ends. After that point, the return is deemed filed by silent acceptance, and line items can no longer be amended in ROS. Once the silent-acceptance moment passes, the only correction route is a submission via MyEnquiries with a €100 surcharge per period plus interest. The leaders mention the surcharge; what they tend to skip is the procedural lock — the ROS amendment paths above are gone the morning of the 24th.

The implication for the bookkeeper deciding between acting before the 23rd and "fixing it next month" is simple to state and important to absorb. "Fix it next month" is not a neutral choice. It is choosing the MyEnquiries path and the €100 surcharge for that period's correction. The decision before the 23rd is whether the time saved now is worth the surcharge plus interest later, on whatever lines remain unfixed. For most periods the answer is to act now; for a period with a single small mismatch the calculation is genuinely the bookkeeper's to make, but it should be a deliberate calculation, not a default.

A separate point applies even when the reconciliation throws up no mismatches at all. The 23rd-of-month deadline still bites. Silent acceptance operates the same way whether the draft was checked or ignored: by the morning of the 24th the principal has either actively confirmed the return or accepted the silent-acceptance default by inaction. Both are filing decisions, and the principal's exposure on a Revenue inspection rests on the same line items either way.

Non-Resident Subcontractors Inside the Period Return

Most Irish principal contractors engage non-resident subbies infrequently — a UK fitting-out specialist for one job, a Polish formwork crew for another. The handling inside the period return is straightforward once the canonical position is clear.

The 35% default rate applies to unregistered non-resident subcontractors. Where the pre-populated Deduction Summary shows a 35% line on a non-resident subbie, that is not by itself a mistake to amend down — it is the default rate the regime applies until the subbie registers with Revenue and is rate-reviewed. Amending the line down to 20% or 0% on the assumption that 35% is wrong, without registration evidence on file, is the error to avoid here.

Rate-change events for non-residents flow through the same Bulk Rate Review machinery that applies to resident subbies. A non-resident who registers and qualifies for a lower rate will see Deduction Authorisations issued after that point reflect the new rate; the rate-at-notification rule from Mismatch 4 applies the same way for non-residents as for residents.

The principal's RCT file for non-resident engagements should hold copies of the Deduction Authorisations issued during the period, the Payment Notifications filed, the contract documents, and any registration evidence (the subbie's tax reference confirmation from Revenue, the contract paperwork establishing the engagement). A Revenue inspection that queries a cross-border engagement will expect to see that pack assembled per subbie. Building it as the period closes, while the Authorisations and invoices for the period are already on the bookkeeper's desk, is materially less work than reconstructing it months later from email archives.

Closing the Loop to the RCT Control Account Before the Next VAT3

The work inside ROS is only half the bookkeeper's period-end task. The other half is making sure the period's RCT activity reconciles in the ledger before the next VAT3, because the principal's net cash position to Revenue blends both and drift between them drives ugly month-end variances.

The aggregate value on the period's Deduction Summary is the total RCT withheld from subbies during the period. That figure has three places it should agree with itself. It should match the credit movements on the supplier ledger — RCT withheld appears subbie by subbie as a credit reducing each subbie's payable balance. It should match the debit posted to the RCT control account in the GL — in Sage 50 the standard code is 748 Retained Tax Control, with equivalents in Surf Accounts, Big Red Cloud, BrightPay, and the other Irish-market systems under different account numbers. And it should match the cash position the principal owes Revenue when the next remittance falls due.

When all three agree, the reconciliation is clean. When they don't, the variance points at where the error lives. A control account higher than the Deduction Summary aggregate means RCT was posted to the GL that wasn't notified — the Mismatch 2 case in reverse, where the bookkeeping caught the deduction but the notification didn't. A supplier-ledger total below the control account means a subbie's RCT credit posted to the wrong account or to the wrong subbie. Each direction of variance tells the bookkeeper where to look.

The cash side closes the loop. The RCT withheld during the period is owed to Revenue, and on the next VAT3 cycle the principal's overall liability to Revenue blends VAT outputs, VAT inputs, and the RCT position. Finishing the RCT tie-out before posting the VAT3 prevents the two from drifting against each other — once VAT3 is filed on a foundation that doesn't agree with the RCT control account, unwinding the variance gets harder. The discipline is to tie out RCT first, post the period's RCT cash movement, and only then turn to the VAT3.

Worth noting in passing: the construction payroll side of the same firm runs a parallel month-end on the same calendar — see the parallel CWPS monthly remittance schedule for construction payroll for the workflow on that side.

The work the morning of the 24th is short. Confirm the period filed, log the Deduction Summary aggregate against the RCT control account, post the period's RCT cash movement, and turn to the next VAT3. Whether that filing reflects what actually happened during the period, or what Revenue inferred from the notifications it received, was decided the day before.