I just finished wrapping up my first audit. So I thought it might be helpful/interesting, to post some of the things that I learned along the way. Some of the things that worked, and others that didn’t, as well as some good advice I received from various people.
Probably the biggest thing I learned – which I’m sure I’ll tweak with each audit – was the general framework of what you include and exclude from a file. At it’s bear bones, here’s what my file looked like;
- Engagement letter
- Audit committee letter
- Knowledge of business
- Documenting internal controls
- Testing internal controls/walk-throughs
- Identifying significant risks
- Audit strategy/planning memo
- Analytical analysis per leadsheet to highlight significant changes and risks
- Audit procedures specific to leadsheet and reflective of significant changes noted in analysis
- Proofing the mathematical accuracy of the financials
- Making sure all referencing ties in/descriptions are accurate/format is correct etc.
- Making sure notes conform to GAAP
- Writing audit report
Post field work
- Testing subsequent events period
- Management representation letter
- Independence letter
- Management letter
I’m sure I’m leaving stuff out, so if I’ve missed something blatantly important feel free to let me know. But this is a pretty decent outline of what was in my file. And I’ve found it to be pretty useful as a mental picture, so I know how far along I am when partners ask me for file updates.
Aside from knowing what goes in a file, being able to see each section and understand how the cogs fit together to form a finished working file, quickly unveiled itself as a invaluable skill as I planned my audit. This was my first real audit as a senior, so I wasn`t naturally good at forming the aforementioned `vision` of a complete file; I ended up learning it the hard way, through screwing up my audit plan – multiple times – and then forcing myself to redo it.
Knowledge of the business sets the context for the entire file. It should give you a decent understanding of what the business does, as well as it’s current strategy. And knowing that will give you an idea of what looks “normal” when reviewing the company`s financial statements. For instance, if you’re looking at a manufacturing company you’ll expect to see cost of goods sold, some type of inventory, maybe short term receivables and a few payables from various parts vendors. Things like that. Knowledge of business should establish this context that will permeate through the entire file. From looking at the business as a whole, you then drill down to understand the processes that maintain it – its internal controls.
Internal controls will impact the “nature” of your audit plan. Testing them will determine if they’re effective and whether or not you can rely on them when performing your audit. So if you know a client’s computer program is pretty legit, you might not have to do so many substantive tests – granted you’ve performed a significant amount of controls testing already. It’s an ebb and flow. The better the controls, the more control testing, the fewer substantive tests. Conversely, if the controls suck, there are no controls or one person does everything, you won’t be able to rely on them and you’ll be doing far more substantive testing.
Then there are significant issues. These are things that will have a large impact on the audit – i.e. the statements are going to be screwed up. Usually companies won’t have too many of these and they’re likely the result of new or complex transactions that the client didn`t know how to book. In my significant issues section I made note of these potential problems and the assertions they’d impact (account balance = completeness, rights, existence, valuation; transaction = occurrence, classification, cut-off, accuracy, completeness).
Based on these three things – knowledge of the business, internal controls and significant issues – I was able to draft a fairly decent audit plan. Knowledge of the business told me what I could expect from the client, internal controls told me how much substantive vs. control testing I needed to perform and the significant issues pointed me towards the areas that were likely going to be misstated.
From that I broke down my fieldwork by leadsheet, addressed the assertions that effected the account balance I was testing and then developed procedures that tested those assertions. Once that was done I knew what my audit was going to look like. And then it just became a matter of actually doing the work – which will make up part 2 of this little series.