How should I accommodate an Audit workflow system?
If you already have a workflow set up to track Accounts Production services, then you may find yourself considering how best to modify this workflow so that it can also track those jobs that require a statutory audit.
Within Glide, there are several ways to accommodate the different processes involved here. We have briefly summarised each of those below. It is also possible to adopt more than one of these approaches in your system, for different cohorts of clients.
Which approach you prefer is likely to depend on some of the following factors:
- If the audit process is undertaken by the Accounts Production team and feels like an extension of their existing process, then you may find options 1 and 2 work well.
- If the audit process is undertaken by a separate team or department, then you may find options 3 or 4 work better. They both created two job holders, better reflecting the two teams.
- If you undertake 'pure' audits that have no link at all to Accounts Production, then you may wish to look at option 4. You could achieve this with a 'Pure audit' route on option 2, but you may find you have lots of stages on that sub-system that are only relevant to one route or the other. This can make the progress monitor a bit untidy.
- If you find you need to be tracking accounts production stages and audit stages simultaneously (e.g. where the audit planning is underway whilst the audit is also being planned), then you would want to look at options 3 or 4.
Option 1 - Add some (optional) stages to your existing Accounts Production route(s)
In our opinion, this approach oversimplifies the complexities an audit brings and is least likely to work well in practice. We include it here for completeness.
The existing route(s) on your existing Accounts Preparation workflow system can be extended to add the extra stages that an audit requires. You would have a decision point in the workflow (which could be taken automatically by reference to a Boolean field), where the job either enters the audit stages or does not.
This simple approach assumes that the job is either at an Accounts Production stage or an Audit stage at any one time; it does not allow for both to be true simultaneously. This might work if you are only interested in tracking, for example, the audit fieldwork that is undertaken once the Accounts have been prepared. In this case, your Accounts process effectively pauses whilst the audit is undertaken.
In this approach, you could not, for example, track the audit fieldwork whilst also having the Accounts go through review processes, etc. In this case, you need to be looking at options 3 or 4.
From a reporting perspective, identifying audit jobs would be by reference to a job boolean field (whilst not mandatory, this would be pretty useful; it could be populated automatically from client standing data) and/or the actual dates on the audit stages. Reporting options are, therefore, pretty minimal.
Option 2 - Add a new 'Audit' route to your existing Accounts Production workflow system
This is similar to option 1 but formally splits the audit jobs into a dedicated route(s). The clients active on this workflow system would either be active on one of the original Accounts route(s) or one of the new audit route(s).
The limitations from option 1, in terms of the current stage being either an accounts production or an audit stage, remain, but you get the flexibility that comes with a route. That is to say, you can modify the stages, steps, actions, fields, deadlines and alerts to be different on your Accounts and Audit routes.
The ease of reporting improvers here, too. All job-based reports can be filtered by and/or expose the route. Glide's progress monitor widgets can be route-specific or include a column per route.
Option 3 - Add an 'Audit' sub-system to your existing Accounts Production workflow system
In this option, the audit process gains its own flow diagram(s). Unlike options 1 and 2, the audit process can progress from start to finish without impeding the Accounts Production stage. Of course, being a sub-system, the Accounts Production progress, or lack thereof, can be used to auto-progress or block the audit sub-job and vice-versa.
This option allows the system to track the current stage of the Accounts Preparation and the Audit simultaneously, i.e. you can be doing two things at once with different 'current job holders' and 'next target dates'.
You would activate the audit sub-system at a client level where required. For non-audit clients, you would simply not activate it.
In some situations, you may find it useful to use this in conjunction with option 2. I.e. your Accounts Production route may be different to acknowledge an audit in ongoing, in addition to having the Audit sub-system.
With this option, your Audit sub-system can have multiple routes. This might be used to differentiate between different types of audit, e.g. a Pure Audit service from an Accounts + Audit service. This is also possible in option 2.
Option 4 - Create a new 'Audit' workflow system
This approach is remarkably similar to option 3, except the Audit job is now its own job in an entirely different workflow system.
You may find this a tidier option where you do lots of 'pure' audits or where you internally consider the audit process to be very separate from the Accounts process.
Separate jobs can not currently interact as closely as sub-jobs; for example, they can not block or auto-progress. Glide does have plans to introduce such a feature in the future.
You may also prefer this option simply to keep the count of sub-systems lower on the main Accounts system. If you already have both Accounts and Corporation Tax sub-systems, you may find the job card starts to get a little busy. (Please note that the next iteration of the job card will offer different ways to organise higher sub-job counts, such as tabbing through them, viewing just one at a time.)
With this option, for customers who also have Accounts Preparation, you will find that you have two jobs per annum, whereas for pure audit clients, you will only have one. The only complexity to consider here is when you provide Corporate Tax compliance in both situations. In this case, to get the Corporate Tax sub-job on the 'audit-only' clients, you may need an 'Audit CT' sub-system on the Audit flow.
If you do not wish to split your CT compliance across two workflow systems, then the alternative would be to create an Accounts job solely for the CT sub-system. In this case, you do not need to have the Accounts sub-system active; the job can exist solely for the CT sub-system. With this setup, we would recommend a dedicated route on the CT flow to reflect the existence elsewhere of the audit job, similar to how you may have a 'CT only' flow already differentiating from those that live alongside an Accounts sub-job.