Payroll and SOC 1: every pay run ends up in someone else's ledger.

A payroll provider does not own the numbers. The client decides who is employed and what they earn; the provider turns that into net pay, deductions, remittances and filings. The objectives in your report should follow that hand-off, stage by stage, so a reader can see where the client's responsibility ends and yours begins.

Which remittances and forms apply depends on the countries you pay in: income tax deducted at source, provident fund and state insurance contributions, social security, or annual employee tax statements. Name the ones in scope in the system description, not in general terms.

1. PAY.1
   Authorised client contactsA maintained list of who may submit changes for each client, refreshed when the client tells you.
2. PAY.2
   Input completeness checksHeadcount and gross pay compared with the prior run; variances above a threshold are explained before processing.
3. PAY.3
   Rate and table change managementStatutory rate updates and formula changes tested in a separate environment and approved by someone other than the builder.
4. PAY.4
   Pre-release reviewA preview register sent to the client, with processing held until client approval is received.
5. PAY.5
   Bank file integrityControl totals and record counts on the bank file agreed to the approved register; upload rights limited to a small group.
6. PAY.6
   Remittance trackingEach due remittance logged, paid, and matched to the deductions in the register for the same period.
7. PAY.7
   Access to payroll dataPeriodic review of who can change pay, bank details or tax settings, with leavers removed promptly.

General IT controls sit underneath all of these. If anyone can change the calculation engine without review, every calculation objective is weaker, so change management and logical access are usually written as supporting objectives of their own.

1. Check that the report covers the services the client uses and a period that overlaps the client's financial year.
2. Read the opinion and every exception in the tests of controls, and decide whether any touches payroll expense or liabilities.
3. Find the complementary user entity controls and test that the client actually performs them.
4. Look at subservice organizations you carved out, such as a hosting provider or a payments bank, and decide whether more evidence is needed.
5. Ask for a bridge letter if the period ends well before the client's year-end.

The client's auditor works under its own standard on service organizations, such as AU-C 402, or AS 2601 for audits of US public companies. Your report is evidence inside that work, not a substitute for it.

• Approving the register. The client reviews and approves the preview register before you release payment.
• Authorising changes at source. Hires, leavers, pay rises and bank detail changes are approved inside the client before they reach you.
• Reviewing exception reports. The client works through the variance and exception reports you send, and tells you what to correct.
• Keeping the contact list current. The client tells you when an authorised contact leaves or a new one is appointed.
• Reconciling to the ledger. The client agrees payroll journals and bank debits to its own general ledger.

These are written in the description as complementary user entity controls. If a client skips them, your controls can still pass while the client's payroll numbers are wrong, and the client's auditor will find that gap on their side.

• Manual overrides with no trail. An operator forces a net pay figure to fix an urgent complaint. If overrides are not logged and reviewed, the calculation objective has a hole the auditor can sample.
• Off-cycle runs outside the controls. Bonuses, corrections and final settlements run on a different path, without client approval or control totals. Auditors often pick these on purpose.
• Bank file edited after approval. A rejected payment is fixed by editing the file directly. Without a re-check against the register, the file no longer matches what the client approved.
• Rate tables updated late. A statutory change goes live a cycle late and nobody records why. That is both a calculation and a cut-off problem.
• Objectives promising what the client controls. Wording such as 'pay changes are authorised' claims something only the client can do. Write it as receiving changes from authorised contacts.

Sources: AICPA SSAE No. 18, AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting, as amended; AICPA Guide, SOC 1 Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting; AU-C section 402 and PCAOB AS 2601 as named. Stages, controls and the scenario are illustrative.