XBRL and Compliance

I have just finished working on a paper with an industry group that is concerned with compliance issues. The paper takes a broad look at enterprise-wide compliance issues, as distinguished from the trap (an easy one to fall into) of dealing with compliance in a fragmented way, driven by the demands of different (and changing) regulations.

What are the requirements for an enterprise-wide, operational approach to compliance? Well, to get the full answer you will need to read the paper when it comes out in the next few weeks. But there was one requirement –a requirement that I want to talk about here– that ties into the threads and postings about XBRL here on the Gilbane website.

One of the first, big steps toward getting a broader, more useful view of “compliance” consists of applying it to internal control procedures, rather than just in reference to external requirements. “Compliance,” in this view, means doing what is right for the organization.

Take relations with donors within a non-profit organization as an example. Compliance, in this instance, means that the staff follows the organization’s procedures for contacting donors, working with donors to structure gifts for maximum tax advantage, and staying in touch with and supporting donors after the gift has been given. Compliance, in this sense, means making use of what the organization has learned over time. Compliance is the means by which the organization ensures that learning is retained and put into practice.

Stepping back from the particulars and looking at the general case, compliance is one part of the mechanism by which an organization responds to its environment — to the sources of support, to threats, and, of course, to rules put in place by governments. Compliance–the exercise of internal control systems–is how the organization regulates itself so that it survives and thrives in its environment. To use a human analogy, your body’s responding to infection is kind of compliance response. At a higher level, using learned compliance, your responses in a business meeting–measuring your reactions, thinking before you speak–are also forms of control and compliance.

The point of taking this broader view  of compliance is, of course, to help organizations deal more deliberately and productively with the process of making decisions and taking risks.

But … when you put this good thinking and theory into practice, you run into a problem. The problem is that, for each component in this overall compliance system, the key to making the system work is always in the details–BUT–at the same time, you want to somehow get these systems to connect with each other.

And, they DO connect with each other. When you connect the details of
responding to infections with the details for responding to a business meeting, for example, you find that it is very difficult to put all the tact and learning about social interactions into play when you are running a raging fever.

This isn’t a far-fetched analogy. When you take a close look at the day-to-day operations at Enron, courtesy of a book such as Kurt Eichenwald’s Conspiracy of Fools, it is hard to escape the sense that the Enron tragedy grew from a combination of thousands of small infections coupled with a couple of big instances of shortsightedness and fraud. The interesting question raised by a book like Eichenwald’s is one of how the entire system managed to get out of control–and, if we can understand that–how can we prevent such interactions in the future.

So, the problem is one of finding a way to operate effectively both at the level of forest and at the level of trees. You’ve got to sweat the little things to make compliance work, but you also have to see how the little things work together in big ways.

One reason that this is so difficult is that many of the different, “tree-level” compliance efforts use different terms, because they reflect different concerns.  Calibration of lab instruments is an important aspect of compliance. Protecting privacy of patient records is another aspect of compliance. Tracking costs for clinical trials is yet another. Each uses a different language, reflecting different concerns. Yet all of these activities, taken together, contribute to assessing the health of a pharmaceutical research effort.

Successful governance–overseeing these compliance efforts and understanding what they are telling us–depends on finding a way to abstract the common elements and concerns. Communication of the common concerns depends on defining a “forest level” view that imposes uniform, organization-level language and perspective on all the tree-level activities.

My sense–and I am putting this out here for discussion and argument–is that XBRL is a good candidate for doing this. Taxonomies are a large part of what XBRL is all about, and XBRL has the flexibility, viewed as a formal language, to describe taxonomies at the level of “trees” and to link those “tree-level” concepts back up to a set of concepts that are appropriate to the needs of someone who wants to see and manage the “forest.”

Taking my pharmaceutical research example, XBRL taxonomies could describe the disparate concerns of instrument calibration, patient records, and financial costs, recording and tagging the facts associated with each of these areas of activity. The recording and identification of these facts would be an integral part of each detailed control process. At the same time, XBRL could be used to capture exception conditions and other aggregations, supporting high level, management control systems.

I would be interested in reader feedback on this idea. I am pretty sure that we do need a way to move from trees to forest and back again, and it seems to me that XBRL is set up to do that job. What do others think?