Four-eyes review in Italian payroll: what it catches

Payroll errors rarely come from bad intent. They come from a wrong input, a stale rate or a rule applied to the wrong person. A maker-checker control is built for exactly this. The person who prepares the gross-to-net is not the person who approves it.

This article explains what that control looks like in Italian payroll and what it tends to catch. It is written for partnership, operations and payroll managers at global EOR and payroll platforms who rely on a local provider.

What maker-checker means here  

The maker prepares the payroll run. They load the inputs, apply the contract rules and produce the gross-to-net for each employee.

The checker reviews the result before it is released. The checker must be a different person, with their own login and their own sign-off. The system should block approval by the same user who prepared the run.

This is often called four-eyes review. The name is simple. The discipline behind it is not. A checker who only looks at totals is not a control. The review has to test the logic.

Why Italian gross-to-net needs it  

Italian payroll has many moving parts. The national collective agreement sets minimum pay, job levels and additional payments. Social contributions depend on the employer’s classification and on the employee’s situation. Income tax withholding depends on personal data, deductions and local surcharges. Year-end settlements and deferred pay items add more rules.

Each part is manageable alone. The risk sits in how they combine. A small input error can pass through several steps and reach the payslip looking plausible.

What a good checker catches  

Wrong collective agreement or level. A new hire is mapped to the wrong agreement or job level. Minimum pay and extra payments then follow the wrong table. The net looks reasonable, so only a review against the contract exposes it.

Stale rates and tables. Contribution rates and tax parameters change. A run that reuses last period’s table produces a clean but incorrect result. The checker compares the table version used with the current one.

Input mistakes. A misplaced decimal in a bonus. A start date entered in the wrong month. Overtime loaded twice. These are the most common errors. A checker who sees the variance against the previous period spots them quickly.

Missing or duplicated items. An employee is left out of a run. Another is paid twice. A leaver still appears after the final payment. Headcount reconciliation against the HR record catches these.

Tax situation errors. Family deductions or other personal data are not updated. The withholding is then wrong in a way that only appears later, at year-end adjustment. Reviewing changes in personal data alongside the run helps.

Treatment of special items. Benefits in kind, expense reimbursements and relocation payments follow different rules from regular pay. The checker confirms each item is classified correctly and taxed as intended.

What the control does not do  

Four-eyes review does not fix bad source data. If the HR record is wrong, both people may approve a wrong result. The control also fails when the checker is rushed or rubber-stamps the work.

Three practices keep it honest.

• Give the checker a defined checklist, not a general instruction to review.
• Show variances against the previous period, line by line, so changes stand out.
• Record who prepared, who approved and when, and keep that log.

What it means for your platform  

You carry the client relationship. When an Italian payslip is wrong, your client does not blame the local provider. They blame you.

So ask your provider concrete questions.

• Is the checker always a different person from the maker?
• Does the system enforce this, or is it only policy?
• What is on the checker’s list?
• How are rate and table updates verified before they go live?
• Can you see the approval log for a given run?

Good answers are specific. Vague answers about experienced staff are not evidence of a control.

It also helps to agree on the data you exchange. Clean, structured inputs reduce the errors the checker has to find. They also make the review faster, because variances are easier to explain when the data arrives in a consistent format.

Summary  

Maker-checker review is a basic control that works when it is enforced and tested against real logic. It catches mapping errors, stale tables, input slips and omissions before they reach an employee. It does not replace good source data.

Partnership teams can request the data-exchange specification from us.