Digital Financial Reporting

First off, before you jump to conclusions, this blog post is not about making any sort of judgment about what should be comparable and what should not.  That is for the financial reporting supply chain to figure out. This blog post shows the moving pieces of comparability and how to move those moving pieces should comparability be desired.

There are two set of prototype financial statements which I have created to work with, explore, test, and otherwise figure out how comparability works in XBRL.  Here are those two sets:

• Comprehensive example comparison: This prototype compares three financial statement-type XBRL instances which are constructed following the Business Reporting Logical Model (BRLM). This prototype is unconstrained by the idiosyncrasies of the US GAAP Taxonomy or SEC XBRL filing rules. Because I was able to create my own GAAP taxonomy, I could created it how I wanted to create it, maximizing comparability. This example shows the best comparability and how to achieve it, unconstrained by others.
• Reference implementation of SEC XBRL filing comparison: This prototype compares three SEC XBRL filings.  Each is a legal SEC XBRL filing as each uses the US GAAP Taxonomy and passes Edgar Filer Manual (EFM) validation, for the most part. Some things are intentionally done to make some specific points about comparability.

Moving parts of comparability

So what are the moving parts of comparability? When you think about comparability you need to think like a computer because it is the computer which leverages the "stuff" you provide to perform any comparisons. That stuff can take three forms: XBRL instance, XBRL taxonomy, other external stuff. Let us now look at those three pieces. (The Business Reporting Logical Model explains many of the terms used below. Section 4.3 of this document reconciles many of these terms to the US GAAP/SEC terminology used.)

• XBRL instance: The XBRL instance has all the fact values and meta data values which gives contexts to the fact values which you want to compare. Meta data values provide contexts for the fact values.  The fact values are the values.  For example, say you have a value "1000". The fact value is the value, plus the collection of measures which describe the value such as the concept which might be "Cash", the period which might be "December 31, 2010", the legal entity which might be "ABC Company", etc.  A fact value also has attributes which provide additional information such as the currency of the value which might be US Dollars or Euros (called units) and the rounding information of the value (called decimals).
• XBRL taxonomy: The XBRL instance contains all the fact values, the XBRL taxonomies defines much, but not all, of the meta data used by the XBRL instances. XBRL taxonomies do not define the periods which can be used, the entity identifies which can be used, the currencies or other units, or the rounding values; those are defined by the XBRL instance and unconstrained. But the taxonomy defines everything else including: networks (some people call these extended links but that term is actually incorrect, network is the correct term), hypercubes (called [Table]s in the US GAAP taxonomy, dimensions (called [Axis] in the US GAAP taxonomy), concepts (called [Line Items] many times in the US GAAP taxonomy), and values for dimensions/[Axis] which are called members (called [Member]s in the US GAAP taxonomy.  A special type of member is the domain (called [Domain] in the US GAAP Taxonomy.
• Other stuff: Other stuff, external to XBRL, is important to understand because you do need it and there are no standards for this as it is beyond the scope of XBRL, but these things are still needed.  One example of other stuff is some way for a computer to find the set of XBRL instances you want to work with, such as an RSS feed. The SEC created an RSS feed to provide links to XBRL instances. If you look at my comparisons, I followed the SEC lead and used RSS as the format for providing my list of files.  Others have their way of getting a computer application to a set of XBRL instances you will want to compare. Another thing you will need is a way to map meta data defined multiple times by different filers to indicate that it is the same. Other types of mappings are used to overcome meta data issues.  You will understand this better after the discussion we will have next.

So those are the moving pieces. Again, keep in the back of your mind that you need to consider how a computer deals with all these moving parts, not how a human deals with them.  The whole point here is to automate the process and avoid using human effort where possible.

Working with the moving parts

Now we look at some examples of working with the moving parts and how comparability is impacted. Differences may seem subtle, and they are.  But it is these nuances which make comparability work or not work. We will walk through this from the top down.

• Defining networks: Networks, which many people refer to as extended links or groups, is one tool which can be used to achieve comparability at the highest levels.  For example if you tell the computer you want to compare balance sheets, you can give it the network name for the balance sheet and grab that from each XBRL filing which you want to compare.  For example consider this network, this network and this network of ABC Company, XYZ Company, and QQQ Company of the reference implementation above. Not that they are all the same, "Network: 104000 - Statement - Statement of Financial Position, Classified (http://xbrl.us/us-gaap/role/statement/StatementOfFinancialPositionClassified)" from the US GAAP Taxonomy.  Well, that is actually illegal per SEC XBRL filing rules.  Each filer is required to define their own networks.  As such, networks are not helpful in comparing balance sheets or any other pieces of SEC XBRL filings because every network of every filer is unique for everything! By contrast, the vast majority of the networks of the comprehensive example comparison are the same. So, to improve comparability; define networks so they can be shared between filers which improves comparability.
• Defining hypercubes or [Table]s: Drilling deeper into XBRL taxonomy models the next highest level we run into after the network is the hypercube or [Table] in the US GAAP Taxonomy. Looking at the same portion of the taxonomies of ABC, XYZ and QQQ companies, the balance sheet, let us look at them another way; via the [Table] rather than the Network. If you check out the three links you will see that each is to a [Table] with the label "Statement of Financial Condition, Classified [Table]".  Now, look a little more closely and notice that the concepts are actually different, the are NOT the same.  Each company defined their own concept for the balance sheet table.  How will a computer understand that each of these are the balance sheet?  Well, it will not. By contrast look at this [Table] which is the same for ABC, XYZ, and QQQ. All three use the concept from the US GAAP taxonomy "us-gaap:Nonmonetary Transaction, by Type [Table]". Now, this is easy for a computer to understand to be the same [Table] so it can easily be retrieved and compared from all three prototype SEC XBRL flilings.
• Defining dimensions of [Axis]: OK, now go back to taxonomies of ABC, XYZ and QQQ companies and this time focus on the [Axis] of the Nonmonetary Transaction, by Type [Table].  Notice that the [Axis] "Report Date [Axis]" is defined by each company individually which can be seen by the different namespace prefixes abc, xyz, and qqq in each taxonomy.  By contrast, look at the "Nonmonetary Transaction Type [Axis]" which has the "us-gaap" namespace in each taxonomy, so that is the same [Axis] in each.  Again, the same helps comparability, different hinders comparability.  Now, analysts can create a mapping which tells the computer that they are the same, but that takes humans to do work which takes time and costs money.
• Defining domains: You get the general idea, so I will not repeat this for the [Domain], basically if the [Domain]s are defined in the US GAAP Taxonomy they are more comparable than ones defined in the individual company extension taxonomies.
• Defining members: Same deal for [Member]s.
• Defining concepts or [Line Items]: Same deal for [Line Items].
• Defining units: It is worth pointing out how units works a little differently.  Imagine every individual company having to define their own units, such as "USD" for US Dollars.  Not good. If each GAAP taxonomy, US and IFRS, defined the units then cross taxonomy comparisons are harder, mapping would be involved.  XBRL defined the attribute "units", so that can be shared between taxonomies, in fact, it must be as it is required on all numeric facts. Even better, XBRL actually relied on the ISO standards, specifically ISO 4217 which defined currency codes, such as the code for US Dollars "iso4217:USD" which is the global standard for specifying what currency something relates to.

So who defines the information/meta data has significant impact on comparability as you can see. Global standards such as ISO codes enable the most comparability. Things defined by XBRL itself are slightly less comparable. Next are things defined by a US GAAP Taxonomy.  Last are things defined by individual filers. Experiment with the two comparison prototypes above and see how they work in software applications. You can learn even more about the nuances of working with XBRL to create the comparability which you desire.

Impact of financial integrity on comparability

Financial integrity has a big impact on comparability. For example, if there is no agreed upon foundational definition of a balance sheet, income statement, statement of changes in equity, cash flow statement then those creating analytical software have to create one and normalize every different financial statement created by each individual SEC filer in order to create comparability.  That means two things: (1) Different analysts or data aggregators can create different definitions of the foundational definition of statements and (2) It is so complex to get data out of the many different filings that you will have to go through some data aggregator to get useful data.

But what if there were an agreed upon foundational definition of financial statements, certain policies, and certain disclosures? Then, querying the information at the highest levels would be quite easy.  At the lower levels, individual filers still have the flexibility to show the information they want to show but there is at least some basis for comparing.  Another way to say this is that computers don't do to well with random.

Conclusions

Try comparing the information in the two sets of XBRL instances above.  The results you get from the "comprehensive example" comparison will be better than the "reference implementation" comparison. That is because the comprehensive example was built to be comparable.  The reference implementation was constructed to communicate some comparability issues and had to follow the US GAAP Taxonomy and SEC XBRL filing rules.

Comparability is not an art, it is pure science and testing comparability is quite objective. Some financial reporting supply chain deciding WHAT will be comparable is an art and is quite subjective and political. Whatever the supply chain might decide can be expressed in XBRL. Understanding how to use the XBRL medium helps one use the features of the XBRL medium far better than leaving things to chance.

Again, this blog post deals with the science of comparability, not the art of what should be or should not be disclosed. That is a different discussion.

There is increasing talk about the need for quality SEC XBRL filings but there is less information on exactly how to create a quality SEC XBRL filing. Some pushing validation services say that their validation is key to achieving quality. Some feel that quality is not even important because the SEC does not require anything beyond the validation you must pass to submit your XBRL filing to the SEC. Others say quality is not important because few investors use the SEC XBRL information.

What constitutes quality?

The ultimate test of quality is whether the SEC XBRL information is usable in an automated manner.  After all, what is the point of spending millions of dollars articulating all this financial information in XBRL if it is useless? Using one report, leveraging the interactive characteristics of XBRL, comparing a company over time, comparing companies. XBRL's utility is the ultimate testament of the quality of SEC XBRL filings.

I have been pushing for quality for quite some time, well before it was even in fashion. I have also spent a significant amount of time trying to figure out exactly what "quality" means when it comes to an SEC XBRL filing. This is what I have learned about quality.

To start, this information is based on empirical evidence. I do eat my own dog food.  This is the latest iteration of what I think quality XBRL looks like, I call it a reference implementation of an SEC XBRL filings. Now BE CAREFUL HERE!!! This is both a work in progress and I consider this an ideal XBRL filing and not necessarily what you would want to file with the SEC.  There are a few things I am trying to determine beyond SEC XBRL. This prototype filing is close to what I would file with the SEC and it can help you figure out how to get where you want to be, but like I said, this is still a work in progress and I am working toward an even higher goal.  That said, the example can be quite useful in seeing what a quality SEC XBRL filing might look like.

So, these are my thoughts on quality which I will try and reference to my reference implementation to endeavor to explain each piece of the quality puzzle.

Defining quality

This is my definition of quality SEC XBRL filing: A business user of the paper or HTML version of the financial information and the XBRL version of the financial information will reach the same conclusions.

Paper, HTML, Word, Excel, PDF and XBRL are all mediums. Different mediums have different characteristics, paper has different characteristics than XBRL. If you are working with a medium, you need to understand the characteristics of that medium.  Most accountants understand how to create a financial statement using the paper, HTML, or Word mediums. They are less skilled at using the XBRL medium. So, quality of an SEC XBRL financial statement involves the proper use of the XBRL medium to articulate the financial information you are communicating. The message should be the same as the message one might glean from reading a paper-based financial report, at a minimum.

Unique characteristic of XBRL: computers can read it

The unique aspect of XBRL is that a computer can read the information. Whereas a human is required to make sure that 100% of the information expressed using the medium of paper, HTML, Excel, Word, PDF or other medium that a computer cannot understand; XBRL is different in that a computer CAN understand the information expressed in the XBRL medium.

Can a computer understand 100% of that information? No way.  That will never happen. But there are many things that a computer can understand.  As such, automated validation of information expressed within XBRL is possible.  That (a) reduces the cost of verifying the information and (b) frees humans to focus on things that a computer cannot handle.

What is even more interesting is that because XBRL is a global standard, your report can be read by someone elses software application.  For example, XBRL Cloud validates every SEC XBRL filing and reports the results. So does XBRL US with their consistency suite. The Firefox XBRL viewer add on can be used to read your report. Other software will likely appear. So, SEC XBRL filings can be consumed by any application which supports the standard, particularly since the SEC XBRL filings are all public information.

Automated verification a computer can perform

The following are the automated verification or validation which XBRL can perform. Humans still play a role in some of these. I will cross reference the type of validation to a set of four categories which I have heard automated validation placed into: correctness, completeness, consistency, and accuracy. I will also provide examples of this validation where I can.

• Edgar filer manual (EFM) validation. This is the only validation required to pass a filing into the SEC. But this is far from what is necessary to tell whether your financial information is correct. There are different interpretations in SEC EFM validation. That is why XBRL Cloud validation is different than SEC XBRL validation required for submission.  Here is the validation results for the reference implementation for the XBRL Cloud EFM validation, provided complements of XBRL Cloud. This covers XBRL syntax validation, SEC specific validation requirements which includes meta data related, some light semantics. (Relates to: correctness, consistency, completeness)
• Information model validation. Tests to be sure you are creating things such as your [Table]s, [Roll Forward]s, roll ups, and hierarchies consistent with the US GAAP Taxonomy. Doing so is specified in the US GAAP Taxonomy Architecture. This helps make sure your extension taxonomies are consistent with the US GAAP Taxonomy and with other SEC XBRL filers. For example, section 4.5 covers how [Table]s are to be created. I don't have a validation report for this, but this shows what the reference implementation taxonomy looks like which follows the US GAAP Taxonomy information model. (Relates to: consistency)
• Extension points and extensibility rules validation. Tests to see if where you are extending the US GAAP Taxonomy is appropriate and if you are creating logical extensions. For example, putting an income statement line item on the balance sheet is illogical. Or, adding a concept at the same level as "Assets" and "Liabilities and Equity" on the balance sheet might not make much sense. (Relates to: consistency)
• Financial integrity validation within a [Table]. Tests to be sure that each [Table], be that [Table] explicitly defined or implied, is "internally consistent and correct". Financial integrity is discussed here.   For example, does your balance sheet have "Assets", "Liabilities and Equity", does your balance sheet balance, and do all the line items add up correctly? That is financial integrity, just like a paper based financial statement. (Relates to: correctness, consistency, completeness, accuracy)
• Financial integrity validation between [Table]s. Tests to be sure that explicit/implicit [Table]s are properly related to one another. For example, the balance sheet ties to the statement of changes in equity.  The cash flow statement cash account needs to tie to the balance sheet.  Disclosure details need to tie the financial statement line items. (Relates to: correctness, consistency, accuracy)
• Internal consistency. When I originally created my reference implementation I did not have access to the XBRL US consistency suite.  I asked that model be run through that suite of tests and the consistency suite pointed out that the reported issued shares was less than the reported authorized shares, which is impossible.  Internal consistency relates to the consistency between reported facts within an XBRL report.
• Computations validation. A type of consistency is whether all the numbers foot, cross cast or otherwise tick and tie.  XBRL calculations offers some help here, for example here is the validation report for the reference implementation which shows that things add up.  But there are things that XBRL calculations cannot test, something else must be used.  For example, [Roll Forwards], dimensional aggregations, and other more complex computations. Need to be verified whether the SEC tests these or not.  This XBRL Formula linkbase is used to test the reference implementation, here are the passing results. (Relates to: accuracy)
• Consistency with prior period filings. The ending balances in your period 1 filing will become the beginning balances in your period 2 filing. Automated validationests to see if the current period filing beginning balances tie to the prior period filing ending balances are possible. (Relates to: correctness, consistency, completeness, accuracy)
• Disclosure checklist validation. Also sometimes referred to as reportability rules, these tests help to make sure your disclosures are complete.  For example, if PPE is reported, you have to include your PPE policies and PPE disclosures. This has less value for a financial which is already complete, when making modifications for new disclosures this can add value. (Relates to: completeness)
• Industry standards validation. Are industry practices being followed if the applicable industry is different than US GAAP for commercial and industrial companies. (Relates to: correctness, consistency, completeness)
• Rendering validation. Does your SEC filing render correctly, using the SEC previewer for SEC filings. Test to see how the XBRL instance renders within the SEC previewer. (Relates to: consistency)
• Comparability validation. Tests to see how well an XBRL filing can be compared to a similar XBRL filing. (Relates to: consistency)
• Key performance indicators validation. Tests for wild fluctuations against internal benchmarks and industry averages.  Much like an auditor's variance analysis. (Relates to: correctness, consistency, accuracy)
• Best practices validation. Other common practices. (Relates to: correctness, consistency, completeness, accuracy)

Should accountants REALLY have to do all this?

Should accountants have to deal with things like XBRL syntax validation and making sure your HTML ampersands are double escaped in your SEC XBRL filings? No.  Computers should do all this behind the scenes and these sorts of things should just happen. But software is not mature enough yet to hide these technical things from accountants.

The marginal value of some of these validations is higher than others currently. That will change as software improves and the marginal effort to employ these validations decreases.

Should you care about all these things?

Do you care if your financial reports tick, tie, cross cast, foot, etc?  Sure you do.  Should you care about your XBRL? Why wouldn't you care?  You are responsible for it.  Besides, look at it this way.  XBRL will eventually be the only thing you will be filings with the SEC at some point and you will be legally liable for your SEC XBRL filing. Do you think you should care about it?

Eventually you will care.  You may as well get the quality where you want it while the SEC limits your legal liability. Why wait until you are liable to figure out how to master the medium you will likely be using in the future.

Longer term view

The longer term view you take, the more it makes sense to deal with the quality of your XBRL based financial report sooner rather than later.  We are paving the last mile of finance, after all.

Did I miss any opportunities to automate validation of a financial report? If so, please let me know.

Consider this statement:

"In the first hundred years of active life, it has been described as a menace and a blessing, a blight and a godsend, as a savior of our countryside and cities, and as their curse, as socially divisive and the greatest social leveler. It has been worshipped and reviled, celebrated and scorned."

No, the quote is not talking about XBRL, it is talking about the automobile. Here is another quote from an article which talks about the history of the automobile:

And as you would expect, the politicians of the day displayed a total lack of vision.

I think that XBRL was lucky in that we happened to find many visionaries such as leaders within the Association of Dutch Water Boards, the U.S. Federal Deposit Insurance Corporation, the Committee of European Banking Supervisors, the U.S. Securities and Exchange Commission, the Australian SBR Project, the National Tax Agency of Japan, the Tokyo Stock Exchange, the Japan Financial Services Agency, the MIX Market and others to consider what XBRL might offer.

This Machiavelli quote has always been a favorite of mine:

"It must be remembered that there is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than a new system. For the initiator has the enmity of all who would profit by the preservation of the old institution and merely lukewarm defenders in those who gain by the new ones. "
— Niccolò Machiavelli

Consider this quote by Wilbur Wright:

"I confess that in 1901, I said to my brother Orville that man would not fly for 50 years.... Ever since, I have distrusted myself and avoided all predictions." —Wilbur Wright, 1908

One of my favorite pieces which helps one to tune their perspective is an article which appeared in The Futurist (July-August 1995), Peering into the Future with Wilbur and Orville Wright, On the brink of a new age, two inventors debate their innovation's potential, by Malcolm Wells. Here is part of Wilbur and Orville's discussion:

WILBUR

Orville, when you get that strut repaired, I want to talk to you about the commercial value of these machines. What I mean to say is, aside from putting on demonstrations at fairgrounds, do you really think there's any money to be made from flying?

ORVILLE

Are you serious? Airplanes are going to carry millions of passengers someday. And thousands of wagonloads of freight, too.

WILBUR

Come on, now, Orville, talk sense. Even a flying machine 10 times bigger than ours couldn't carry more than 20 people. And I doubt that they'd even be willing to sit out there. Imagine women and children traveling that way.

ORVILLE

Not on the wings, Wilbur; inside. There'll be enclosed cabins with soft seats and carpet on the floor.

WILBUR

And electric lights, too, I suppose. You really are a crackpot.

read more...

Will the last mile of finance get a face lift? Every day it seems that more and more evidence that some pretty big changes might be coming. No one knows for sure.  Maybe there is nothing to all this. But then again, maybe there is.

You know, it is really amazing what one can find on the Web. How did we ever survive without it?

I was looking for something and stumbled upon a study written by Nico Bouwkamp, Understanding Technological Transitions in History and Lessons Learned for a Hydrogen-Refueling Infrastructure.

The study looks at the dynamics of the transition from steam to the internal combustion engine and the transition from fixed line to wireless telephones, looking for clues which those pushing hydrogen as a fuel source.

There is a section of the report, Dynamics of the Innovation Process, which summarizes the factors that influence the rate of adoption. The author says in part,

The rate of adoption is set by the characteristics of an innovation, which are not only objective measures but also reflect the perceptions of potential adopters in the market.
Diffusion research shows that there are five main characteristics that dictate the rate of adoption and which all have to do with how potential adopters perceive the market.

Here are those five characteristics:

• Relative advantage is the degree to which an individual perceives the innovation as superior over the existing technology it replaces.
• Compatibility stands for the degree to which the innovation fits existing values, experiences and needs.
• Complexity is the level to which an innovation is perceived as difficult to understand and use.
• Trialability is the extent to which an innovation can be experimented with before it is adopted.
• Observability is the degree to which the adoption and advantages of an innovation are visible for others than the potential adopter.

Perhaps there are lessons those trying to help XBRL achieve critical mass might learn from how other technologies achieved that state.