A shared services centre (SSC) runs processes such as payables, receivables, payroll or general ledger for several business units. Centralising work moves controls with it, so an audit needs to cover the centre's own controls, the handoffs with the business units, and whether the service agreement is working.
Last reviewed: 17 October 2026. Facts checked. This post describes audit method and does not rely on statute or a published standard. We did not open IIA or ICAI standards or any regulation for this post. Where the centre serves entities in other countries, local law on data transfer, tax and outsourcing needs separate advice, which we have not sourced. We checked our own existing posts to link only to pages that exist.
Why an SSC changes the audit
Before centralisation, each business unit had its own accounts team, its own controls and its own errors. After it, one team does the work for many. That brings strengths: standard process, specialist staff, easier monitoring. It also brings concentration: one error in a rule or template repeats across every unit, and one access weakness exposes all of them.
Three questions guide the audit:
- Does the centre perform its processes accurately, completely and on time?
- Do the business units and the centre agree on who is responsible for what?
- Are risks of concentration, such as access, key people and system change, controlled?
Scope the engagement
Start with a map of what the centre does. Typical processes are procure-to-pay, order-to-cash, record-to-report, hire-to-retire and treasury support. Our checklists for P2P, O2C, R2R and H2R provide process-level tests that apply inside the centre.
Then add the centre-specific areas below, which are what make this audit different from five separate process audits.
Centre-specific areas
1. The service agreement and service levels
- Is there a signed agreement or charter between the centre and each business unit?
- Does it say what the centre does, what the units provide (for example approved invoices, master data requests) and by when?
- Are service levels defined in measurable terms, such as turnaround time and error rates?
- Who reports on them, how often, and are the numbers checked independently?
Test the reported figures. A dashboard showing 99% on-time processing means little unless a sample of items agrees with it.
2. Handoffs between the units and the centre
Most errors in an SSC sit at the boundary. Typical failure points:
- Units sending incomplete or unapproved documents.
- Approvals given in email outside the workflow.
- Master data changes requested by one person and made by another with no confirmation.
- Queries bouncing between teams with no owner.
Trace several transactions end to end, from the unit's initiation to the centre's posting, and note every handoff.
3. Access and segregation of duties
Centres tend to give staff broad system access for flexibility. Test whether one person can create a vendor, approve an invoice and release payment. Review access by role, and check that leavers and role changers lose access promptly. For payroll or treasury work, review who can change bank details.
4. Master data
Central control of vendor, customer and employee master data is one of the main reasons for an SSC. Test the change process: request, validation, approval, update and periodic review. See vendor reconciliation and matching for related tests.
5. Standard rules and templates
If posting rules, tax codes or approval limits are wrong, the same error repeats. Select a sample of rules and test them against current policy and law, and check how changes are approved and communicated.
6. Automation and tools
Where the centre uses robotic process automation or workflow tools, audit the bots as users: who built them, who can change them, how exceptions are handled, what logs exist. A bot with a hard-coded password and no owner is a risk.
7. Third-party providers
Some centres are outsourced. Then the question moves to the provider: what assurance reports exist, which controls does the provider own, and which stay with the customer? For service organisation reports, see ISAE 3402 and SOC reports.
8. Continuity and people
Test business continuity: remote access, backup staff, cross-training. Check attrition and reliance on a few experienced staff. A centre that works only because three people know the exceptions is fragile.
Sample test steps
| Area | Test |
|---|---|
| Service levels | Re-perform the reported figure from source data for one month |
| Handoffs | Trace 25 transactions from unit to posting; record deviations |
| Access | Compare the access list to roles and to the leaver list |
| Master data | Select vendor changes and check request, approval and update |
| Rules | Compare a sample of posting and tax rules to policy |
| Bots | Review ownership, change log and exception queue |
The sample size is illustrative. Set sizes using your own methodology.
Reporting to the parent
A centre report should separate observations that the centre owns from those owned by units. If the centre blames the units and the units blame the centre, the report should name who owns the fix. The audit committee needs a single owner per issue.
Common mistakes
- Auditing the centre as a standalone team and ignoring the units.
- Accepting service-level reports without testing them.
- Missing the interface controls because they belong to nobody.
- Assuming a good control in one process holds in all.
Related Articles
Statutory facts on this page are checked against their sources, and the page says where it relied on secondary reporting. How we verify · Report an error