Digital Financial Reporting

If you look within SEC XBRL filings you can see that their creators still have confusion about what exactly an [Axis] does.

As explained in on the SEC XBRL Financial Filing Glossary and Logical Model, an axis is:

A means of providing information about the characteristics of a fact reported within a business report.

Nothing scary or technical about that explanation and that is all an axis really is.  Now, some people refer to an axis or [Axis] as seen in XBRL taxonomies using other terms which can make them seem confusing.  Some common terms are: dimension as used in the XBRL Dimensions specification, aspect as used in the XBRL Formulas specification, measure as used in the multidimensional model and in the Business Reporting Logical Model, to name most.  I will use [Axis] as used in the US GAAP Taxonomy and in SEC XBRL financial filings.

But what exactly does an [Axis] do?  Walking through this will make exactly what an [Axis].  Consider the following two facts:

The two facts have values.  What do those values mean? Well, you don't really know, you need more information. So, you add an [Axis] to provide additional characteristics. Now, consider this next screen shot:

So above, I added the Concept [Axis] and provided values for each fact to both explain and differentiate the two fact values.  The value of an [Axis] is called a [Member]. We still don't have quite all of the information we need yet, this next screen show will make that clear: 

So now we are getting closer and closer to something which is becoming useful. Knowing the period and the entity reporting the fact, in the case of SEC XBRL financial filings the CIK number, is commonly desired.  In fact, it is so common that XBRL requires these three [Axis] on every single fact: the concept, the period, and the reporting entity.

But, do we have enough information?  Well, that depends.  Take a look at the next screen shot and we will bring up a few more things about an [Axis]. 

XBRL provides the ability to add even more, in fact any number of, [Axis]. Here we added the business segment [Axis] and indicated that our fact values both relate to the the consolidated entity.

When do you know if you have enough [Axis]? Well, that is dependent on whether you have communicated all the business information you are required to communicate. A fact is comprised of a value and all the characteristics which describe that value. There is nothing technical about what an [Axis] does so don't let a poor software implementation or some consultant who speaks using $150 an hour jargon tell you any differently. Yes, it really is that simple and straight forward.

Rather than complicating this explanation with more details, I will call this good.  You can find more definitions of the report elementswhich make up an SEC XBRL financial filing in that same glossary.

I will go into some of the more common mistakes I am seeing in SEC XBRL financial filings later.

XBRL Global Ledger Distilled, a book by Jia XinQuan, was recently published by the Economic Science Press. The book is in Chinese and I don't know if it will be translated into other languages.

Seven years ago I could not tell you the difference between syntax and semantics. I now understand the difference thanks to countless conversations, lots of reading, and years of trying to figure out how to make XBRL work to serve my needs.

If you are an accountant or an auditor why should you care about semantics? The reason is because the capabilities which XBRL has to express business semantics using a global standard technical syntax, the existence of business standards such as International Financial Reporting Standards (IFRS) and US Generally Accepted Accounting Principles (US GAAP), and the adoption of XBRL by the US SEC and other regulators around the world will change financial reporting.

You likely don't believe me if you don't understand the difference between syntax and semantics or you don't understand that it takes three things to achieve business system interoperability: technical interoperability (i.e. syntax), semantic interoperability, and process interoperability.  If you do understand the difference between syntax and semantics, you might not believe me because creating an SEC XBRL filing is so utterly expensive and challenging that it is hard for you to believe that XBRL would ever provide any real value. This is justifiable. Or, you may find it hard to believe that XBRL could be useful because the expensive to create SEC XBRL filings are not all that useful for analysis and certainly don't yet live up to the SEC's promise that XBRL will improve transparency and the general utility of all that public company information they make available via their EDGAR system. If none of those reasons to not believe me are good enough, you can always fall back on the rational that I, being the so called "father of XBRL" is nothing but an XBRL zealot whose opinions are biased. Granted, the appearance of independence is just as bad as an actual lack of independence.

There are plenty of reasons to believe that XBRL is not capable of delivering any real utility.  And I could provide all the evidence in the world that a business user could, in fact, make use of XBRL and a new digital model-based paradigm of financial reporting will emerge, disrupting current financial reporting practices not just in the US, but globally. What if all IBM, Oracle, and SAP are right and the last mile of finance will change? What if improved collaboration and workflow tools were created.

What if:

• SEC no longer requires HTML, all filings are to be in the XBRL format: Already, many regulators require only XBRL to be submitted including the Federal Deposit Insurance Corporation and the Bank of Belgium. Why does it make sense to report both XBRL and HTML and have to make sure both versions of the information agree?
• Public companies report to financial institutions using XBRL: What if reporting using XBRL could be make easier, so easy that the cost drops significantly and software leverages semantics and guides business users in the process of creating financial reports and the process becomes better, faster, and cheaper?
• Federal, state, and local governments around the world adopt model-based digital financial reporting:  Already two countries, the Netherlands and Australia, have made major investments in what has become called standardized business reporting (SBR). Their goal is to reduce the cost for both those who report and government.
• Model-based digital reporting is adopted for not only financial reporting use cases where it is cutting its teeth; but also for general business reporting use cases: There really is no difference between financial information and non-financial information, both are numbers and text.

If you have been paying attention to my blog you will see that I have not been very shy about commenting on how well the XBRL which is being used for SEC XBRL based financial reporting is working. I have invested all that effort into looking at these SEC XBRL financial filings because I realize that the SEC is the toughest use case which XBRL will ever encounter: the reports are big and complex and extension is allowed.  I have used this opportunity to both figure out if XBRL can work and how to use XBRL correctly. All that I have come up with is encapsulated in the phrase: semantic model-based structured authoring.

I can tell you based on my assessment of SEC XBRL financial filings that not only can semantic model-based structured authoring of financial reports work, but it will displace the current practices of using unstructured authoring tools and systems and that there are many software vendors and others placing bets on this approach.

It is my assessment as a certified public accountant with 29 years of experience relating to financial reporting and business reporting that, if implemented correctly, XBRL can make things better, faster, and cheaper.  I thought this back in 1998 when I brought this idea to the American Institute of Certified Public Accountants (AICPA), I began to doubt it when we actually struggled to create what became XBRL because of all the challenges, but because of the evidence provided by the SEC's implementation of XBRL I can see not only that XBRL can work, but also how to make it work.

Sticking my neck out, I will go as far as predicting that the first three bullet points above will come to pass within 10 years, maybe sooner.  The fourth bullet point is still up in the air, the best hope that I see is for a de facto standard approach to implementing XBRL based on the SEC's implementation. Agreeing on a de facto standard is likely the path of least resistance as I see it.

The biggest benefit that XBRL provides is not the exchange or analysis of the information provided.  I know of at least three software products which were taking a structured approach to creating financial information before XBRL even existed.  Structured authoring has its advantages. Add to that the US GAAP and IFRS XBRL taxonomies, structured authoring becomes even more compelling. Add to that the investment made by software vendors and the successful interoperability which has existed since about 2003 at the XBRL technical syntax level. Add to that the core financial reporting semantics which the SEC XBRL financial filings show. Add to that the investment software vendors have made in SEC XBRL financial filings creation and the competition between software vendors in the market.

Call me an XBRL zealot if you like...but what if I am right? What if the predictions in my first three bullet points above do come to pass.  What will that mean for financial reporting?

What do you think?  Before you venture a guess, please take the time to understand the fundamental differences between syntax and semantics.

This document summarizes my evidence that XBRL can be made to work, but is not necessarily the appropriate technical implementation approach: Modeling Business Information Using XBRL. (Or get to it via this location on my blog.)