Ah, old times!
I was brought up as an internal auditor in a day and age when computer aided auditing was still to become mainstream. I know that dates me, but so be it. My first years of auditing consisted of performing audit tests as described in a paper work program. I was responsible for documenting the work performed in a concisely prescribed manner on large yellow 14 column papers as well as hauling large stacks of working papers to and from the client, both current and prior-period documents that could barely fit in one large case. My back still remembers the pain of carrying thosecases around when I think about that time. I also remember taking a lot of photocopies. And making lots of pots of very strong, black coffee for my seniors. Ah, old times!
A paper based paradigm
Traditional working papers had an established structure that carried over from audit to audit, which made reviewing the work easy. I learned to appreciate the existence of that structure when I was a senior and a manager and had multiple clients to review. now, the purpose of those working papers was dual: they were both a proof of the work that had been performed as well as a support for the material findings that would eventually make their way into the final report. The hierachical structure was developed in such a way that referencing your report for completeness and accuracy became very easy indeed. This paper-based paradigm was essential in a period where paper was what we had.
The inertia of older partners
The transition from a paper-based system to a computer supported system went rather slow. The successful software emulated the paper-based paradigm. This software was successful because it was recognizable. We gained acceptability. We lost a lot of the flexibility inherent in these new systems. However, most of the older partners who have final word on the investments were not ready to adopt an entirely new way of working.
A high level overview of our current approach
But how do we go about our work now, as internal auditors? After a preliminary risk analysis based on information gathered from the entity to be audited, prior period work papers if these exist and other sources of information, we develop a risk analysis. That risk analysis is the basis for the development of a high-level work program. At the start of the actual fieldwork, during initial interviews and procedural testing, we gather evidence that leads us to develop a more in-depth work program which aims to gather additional information and perform more specific tests, eventually proving or disproving any assumptions that we may have made at the outset. Combining different sources of information, we home in on an eventual conclusion. We do this for all relevant aspects of the function or activity we are auditing, within the limitations of the scope of the work.
We document the work we have done, sign off on it in preparation for review by a peer or a superior. In certain cases, our findings are material and our conclusions result in a finding, which can give rise to a recommendation. These findings, and in certain cases the recommendations together will form the bulk of the report. This is pretty much Sawyer 101.
A report is a linchpin
Now, a report is a special document. it is the linchpin document of the entire audit, holding everything together. It is important that all the findings, if considered material, are properly represented in the report. Our working papers need to show that the finding is relevant, by means of our documented work, and that all relevant findings have been appropriately integrated in the report. If a finding is not reported on, it needs to be clear why. The report needs to be easily reconcilable with the documentation of the work done.
The traditional solutions were not flexible enough
The problem we faced at BTC is that the current crop of working paper solutions, most of them software as a service, are just not flexible enough. They provide you with plenty of tools that work fine if you work in their specific manner. However, our reality, one of auditing development aid programs in the field, often in the middle of Sub Saharan Africa, requires us to have a significant amount of flexibility just not adequately offered by the current, popular systems. So after a year of test driving a traditional system, we decided to migrate to 37Signals Basecamp. And although not perfect, we are quite happy with the results. we currently use Basecamp not only as a working paper repository, it also acts as our general audit information and documentation hub and we use it in our collaboration and exchange programs, both for internal projects as well as projects with other parties.
We integrate communications with auditees
Whenever we start a new audit, we create a new project in Basecamp. We write a text file with the motivation for of the audit, the audit scope etc. Any communication with the auditee is forwarded to the email address exclusive to that specific project. This way, we have a complete trace over all communication relating to the project.
To do lists play a central role
During the preliminary phase, all documentation relating to assessments, interviews etc. is posted to Basecamp. This work eventually leads to a high-level work program, for which we develop a to do list, one of Basecamp’s core functions. All tasks to be executed as a part of that work program are assigned to a collaborator, who does the work and provides adequate documentation in the comments section of the to do activity. Basecamp’s to do’s allow you to attach files and even, if that is your poison, provides links to Google docs.
Clearing tasks is up to the reviewer
From a practical point of view, a collaborator does not check off the task after having executed the work. Rather, he reassigns this to the responsible reviewer, who will review and, if so required, will create a finding in a separate list, which is just another to do list, aptly named Findings. During our review, we ensure that all tasks have been properly cleared by the correct person. If we feel the work is not appropriately done, we comment, open up the point again, and reassign it to a collaborator.
Using a separate findings list
Eventually, after due consideration and review of the underlying evidence, we publish a finding to the findings list. When we publish a finding to the findings list, it is URL linked to the evidence in the Basecamp project. This way, a reviewer with the right authorization to access the project can easily review the underlying documentation in order to assess the validity of the findings. This is ideal for thorough peer reviews.
URL linking everything together
Ultimately, the draft report is an integration, in one document, of the retained findings and recommendations. To ensure easy links to the findings, that draft report contains links to each of the findings as presence in the project Basecamp space.
After receiving comments on the draft report, we forward that information to our project space. Our final report is linked to the draft report, as well as to the comments we received. Any comments received but not included contains a motivated disposition on why it was not included. The final report is in turn linked to a presentation which is prepared for presentation to the audit committee. Of course this presentation can also be found back in our project space, where we post a version that contains links to each of the findings presented to the audit committee.
Cleaning up after ourselves
After we presented the report to the audit committee, we clean up our Basecamp project space. For this we use a closing out checklist. This checklist requires us to go through each document in the project space and review its relevance. Documents which do not support findings or recommendations or have no other relevance in the context of the project, can be removed. We actually move those documents to a separate just in case project space where they will reside until the end of the year, when we clean out our Basecamp space.
Once the project is cleaned up and all links have been checked, we archive the project. By archiving, we ensure that no one can change the information present in that audit file.
Our evaluation
Is this system perfect? No, it is not. When we are working remotely, with that Internet connections, we need to document locally to our drives and upload later, whenever we are close to a good Internet connection. Mailing in the documents is an alternative which is provided by Basecamp, but that does not reduce the effort of the ex post reconciliation. If 37Signals would ever consider off-line mode, we would be very happy. Having said that, the simplicity of their current solution augments its flexibility, which is why we chose it in the first place.
This should provide you, dear reader, with some insights into how we Basecamp as work paper documentation for our internal audit work.
Exploring The Black Box 