Re: Accounting Firm Audit Methodology vs. Technical Writing Research Styles

[Lisa Wright <liwright -at- earthlink -dot- net>]

Hi Anthony,
Congratulations on the job! I am doing similar work. In fact, we are 
this week wrapping up our documentation and reviewing the controls with 
the client, who will sign a document stating that the controls are 
accurate and the company is ready for testing. Then we develop test 
plans for the controls and execute the tests. (I probably won't be 
around for that part.)

I can't really speak to what most audits look like, but I'll share my 
experience to give you some idea of what a project might look like.

As part of pricing the project, the project manager and the client agree 
to the scope. In the case of SOX work, that means the specific processes 
where you are going to document the controls. We don't deviate too much 
from this list. Scope is based on several things (this is a partial list):

1. What are the external auditors concerned about? For that you read the 
past audit reports and consult with them.
2. What did the company reveal in its 10K and recent 10Q statements?
3. Have any areas of concern arisen for the Audit Committee (an 
independent arm of the board of directors, and likely the group your 
project team is accountable to). Concerns can arise from the internal 
auditor or from whistleblower reports.
4. If there's cash money involved, there are standard areas you'll look 
at: Sales Audit, Cash Receiving, etc.
5. What is the materiality of the account, meaning, how much money is 
involved?

I attend meetings with the accountant-consultant. I am not a project 
lead and I am not responsible for developing content, except for 
drafting Visio flowcharts based on the meetings. Because I've done a lot 
of interviewing in my career, I make contributions at meetings and ask 
good, relevant questions that will help me create the flowchart ("who 
does that? what report do they use? what account does that hit? who is 
responsible?"). At the beginning of the project I developed the tools 
they would use and standards for them to follow. At the end, I am doing 
QC on the document set based on standards and anything that's evolved in 
the course of the project.

To develop the content, the accountant-consultants look for existing 
policies and procedures, the interview the people who do the processes, 
and they document the controls that mitigate the risks. Documentation 
takes the forms of a flowchart, a risk-control matrix, and a narrative 
that describes the process. The narrative is *not* a step-by-step SOP.

If I *were* developing content, I'd be doing some similar activities to 
tech writing, except for one thing: My job on a SOX project would not be 
to doc the process. My job is to doc the controls *around* the process. 
You have to capture enough so that someone can understand what's 
involved, but not so much that you could do that person's job. It's a 
subtle distinction, and it's tripping up one of the 
accountant-consultants who has an audit background and is mired in the 
details. We are supposed to take the 30,000-foot view. Nor are we in a 
process improvement project, though we do have to report areas requiring 
remediation and follow up on that.

My goodness, this has become quite a long essay. I'm not sure if I 
really answered your question, but I hope this helps a bit. Let me know 
if you have more questions.

Lisa

Anthony wrote: