What RCA, RSA and RPA really do in reconciliation
RCA, RSA and RPA are the employee-level reports that explain the “story” behind your monthly ZUS settlement (DRA). Payroll teams reconcile by making sure: RCA shows the correct contribution bases and amounts for each insured person; RSA captures absences and benefits that interrupt or change contributions; and RPA provides extra information ZUS needs in special cases, such as income paid after employment ends or periods qualifying for bridging pensions.
In a small company, reconciliation is about consistency between events, earnings and contributions. Every change in status or pay should be visible in at least one of these reports. If the totals in RCA do not align with DRA, or if RSA hasn’t recorded a sick leave that reduced the base, ZUS will flag discrepancies. The good news: a structured month-end check can catch these issues before submission.
The three reports in practice: what goes where
RCA is the backbone: it lists each person with social insurance, their insurance title code, the monthly contribution bases and the calculated pension, disability, sickness, accident and health contributions. If someone is insured only for health (certain civil contracts), they usually aren’t in RCA; however, verify your contract and insurance setup before excluding anyone. Use consistent title codes so ZUS reads the person’s coverage correctly.
RSA records events that change contribution rules: sick leave, maternity/parental leave, unpaid leave, care leave, and periods receiving ZUS benefits. You report the type of event, start/end dates and—where applicable—the benefit base. RPA is an informational report used in defined cases to give ZUS additional data such as income paid after termination or periods of work in special conditions for pension purposes. Check current ZUS guidance for when RPA is mandatory in your scenario.
A month-end reconciliation workflow that actually works
Step 1: lock payroll inputs (timesheets, absences, contract changes). Step 2: calculate gross-to-net and contribution bases, including any ZUS-funded benefits. Step 3: produce draft RCA/RSA (and RPA if triggered). Step 4: verify that the sum of individual RCA matches the totals intended for DRA. Step 5: cross-check RSA events with HR records. Step 6: run Płatnik/ePłatnik validations. Step 7: submit via PUE ZUS and obtain acknowledgment. Step 8: pay ZUS by the statutory due date.
Example: your graphic designer had five sick days; RSA should show the absence period with the correct code, and RCA should reflect reduced bases consistent with that absence. A sales manager left in March and received a bonus in April after termination; there may be no RCA in April for that person, so RPA can be required to inform ZUS about that post-termination income. Keep a short case note for each exception and attach it to the payroll file.
Data to map and cross-check before you submit
Map master data first: PESEL/NIP, address, insurance title codes, disability status, and contract type. Then map remuneration components to insurance rules: which elements build social and health bases, which are excluded, and how absences affect those bases. If someone has multiple contracts with you, decide whether they aggregate for insurance and reflect that consistently across RCA and RSA. Maintain a simple matrix so everyone on the payroll team calculates the same way.
Cross-checks that catch most errors: compare HR absence calendar to RSA lines (every recorded leave should exist in RSA if it affects insurance). Ensure RCA base totals equal what you plan to declare on DRA. If the annual pension/disability cap becomes relevant, document when it was reached and adjust bases thereafter according to current rules. Use Płatnik/ePłatnik control reports, and don’t ignore soft warnings—many hint at later rejections or ZUS inquiries.
Frequent mistakes that create ZUS mismatches
Wrong insurance title codes are common, especially for mandate contracts that change coverage mid-year. Another trap is failing to add an RSA line for unpaid leave or care leave, so RCA still shows a full base when it should not. Mis-typing PESEL or surname causes person-level rejections. Post-termination payouts are often left only in accounting; if they are relevant to ZUS records, they may require an RPA—check the current instruction before paying.
Benefits vs. pay mix-ups also drive errors. Employer-paid sick pay and ZUS-funded benefits are treated differently for contributions; if you don’t split them correctly, RCA won’t match the expected bases. Foreign employees without PESELs need correct identifiers and insurance eligibility set up from day one. Finally, corrections (korekty) must adjust both the individual report and the summary declaration; changing RCA without updating DRA will not reconcile at ZUS.
A lean checklist for small teams
Before calculation: confirm active contracts and insurance titles; lock absence data; review any terminations and planned payouts after termination; note employees in special work conditions if applicable. During calculation: apply component-to-insurance mapping; split employer-paid vs. ZUS-funded benefits correctly; track any progression toward annual caps and document the month of impact; preview RCA/RSA/RPA drafts and investigate every system warning.
Before submission: ensure RCA totals equal DRA; ensure each RSA event matches HR records; prepare RPA for any after-termination income or other cases required by current ZUS rules; validate identifiers; export, sign and submit via PUE ZUS; save acknowledgments. After submission: schedule the ZUS payment; reconcile the bank payment to DRA totals; archive reports and case notes; if ZUS returns a query or you spot an error, prepare a korekta covering the affected periods and reports.
Edge cases worth a second look
Multiple concurrent contracts with the same person can alter which contract is the basis for social vs. health insurance. Align this in RCA with the correct title codes, and ensure RSA reflects any parallel absences. Workers performing tasks that may count toward bridging pensions require accurate period tracking; if such periods exist, RPA can carry those details to ZUS for pension purposes—seek current guidance or professional advice for classification.
Terminations often create reporting nuance: payouts of unused leave or deferred bonuses after the insurance title has ended may not belong in a standard RCA for the payout month. Depending on circumstances, RPA may be required so ZUS can attribute the income correctly in the person’s record. Document the timeline—last insured day, payout dates, and what was included in the last RCA—and retain this with your payroll archive.
What to do next: controls, updates and where to verify
Set a recurring calendar: close inputs two business days before payroll, reconcile draft RCA/RSA the next day, submit and pay on schedule. Keep a change log for each month—who validated which control and when. Provide quick-reference notes on absence codes and insurance titles your team actually uses. For unusual cases, add a brief memo so future corrections don’t rely on memory.
Rules and interpretations can change. Verify specifics on the Social Insurance Institution (ZUS) website and through official finance channels before implementing edge-case handling or preparing RPA. If you want a partner to help set up the controls and maintain submissions, Auranik’s 1 Point Business Service Package (/poland/consulting/business-services) can coordinate the workflow with your HR and accounting tools. When in doubt, obtain tailored professional advice for your company’s situation.
Community content reflects individual experiences and should not be treated as legal, immigration, financial or government advice.
Know someone who may find this guide useful?