Digital Financial Reporting

People might not get this, but this rendering of XBRL instance information (I am calling this a Level 1 Fact Group Rendering) is actually quite interesting from a number of perspectives.  I am not going to cover all the perspectives, just four. I hope I can make my points. I appologize for the colors, an artist I am not.

Fact Groups or Fact Tables

The rendering above shows a flat list of facts which are from one XBRL instance. There are several different fact groups.  Each fact group has different Measures (or some people call these dimensions or axis or aspects). Basically, each fact group (some people call these fact tables) is a fully complete table.  The different fact groups have different columns because each column contains the Measures appropriate for that specific fact group.

These fact groups are similar to business intelligence or online analytical processing (OLAP) "cubes".  XBRL uses the term hypercube rather than cube because a cube only has 3 dimensions where a hypercube can have any number of dimensions.

While it is true that the rendering is not all that great to use, it is certainly far better than looking at the XML of an XBRL instance. What if there were some default style sheet which rendered all XBRL as fact tables, in a consistent "more readable" format.  Would that be a good thing?  Maybe.  It could even be all you need for many different types of XBRL based information.  See the discussion about CSV files below.  Others need more rendering.  See the discussion about "Measure/Member Relations" below.

It seems to me that every XBRL instance can be expressed as a "more human readable fact table".  This includes XBRL which has no XBRL Dimensions (the context information is the dimensions), XBRL which has XBRL Dimensions (either explicit or typed members) and even tuples (the tuple is the Measure, the key concept is the Member collection of that Measure, and the other concepts are of the Measure-Concepts. I won't bore you with further details, but even non-XBRL dimensions can be expressed in this manner (i.e. the stuff you can put into the <segment> and <scenario> portion of an XBRL context.

Metadata "Levels"

You may want to go back and have a quick look at the graphic on this blog post. As I explain, the closer you are to the top of this inverted pyramid, the better the comparability you will experience.  Go back to the fact group rendering. Look at the namespaces table under "Report". There are five namespaces in that namespace table. Each of the namespaces corresponds to that diagram from the blog post (except I don't have a namespace for Regulator).

The point here is that who issues the metadata matters quite a bit. Each piece of metadata in the fact tables is explicitly defined as to who is providing the metadata except for two [Measure] values or these are sometimes referred to as "Members": brm:ReportingEntityMeasure and brm:CalendarTimeMeasure.  Basically, to reiterate and show more clearly that the blog post above, the more broadly used the metadata (the {Measure]s and the [Member]s) the higher the level of comparability which can be created.

Data as Contrast to Information

Take a look at this text file. For this you may want to go back and review this document which I referred to in another blog post. If you look at the text file you will probably not a number of things. First, it looks like a CSV (comma separated values) file.  Business people use these all the time to exchange information.  CSV files are easily loaded into spreadsheet applications such as Excel.

Compare that text file with the information in the fact group "[Network] gaap: http://xasb.org/gaap/SalesAnalysisByGeographicArea". Notice two things. First, the fact group rendering is way more explicit in describing the values than the text file.  Some of the context is missing from the text file, whereas the fact group is rather explicit.  Not everything is explicit.  You don't now if the information is audited or unaudited. You don't know if the information is actual or budgeted.

One point here is that information needs to be made as explicit as you might need it to be. It is up to the creators of the XBRL taxonomy and the consumer of the XBRL instance figure this out.  The other point is that XBRL can do everything that CSV can, but better.

Measure/Member Relations

Notice on the fact group rendering that the fact groups contain lists of facts.  There are no relations between the facts. Now take a look at this page which does show the relations between the Members used within the fact groups. You don't have to use them, but XBRL provides a way to document these or other relations.  CSV files (like above) don't have these relations expressed, that is one of the drawbacks of the CSV or table type formats.  They are flat.

You can apply the Measure/Member Relations and create far more useful renderings as is shown in the straw man implementation of the business reporting logical model.

This blog post briefly explains the notion of the intelligent business document. See this PDF for more details. For even more details, follow the links in that PDF to the details in the straw man implementation of the Business Reporting Logical Model.

I wish I could take credit for the term intelligent business document.  But I can't. Like is said, "Good artists borrow, great artists steal." I have used many different terms to describe this notion: neutral format table, interactive information hypercube, pivot table, data cube, etc. This has evolve since about 2006 or 2007.

So what is an intelligent business document? It is:

• Something that business users can create, without the help of the IT department, so that they can share business information with other business users without having to rekey the information.
• It has unambiguous business semantics.  As such, it can reliably feed information into and generate outputs from automated processes which can then be fed into other automated processes.
• It is 100% compliant with the XBRL syntax. But it can be serialized into any syntax because the semantics are unambiguous.
• It leverages something like the Business Reporting Logical Model, that is what enables the unambiguous business semantics.
• It leverages the flexibility of the multidimensional model.
• It makes is easy for the average business user to use.
• It is a global standard protocol, not a proprietary solution. It allows one business system to communicate with another business system effectively. (Keep in mind bullet point one; a business person achieving this integration without the help of the IT department.)
• It is dynamic. It is "interactive data" to use the term coined by the US SEC.  I prefer "interactive information" because it is really about information, not about data. You can pivot the information to suit your needs like an Excel pivot table or a Business Intelligence application allows you to pivot information.
• It could just be a boring form, but it is a form based on a global standard that every business system (literally, every business system) can both generate and consume.
• It will save business users time, money, and it will make their processes more effective and efficient.  It will improve the quality of their business information because information integrity is enhanced.
• It will allow drill down from top to bottom of an information "stack".
• It will provide an audit trail as information moves from point to point within that information stack.
• It works for financial reports, which are a form of business report. But non-financial information can also be expressed within an intelligent business document.

Take a look at the PDF which explains this in further detail.

Take a look at the straw man implementation which shows this is possible. I realize that is a lot of information, but it will be worth your while.

That is my vision for what XBRL could become.  You have a better vision?

I think that I have definitive proof that SEC XBRL can be made vastly easier than it is today. So what is the proof? OK, here you go:

• SEC XBRL Logical Model:  The SEC has no real official logical model of the business semantics used in XBRL filings.  But, that does not mean that a model cannot be created. In fact, anyone desiring to make XBRL easier for business uses to make use of will implement a logical model. Creating or extending XBRL taxonomies and building your SEC XBRL filings at the XBRL syntax level in your application? That is because your software vendor has not implemented a logical model.
• SEC Semantics and Business Reporting Logical Model Semantics Mapping to the XBRL Syntax: This is a mapping of the semantics of SEC XBRL filings (cross referenced to the Business Reporting Logical Model) to the XBRL syntax implemented by the SEC.
• Straw man Implementation of the Business Reporting Logical Model: This may be hard for people to grasp, but let me do my best to explain.  This straw man implementation of the Business Reporting Logical Model basically implements the "stuff in the boxes" of that logical model.  I made the straw man implementation work the way I would expect to work in my prototypes.  The SEC XBRL Logical Model simply changes two things: the names of the boxes and the XBRL syntax used to implement it.

Truthfully, I don't know if most people will see what I am getting at here.  I am going to go one final step. That step is to modify my hypercube viewer application (see the straw man implementation) and then run one or two of the better SEC XBRL filings (i.e. they are building [Table]s correctly) and see what it looks like in my hypercube viewer.  I may not even need to modify the hypercube viewer.

The only problem with this is that now each vendor who implements a logical model to make XBRL easier for business users will do so in a proprietary manner because there is no global standard business reporting logical model yet. Well, it just may be that this is part of the evolution XBRL will need to go through.

It was announced today that EDGAR Online and UBmatrix will merge. Here is the first two paragraphs of the press release:

NEW YORK and REDWOOD CITY, Calif., June 24 /PRNewswire-FirstCall/ -- EDGAR® Online, Inc. (Nasdaq: EDGR) and UBmatrix, Inc. today announced the signing of a definitive merger agreement that would create the first global end-to-end provider of solutions for the creation, validation and analysis of XBRL (eXtensible Business Reporting Language) content.  UBmatrix is one of the original inventors of the XBRL financial standard, which is being mandated worldwide by many regulators to improve the transparency and efficiency of business reporting.

The merger would combine EDGAR Online's position as the leading provider of U.S. Securities and Exchange Commission (SEC) public company XBRL filings and XBRL data, and UBmatrix's experience as the leading XBRL software provider to independent software vendors and major U.S. and international regulators.  The combined entity will be strongly positioned to provide global markets with XBRL based transparency solutions from issuers to regulators to investors.

Another thing that the Business Reporting Logical Model does is enhance comparability and interoperability. Or to be more precise, the Business Reporting Logical Model minimizes the effort required to achieve comparability and interoperability. It opens the possibility of a business domain to create comparability, should they desire to do so. Interoperability means easier to use software and less costly software for business users.

Here is why.

Comparability

(Here is a link to a PDF of this graphic.)

Today, there is no logical model below the XBRL syntax level. The only model any business domain has to work with is the XBRL syntax or some model they create. Creating that model and all the infrastructure to enforce that model takes time and costs money.

Or, another way of looking at this is that each company desiring to use XBRL for, say, financial reporting could create their own model using XBRL. That model could be 100% XBRL compliant (i.e. comply with the global standard).  Each company would have to deal with all the "stuff" in the middle such as which GAAP (accounting standards they would use), create their own XBRL taxonomy, and so forth.

The "middle ground" needs to be created.  The US GAAP Taxonomy created some of this middle ground.  You can see that middle ground in the US GAAP Taxonomy Architecture. But, the US GAAP Taxonomy is not enough.  That is why the SEC had to create a boatload of additional EDGAR XBRL Validation tests (see this list of errors, here is the test suite). Of course, the SEC would probably never want XBRL International to deal with 100% that that specific regulator needs to deal with, nor would XBRL International members do that; it would be like everyone agreeing to do business reporting exactly like the SEC does it, that would become the XBRL standard.

Business information exchange is a balancing act. Where agreement is achieved has ramifications for business users. Too much flexibility has its issues, too much comparability (or requiring things too high in the stack) has its issues. Where comparability exists within the "stack" (the diagram above) is up to the business domain's implementation of XBRL.  XBRL itself does not control this. How XBRL is used does.

Interoperability

There is another piece to this puzzle.  XBRL is a standard. What a system needs to make business information exchange work properly, it seems to me, is a protocol.  There is a difference between a standard and a protocol. A difference worth understanding. Erez Ascher (Ascher Consulting & Development) articulates the difference between a protocol and a standard as: 

• A protocol is a series of prescribed steps to be taken, usually in order to allow for the coordinated action of multiple parties.  In the world of computers, protocols are used to allow different computers and/or software applications to work and communicate with one another.  Because computer protocols are usually formalized, many people consider protocols to be standards.  However, such is not actually the case.
• Standards are simply agreed-upon models for comparison, such as the meter and the gram.  In the world of computers, standards are often used to define syntactic or other rule sets, and occasionally protocols, that are used as a basis for comparison.  Some good examples include ANSI SQL, used to compare derivations of the SQL database query language, and ANSI C, used to compare derivations of the C programming language. 

In other words, it seems to me that protocols can be standards, but standards may not contain all that is necessary to "allow different computers and/or software applications to work and communicate with one another". Therefore, every business system, such as the SEC XBRL filings system, must add "stuff" to XBRL to turn the standard into a protocol it seems. For every system to have to do this is both inefficient and ineffective because you really don't get cross business system interoperability. What you get is what we have today - many point solutions or one-to-one integrations.

So not only does the Business Reporting Logical Model enhance comparability, it also enhances interoperability. The Business Reporting Logical Model can provide the pieces which can turn the XBRL standard syntax into a business reporting protocol. I am not sure if it is all the pieces, time will tell. But I am sure XBRL alone is not enough to give business users what they need from XBRL.

The Bigger Picture - Financial Reporting in the Age of the Semantic Web

There is a bigger picture here.  Consider this blog post titled "Why the Semantic Web Will Fail". The post is pretty good, but what is really interesting are the comments to the post. The way I read that post and all the comments is that the Semantic Web is inevitable, but no one knows when it will arrive.

I contend that the Semantic Web is already here. The US Securities and Exchange Commission (every US public company financial in XBRL by July 2011), XBRL US (US GAAP Taxonomy), Tokyo Stock Exchange, Japan Financial Services Agency, Korean Stock Exchange, China Securities Regulatory Commission and Shenzhen Stock Exchange, Japan's EDINET, the Commission of European Banking Supervisors, the US Federal Deposit Insurance Corporation, the International Accounting Standards Board (IFRS, standardized financial reporting meta data expressed in the XBRL syntax) among others have already created pieces of it for financial reporting. The US SEC, Japan FSA, and IASCF are already reconciling their implementations of the XBRL standard to make them more interoperable. The Business Reporting Logical Model will make it so others don't have to go through this reconciliation process.

Is XBRL perfect? Certainly not. But XBRL is not RDF/OWL. Who cares, both XBRL and RDF/OWL are just syntax. On can convert from one syntax to another easy enough. The hard part, agreeing on the meta data and getting vendors to support the idea, is done (for US GAAP and IFRS). The IASB started on IFRS in the 1970's, even before the Internet existed. Most countries have either switched to IFRS already or will. Even if they all don't (i.e. the US will converge, but may not convert), reconciling US GAAP to IFRS is not that much of a challenge really. Oracle, SAP, and IBM all support XBRL within their software.

Maybe I am wrong, but it seems to me that a better question might be "When will others catch up to how the financial reporting business domain has embraced the Semantic Web?" That may by an over statement, financial reporting has a ways to go. The Business Reporting Logical Model will help others get into the Semantic Web easier than the early pioneers.

How did XBRL International get to where it is? Back in 2003 Joan Starr wrote an article Information politics: The story of an emerging metadata standard. Here is the article's abstract:

Information politics: The story of an emerging metadata standard by Joan Starr

This is the story of how one commercial metadata standard — XBRL, or Extensible Business Reporting Language — has attracted the participation and support of some of the world’s most powerful public and private organizations. It begins with a look at the nature and use of financial information in today's Internet-enabled environment and discusses three information use patterns: Transaction, retrieval, and reporting. While numerous, sometimes competing standards have been developed for transaction information, XBRL alone has emerged to address reporting formats. Today, the XBRL specification has wide support across the accounting, financial, and regulatory communities. This has come about largely through the efforts of the standards’ governing board, which has pursued a strategy of careful definition of market scope, deliberate courtship of important allies, and establishment of a culture of aggressive outreach for members. The results are impressive. Members of the organization are now positioned to take greatest advantage of a number of new entrepreneurial opportunities that have been created by the organization. Additionally, some participants are now representing the XBRL metadata standard as a key tool for the restoration of public confidence in the scandal-rocked accounting and investment industries. This may create a serious problem for researchers and investors as unaudited financial statements formatted in XBRL proliferate on the Web sites of corporations anxious to demonstrate a commitment to what some are calling "the new transparency."

XBRL seems to have achieved the right mix of technical and business participation. While what the technical people did was very good and very important, I think that what the business people who participated in XBRL created was perhaps even more important. Business users of XBRL should try and understand and push for the Business Reporting Logical Model to be standardized within XBRL International.

This will provide the flexibility where flexibility is needed, but also the things needed for a protocol to work well, be effective, and be efficient. Having every implementation of XBRL undertake this task will hurt XBRL, making comparability of XBRL based information more challenging and interoperability of XBRL software and different implementations near impossible.

So that is what I see. How do you see it?