How much business process documentation is required? 2232

  • Just wondering if there are any general and practical principles in use out there to distinguish between business process steps and control activities?
    My general thinking is that a business process is simply a series of reasonably well defined activities, typically performed on a recurring basis, that are intended to achieve some business objective (be it operational, financial or compliance oriented in nature). Where things might get a bit murky, is in how one distinguishes business process activities from related control activities (for ICFR purposes) within Sox related documentation;and how much time s/b spent on business process documentation in Sox work.
    Also, too wide a definition of what’s a control could lead to unwarranted time spent on documentation of business process steps. My general thinking in this area is that for Sox purposes, business process documentation s/b limited to providing context for control activities. Otherwise, documentation work would explode in breadth, depth, and time required; and consume enormous resources. The art of course is to demonstrate an ‘adequate’ understanding of the business process without spending too much time on documenting it. In this context, adequate means enough to identify associated risks and appropriate control objectives.
    The standard view of business process steps versus control activities seems to be that they are obviously two different things, because a control activity only exists in relation to one or more related business process activity. Thus, preparing and recording a JE is the business process activity (aka process step), while review and approval of the JE constitutes a control activity (aka a control). That seems simple enough. If the activity is designed to ensure that some related business process step functions correctly, then its a control activity. If not, then it’s just a business process step. In Sox work, the focus (and thus majority of time spent) s/b on documenting the control activities, not the business processes.
    Another view, or perhaps another definition, seems to be that control activities are just one form of activity embedded within, attached to or performed in conjunction with a business process. From this perspective, a control activity is simply a ‘special’ kind of business process activity; and the definition of what’s a control activity depends on what the business process activity (or some aspect of it) is intended to achieve. A good example might be an application control consisting of some edit check that prevents a posting to the accounts, unless the posting is to a valid account (ie lookup check). In this case, there’s a control embedded within a regular business process step.
    Regardless of the definition used, are there some general guidelines out there that are helpful in focusing documentation work on risk, control objectives and control activities; and preventing too much time spent on documenting business process? Helpful and practical suggestions would be much appreciated.

  • Welcome to the forum graybeard. We look forward to your ongoing questions and input.
    The short answer to your question is that there are no ‘standards’ as to level of documentation.
    We have worked with two different Big 4 accounting firms and have seen documentation ranging from bullet point overviews to detail process descriptions. My personal preference is a process summary that touches on the various steps required to complete a process. It is generally not worth the time to prepare a step-by-step procedure guide to serve as your process narrative. With this type of narrative, a reviewer will get lost in the details. You want to create a document that will give a reviewer a good understanding of process flow and the critical control points within the process. In reality, you will quite often end up with a document that reflects the authors writing style - sometimes detailed and sometimes very brief.
    My guess, based on your initial post, is that anything that you create will be thorough and well-written.
    Most companies over-documented when they first adopted SOX. That is because most took a bottom-up approach to controls by creating detailed process narratives and then identifying the control points within the processes. This resulted in many transaction-level controls being identified and tested.
    The latest SEC guidance to take a top-down approach will result in much shorter process narratives as you really only need to identify controls (and related processes) around those ares where you do not have high-level review controls that are effective in addressing FS risks and assertions. For us, this means that we now have very few transaction-level controls that we rely on as primary controls.
    Before you start in with your documentation, make certain that you read and understand the latest SEC guidance as well as PCAOB AS5.

  • KYMike,
    You mentioned that you have very few transactional level controls that are being considered primary /key controls now, and this is exactly what I have been pondering about. As most, if not all, companies have a pretty comprehensive review and analysis of their monthly financial statements, would that alone act as a very powerful entity level control? In concept, I think we can use those reviews to cover a lot of the transactional controls, but it just seems weird that now we are almost going back to pre-SOX times when companies did that anyway, to catch anything that transactional level controls don’t catch.
    Thanks for your insight.

  • In order to eliminate the transactional controls, a company must have a very solid close process with good analytics and management review. We compare current month to our internal plan and prior year and explain significant variances. We also have a very good process around account reconciliations.
    While some companies may be moving back to pre-sox times, I think that most will have improved controls and management review. We have always had those in place.
    In addition to a strong management review process, the other areas where I feel strong controls are necessary are SOD, ITGC, reconciliations, spreadsheets. Also, management review will not catch errors in judgment when reserves are recorded. Those need to be reviewed in more detail than other accounts that lend themselves to a good analytic review. Spreadsheets need good controls because they are not kept to the same standards as IT applications, but we tend to rely on them just as much.

  • Trying not changing too much this topic’.
    How many level did you document your spreadsheets controls? And what about spreadsheets when you have an ERP, where manual journal entries are placed based on spreadsheets (are those important)?
    I have heard lots of controllers saying that some accounts are controlled direct on financial statements, without any reconciliation and support spreadsheets. Some times, but not at all, those accounts have feel documents and low fluctuation.
    Are there companies using narratives and flowcharts for documenting their controls and process?

  • Spreadsheet controls seem to be a very controversial topic, in the SOX context anyway. I’m the SOX Project Manager for my company and while I’ve included spreadsheet controls at the corporate level, I cannot say the same for our subsidiaries. The topic was broached and it was decided that any material variance resulting from a flawed spreadsheet, inappropriate access, etc., would be identified during our month end reviews in our financial reporting process/controls. As already stated, in order to rely on this type of entity level control, the reviews need to be well documented with the significant b/s accounts scrutinzed and evaluated accordingly.

Log in to reply