Category: Web technologies & information standards (Page 45 of 58)

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?

XBRL is, in some ways, a funny kind of XML language. It doesn’t make much use
of the capabilities within XML Schema to express relationships such as
order, hierarchy, and so on. Viewed strictly as XML, XBRL looks pretty flat,
without a lot of contextual constraints.

But that’s nonsense, of course. Financial documents are highly constrained
and contain intricate interrelationships. XBRL expresses these relationships
within "taxonomies"–special XBRL constructs that define business
"concepts" and that relate these concepts to each other. The
relationships can, in fact, be really complex …more so than would be possible
within a strict XML Schema definition.

Once consequence of this decision to define the bulk of XBRL semantics
outside the range of standard XML semantics is that XSLT (XML Stylesheet
Language Translator) doesn’t work very well
as a way to transform XBRL documents into something that humans can read. Since
XSLT cannot
"understand" the information in the XBRL taxonomy, XSLT does not have
the information that it needs to present the "facts" in an XBRL instance
in a way that reflects the taxonomy relationships. 

So, how do people produce formatted output from XBRL today? In a Wednesday morning session at the 11th
International XBRL Conference, Raymond Lam of BlastRadius
explained that the usual solution is to hard-wire all
the necessary contextual information into the XSLT rules.  The result is an XSLT
stylesheet that contains nearly as many separate template rules as there are
separate facts to be presented.  Bummer.

Continue reading

When you cut through all the details of banking applications, specialized industry applications, special tools for formula processing, other tools for presentation, international applications, and more … there are really just two fundamental uses of XBRL.

Here is the first use: You start by producing your financial statements the same way that you always do. Once you have your completed financials in hand, you convert them to XBRL and send them out into the world. In this model, XBRL is for the benefit of everyone else. They thank you.

Here is the second use: You identify all of the fundamental transactions in your business according to a taxonomy expressed in XBRL. You use this classification of all the basic financial facts within your organization as a way to aggregate these facts, discover new facts, track activities, and produce reports. What you learn from this use of XBRL is your business. You’ve got yourself to thank.

It is possible to combine the uses, starting with the second use, using XBRL for your own purposes inside your company, and then moving to the first use, creating XBRL reports for the rest of the world. The possibility of combination should not obscure the differences between the two uses.

Not surprisingly, these two different uses of XBRL get separate treatment within the XBRL community. The first use–focused on external users–is supported by a set of “financial reporting” taxonomies,collectively referred to as “XBRL FR.”  The second, internally focused use has a taxonomy of its own, called XBRL GL (for “general ledger”).

If I were betting, my bet would be that the success of XBRL–the breadth of adoption–will depend on which of these taxonomies takes hold in the market.

More specifically, I would bet that broad use of XBRL depends on the eventual success of XBRL GL, or some descendent or variant of it. The reason is that internal use is the only way to get return on investment in XBRL. It could be used to automate internal controls, contributing to better internal decision making, better risk management, and more affordable, sustainable compliance. It could be used to radically reduce the cost of external audits.  It could be used to support management decision tools–dashboards, metrics, benchmarking–to help the organization become more competitive.

By contrast, it is hard to see where the payout is from tagging financial statements in XBRL only at the end of the process, for release to the analysts and regulators.

The people who would bet against me are those who figure that XBRL is going to be imposed from the top down, as a requirement by regulators. I don’t see that happening in the U.S. As the SEC’s Peter Derby said last Tuesday morning at the XBRL conference, XBRL is currently hard to do and U.S. regulators prefer to follow the market’s lead when it comes to technology. It could be a different story in Europe, where, for example, the need to bring 25 different national banking systems together under the direction of a single Committee of European Banking Supervisors really does appear to require something like XBRL:  If it didn’t exist, they would need to invent it.

Assume for the moment that I am right–that internal use of XBRL will be what drives this market forward, and that broad availability of XBRL FR, created automatically from the in-house XBRL GL, will be the consequence, not the cause of market acceptance. Given that assumption, you would be looking for evidence of internal adoption. Is it happening?

From the evidence at last week’s conference, the answer is “NO.”  The only country where there seems to be serious focus on internal use is Japan. Hitachi showcased a case study of an XBRL GL implementation for WACOAL, an apparel manufacturer, and PCA Corporation, which offers a Japanese financial accounting package that was described as being similar in scope and market reach to Quickbooks, has announced support for XBRL GL within their product.

What might broaden this activity?

XBRL GL is currently a technology looking for a good problem to solve. This is not to say, at all, that XBRL GL is not potentially useful. Look at the list–executive dash boards, more effective internal control, reduced cost of compliance–each of these outcomes is very useful. But XBRL GL has yet to demonstrate that it is the critical, secret sauce that makes any one of these good outcomes doable, affordable, or more effective than ever before. XBRL GL needs to move from a technology that could beused for any of these good things to becoming the critical technology that an organization must haveto make some one of these good things available and affordable.

I think this can happen.  It will be driven by an application that needs XBRL GL, and not from XBRL GL needing an application. There are a number of candidate applications. What remains to be seen is whether the companies building and using those applications will find that XBRL GL is the missing piece they have been looking for.