This is a quick tutorial on how to carry out an efficient Service Performance audit.
We have covered the background and theory elsewhere, and this is worthwhile, however, this is about tips and tricks to get the work done thoroughly but efficiently within Audit Assistant.
We will assume that you have decided that the client is using the correct reporting regime, that the Service Performance Information (SPI)* is within scope.
Step 1: Obtain the draft SPI from the client (should be part of the draft financial statements attached to the Control page).
- Read to familiarise yourself with the approach they have taken, and any obvious reporting issues or oversights that may be relevant.
- It will be useful to compare to prior year reporting to see what changes have been made to reporting style or to the items reported.
- It will also be useful to do a quick scan of the financial results and see if these are generally reflected in the service performance results.
- Any issues arising from this preliminary review should be recorded as comments, for follow up or to flag as a risk. A request to the client may also be raised at this point if something requires clarification.
Step 2: If you have not already done so create an engagement letter that includes appropriate mention of the audit of the SPI.
- There are standard paragraphs included in the AA supplied engagement letters that cover the requirements for audit of SPI.
- In Tier 3 and 4 templates, these paragraphs are toggled on or off depending on how a question early on the Control page asking whether the SPI is to be included or excluded from scope is answered.
- However, if needed (say you want to create your own engage not letter) there is an optional checklist called Service Performance - Engagement Letter Checklist (A section) that explicitly states what the standards require in an engagement letter with SPI.
Step 3: As part of the early information gathering from the client, share page the Service Performance - Items Required (A section).
- This optional page is designed for gathering information directly from the client that we will need to know later, which we will use on other pages.
- You could, to avoid duplication, wait until you get to these other pages and ask the client then either directly or by using the requests function (if the answer is not obvious).
- If you do use the page, you might want to remove questions that you know the answers for already (e.g. that there is no service performance information upon which another auditor has expressed an opinion) - if this is not applicable select 'customise' at the bottom right and hide this question and others that are not relevant prior to sharing.
- Once you get to the pages that ask for information you have gathered here, you could cross-reference back to the 'Items Required' page to save duplication.
Step 4: The page Service Performance - Planning (A section) is where the work really starts. This page should be completed in all cases.
- Answer clearly with a comment, attachment or yes/no response. N/a is not sufficient when the standard requires us to provide an answer.
- As noted above, you may like to use the requests feature to have the client answer directly into the file.
- Cross-references to other pages may be appropriate. Create a comment then use the cross-reference option at the bottom of the dialogue.
- There is a space at the bottom specifically asking for the identification of risks related to SPI.
- Risks may be flagged from any comment, however, if not already identified this is the place to flag risks relevant to SPI.
Step 5: Workpapers in the B section are designed to explore and document the control environment as it relates to SPI.
- The page Service Performance - Entity and Environment (B section) should be completed in all cases. However, it has optional sub-pages to be used if service organisations are used or experts help is required.
- Again some of these questions may have been asked if the Items Required page was used or can be gleaned directly from the client here.
- Internal controls as they relate to SPI are explored on the page Service Performance - Internal Controls. Relevant controls are identified documented and tested via walk-through tests.
- If we decide that we may want to rely on internal controls to reduce substantive testing there are sub-pages for this where we can load a sample of transactions and test the controls.
- Depending on what is being reported this may be essential, for instance, if historical attendance figures are being reported there is little chance of verifying these substantively (unless there are dependencies in the financial reports such as attendance fees), so testing of systems for recording these details will be necessary.
Step 6: Assess materiality as it relates to SPI. This should be completed in all cases.
- The page Service Performance - Materiality in (C section) is straightforward enough, and in many cases commonly expressed as "a variance of more than 5% will be considered material".
- Considering variance from the prior year or expected result may also be appropriate.
- However, it is important to note that where there is reporting of a qualitative nature further thought may be required.
- Each service performance matter being reported should be considered to see if it fits the materiality description, and one materiality descriptor may not fit all items being reported.
- Additional lines may be added for additional materiality descriptors.
Step 7: Analyse risk. Risks are grouped with other risks created throughout the file on the Risk Analysis page in the E section.
- SPI Items are likely to be flagged as risks during the work above because they are material, potentially understated, present the potential for bias and so on.
- Risks are gathered and analysed (if not already done so when they are created) on this Risk Analysis page.
- When analysed there is a 'send-to' option at the bottom of the dialogue. This should be used to allocate these to the K1 lead schedule where the actual testing is to take place.
Step 8: Carry out substantive testing on Service Performance - Detailed Testing (K section). This page should be completed in all cases.
- The first step is to decide how much reliance is being placed on controls, and substantive analytical review procedures.
- The page is framed in terms of outcomes and outputs, even though the standard does not use these specific terms - but we are used to them from Tier 3 and 4 PBE.
- In practice, it makes sense to test all outcomes as they are normally material and easy to map onto available information (a trust deed for instance).
- Outcomes are pasted into a testing table, and tests selected (e.g. "Agreed to founding documents").
- Each outcome is marked on the basis of passing or failing the tests.
- It may be that only material outputs are selected for testing, but in most cases, the client will only be reporting on material outputs so all will probably be considered.
- They are pasted or imported into the table and appropriate tests are applied (e.g. "Cutoff is accurate").
- Each output is marked on the basis of passing or failing the tests.
- As an option to using the testing style above, if say the information just doesn't fit the format, you could attach your own workpapers to this page, but there are questions here that are mandatory (e.g. under the headings 'Other testing:', 'Other information:' etc).
Step 9: Summarise and report on Service Performance - Reporting Considerations (Z section). This page should be completed in all cases.
- There are requirements to report to governance, to assess whether fair presentation is achieved, compliance with the applicable framework, and attainment of reasonable assurance.
- We also assess whether our audit report may need modification.
- Finally the optional page Service Performance - Audit Report Contents may be completed. If the correct AA audit report has been utilised this page will only be necessary to double-check that everything is included.
* I use the term Service Performance Information (SPI for short) rather than Statement of Service Performance(SSP) and Entity Information(EI) as per the Tier 3 and 4 frameworks because these terminologies are not used in the NZ-AS-1 or in PBR FRS 48 - the standard applicable to Tier 1 and 2 PBEs. Instead, the generic term Service Performance Information is used.