A payroll acceptance workbook with failures worth finding

Test what could change somebody’s pay

A login and a green connection indicator are not acceptance evidence. Start with a test identity and approved fictional inputs, then ask whether the destination has the right person, value, period and version. The six cases below form a small acceptance suite for the workflow described on this site.

The observations are illustrative examples of a test record, not results from a live provider account. Replace them with your own evidence. Agree a safe test environment or supervised test method with the provider before creating records; a workbook does not itself send instructions to payroll.

Cases 1 and 2: identity and effective date

T01 uses an unknown employee ID LT-999. Expected: no payroll instruction is assigned to another person; the unmatched record is returned for resolution. Illustrative observed: receiver creates a new person from the name. Decision: fail; disable name-based fallback and rerun. Correcting the name in the spreadsheet is not the repair.

T02 uses SAL-017-202611 version 2, entered in October and effective 1 November: October base 3,000; November base 3,200. Expected: those two periods retain their respective values. Illustrative observed: both periods show 3,200. Decision: fail; correct period handling and rerun October as well as November. A correct November screenshot alone would miss the regression.

Case 3: the missing policy

T03 removes the test leave-policy assignment before sending LR-017-11. Expected: the missing mapping is visible and no absence is treated as successfully delivered. Illustrative observed: source request remains, destination record absent, error captured. Decision: the negative case passes, but the workflow is not ready until mapping is restored and the valid request appears once. For Personio this targets the documented missing-policy boundary.

Sources: teamed.global

Cases 4 to 6: duplicates, approval and returned data

T04 sends the same approved event twice through the agreed test method. Expected: one active payroll instruction. Illustrative observed: two entries appear. Decision: fail; agree duplicate handling, remove the duplicate through the supported procedure and rerun. Neither an HTTP success nor a completed upload proves payment safety.

T05 changes approved version 2 to version 3 without fresh approval. Expected: the changed instruction cannot proceed as version 2. Illustrative observed: the operator’s pre-release check stops it. Decision: pass for that manual control; do not describe it as automatic enforcement.

T06 compares approved inputs with the returned test payroll. Expected: base 3,200, award 250 and reimbursement 80 remain separately identifiable, with treatment and resulting amounts explained by payroll. Illustrative observed: the 80 reimbursement is missing. Decision: fail; locate whether input, mapping or calculation omitted it and rerun the affected case.

After T03: prove that support closes the right problem

A restored leave record can pass the integration test while an employee’s payslip question remains unanswered. Add a service check to T03 without treating it as another automated test. In your agreed demonstration, present LR-017-11 and a disputed pay line separately. Record the technical result against the leave request and the payroll explanation against the actual pay period.

Use three evidence levels. Published responsibility tells you which work the provider says it handles. Accepted scope identifies the work and handoffs included for your account. Performed evidence shows what happened in this demonstration or incident. Keep those labels in the result: a source page is not a signed service commitment, and a well-written plan is not a completed correction.

The closure entry should read “absence present once; pay line explained; correction required or not; evidence reference; employee informed; remaining owner”, with actual answers supplied during the demonstration. Where the absence is repaired but the pay question is open, record two statuses rather than one overall pass. The provider comparison uses this same example so the purchasing decision and the acceptance test assess the same work.

Sources: lithuania-payroll-workflow.vercel.app

Make the first-cycle reconciliation a bridge

For every person, start with the last accepted input version, list current changes, and compare each item with the returned payroll. Keep differences explained individually. A net-pay total is not enough: tax or other deductions can change the total while the base-salary instruction is correct, and two errors can offset each other.

Release only after pay-affecting failures are resolved and the authorised payroll owner has accepted the result. Record any non-pay defect separately with a workaround and owner. Repeat the relevant cases when a policy, working pattern, integration mapping or provider workflow changes. Keep a previously passing control case alongside the repaired case so that the fix does not quietly break something else.