Net transaction view

Often, trying to understand what comprises the balance on a GL account can be challenging, particularly where there a lots of journal entries (e.g. reclassifications and reversing journals).

Reclassification and reversing journals should be linked on the system. The user should be able to pick up a line entry (in the case of a reclassification) or a double entry (for reversing journals) and then execute an action (e.g. change the account code or cost centre, or reverse, etc). Such an action should still go through the journal segregation of duty/authorisation process and supporting documentation be retained.

The advantage of a system that links entries on the GL is that it allows a "net transaction view", i.e. only showing where transactions ended up (not how they got there). The full audit trail is there on the system if needed, but the "net transaction view" allows the contents of the ledger to be more easily understood.

Almost certain

Should risk management cover events or outcomes that will almost certainly happen?

The appropriate definition of risk

Unhelpfully, there are lots of different definitions of risk. For example, "a risk" can mean "a potential event". What helps me is thinking about what people mean when they ask the question "what is the risk?": they mean "what is the probability and significance of the outcome". Therefore risk is the probability and level of impact associated with an event.

But should it just be "event"? In some circumstances it may be helpful to think in terms of outcomes, situations and occurrences. For example, having insufficient premises isn't something that fits the definition of an event, but rather a situation.

Working backwards from controls?

Where there are already controls in place, should the risk be added to the risk register?

For example, if an organisation is new to implementing risk management, is it appropriate to track back from the controls in place to ensure all controls and their corresponding risks are on the risk register?

Risk: how low do you go?

How complete does risk management need to be? How low (impact/probability) should you go? At what stage are you just making risk management bureaucratic? How do you evidence the consideration of this long tail without including it in the risk management process?

We think to ourselves "this risk is too low (impact/probability) to include in our risk management". But this undocumented thought is itself risk management.

Is there an opportunity to outsource risk management for low value risks? Such an outsourcing function would, based on business criteria and information provided to it, estimate the relevant low value risks to the business. This document can then be shared with the organisation for sense checking (and possible escalation of some risks into the core risk register).

Organisational responsibility database

Often it is very difficult, particularly in a large organisation, to find out who has responsibility for what. One possible solution would be an organisational responsibility database. All of the responsibilities are defined in the database, and then assigned to a particular person. Another possibility would be to encourage staff to detail their responsibilities on the internal directory (and upload their job descriptions to it).

SOX software

Anyone who enjoys SOX auditing needs their head examined. But SOX auditing can be made much better. One of the areas of weakness in SOX auditing is relying on spreadsheets and other documents that could well have been prepared when asked for rather than at the time. A solution to this problem would be to create a SOX database system that allows a person (preparer) to upload a file, which is then date stamped and locked. Another person edits/reviews that file, another version of which is then date stamped and locked. Such a system would ensure segregation of duty (as long as password sharing doesn't occur) and prove that audit trail existed at the time.