BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting. This is my brain storming platform. This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.
Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.
Entries from December 16, 2012 - December 22, 2012
Integrated Reporting
Integrated reporting seems to be gaining more and more traction, particularly in Europe. One major proponent of integrated reporting is the International Integrated Reporting Council (IIRC). The IIRC states their purpose on their web site as:
The International Integrated Reporting Council (IIRC) is a global coalition of regulators, investors, companies, standard setters, the accounting profession and NGOs. Together, this coalition shares the view that communication about businesses’ value creation should be the next step in the evolution of corporate reporting.
As I understand it, the IIRC is in the process of getting an XBRL taxonomy acknowledged by XBRL International. It seems that the XBRL taxonomy has to do with the "integrated scorecard".
Here is additional information related to integrated reporting:
- Executive overview. This overview which is about 18 pages long explains integrated reporting very well.
- Integrated Reporting: The Integrated Scoreboard (IS-FESG) and its XBRL Taxonomy. This 128 page document provides additional details and explains the XBRL taxonomy being created.
- Integrated Reporting Taxonomy: Extending IFRS & COREP. This is a presentation made at XBRL Europe recently.




Analysis of Dow 30 and Fortune 100 for Core Financial Integrity
In a prior post I covered my analysis of 8289 SEC XBRL financial filings for core financial integrity.
This post is an analysis of the Dow 30 and Fortune 100 for the same core financial integrity. You can download the raw data here in Excel.
The summary of the analysis is this: (Note that the core financial integrity relates to the existence of concepts for: assets, liabilities and equity, equity, net cash flow, and net income (loss); I also checked to see if the balance sheets balance).
- Dow. Of the 150 total possible data points (30 entities x 5 data points); 149 were discernible, only 1 was not. All the balance sheets balanced. The one data point for which an extension concept was created was net cash flow for General Electric. It is likely the case that General Electric chose to create an extension concept because of an issue related to discontinued operations in the definition of net cash flow; so they created an extension concept. (This issue was corrected in the 2013 taxonomy). However, there were two other DOW companies who were in the same situation as General electric (i.e. had cash flows from discontinued operations) and they made the choice to use the existing concept to express net cash flow. Further, of the total of 8289 reporting entities analyzed (the complete set), 724 (or 96%) of a total of 760 filers where also in the same situation and chose NOT to create an extension concept. The remaining 36 (which is 4%) chose to create an extension concept as General Electric did. So General Electric is not incorrect in what they did, but it seems that they would not have been incorrect to follow the path of the 2 other DOW companies and the 724 who chose to use the existing US GAAP Taxonomy concept.
- Fortune 100. Of the 500 possible data points (100 entities x 5 data points); 494 were discernible, only 6 were not. All the balance sheets balanced. Like the DOW, there were similar issues with net cash flow extension concepts (4 filers created extensions). Another issue related to extending "Liabilities and Equity" and an issue related to extending Equity. You can take a look at the Excel comments I provided. See if you think the modeling of these concepts was appropriate.
Per what I understand about the 2013 US GAAP Taxonomy (which was just released today by the FASB); there is now no reason for any of the issues related to the DOW or Fortune 100 to be issues in the future. The issues relating to the lack of clarity as to how equity and liabilities and equity when a filer has member equity are now clear in the 2013 taxonomy. Same with the definition of net cash flow, that has been cleaned up. As such, these 5 data points for the DOW and Fortune 100 should all be resolved and therefore all the DOW and Fortune 100 filings should have zero issues with regard to these five core financial integrity checks which I do.
We shall see what happens in February.




XBRL Linkbases are Semantic Networks. Why Should You Care?
I remember back in, oh I think it was 2001 or 2002 when a few of the technical people introduced the linkbase to XBRL. Most people did not "get it" back then. I did not "get it" at first. But, with the help of some really good technical people, I eventually understood what a linkbase was, why it was important, and why we needed to use them in XBRL.
A linkbase is basically the way XBRL expresses a semantic network. A semantic network is an artificial intelligence technology.
I am not going to go into explaining what a semantic network is, I have a different point. My point is that if you are a technical person or a business person and you don't understand the meaning of terms such as network, graph, syntax, semantics, RDF, OWL, SKOS, metadata; then you are at a significant disadvantage.
Why do I say this?
The world of financial reporting is about to change in a very big way. It is already changing. If you don't understand where financial reporting is going then you likely don't know how to get there. Let me give you one specific example.
In a prior post, I mentioned Risk Modeling at the SEC: The Accounting Quality Model. In that speech; Craig M. Lewis, Chief Economist and Director, Division of Risk, Strategy, and Financial Innovation at the SEC; described some things the SEC are doing. Do you believe that what the SEC will do will work and to what extent? Do you know how the SEC is going to build what they are proposing? Do you understand what to do to build counter measures so you don't unnecessarily stick out on the SEC radar?
There will be many layers to this notion of The Accounting Quality Model. The first layer is basic financial semantics. If your financial report does not have an identifiable balance sheet, if that balance sheet does not provide expected concepts such as "Assets" and "Liabilities and Equity" and "Equity", if your balance sheet does not balance, if your "Assets" and "Liabilities and Equity" don't foot; you will be flagged. Why?
Accurate processing of the subsequent layers is impossible unless the first layer processing is successful. The more sophisticated processing which the SEC seems to be envisioning by that speech cannot be achieved unless all the first layer ducks are all in a row. Now, one could take the view, "Hey, let's just hinder the SEC's attempts at higher level processing by making sure we have issues which block their ability to process our information." Some people will likely take this approach, but that will not last long.
But forget about the SEC and SEC XBRL financial filings; I am only using that as an example of what is possible.
What if your organization could apply similar approaches to your internal systems? What if your organization had an internal Accounting Quality Model-type or some other semantic model that you used to evaluate all sorts of things similar to how the SEC is going to use all that XBRL information?
Welcome to knowledge management!
If you don't understand what a graph is, what a network is, what metadata is, how RDF inference engines work, why semantics are more important than syntax; then it is highly unlikely that you "get" what I am saying here. Thus the need to understand.
If you don't understand these terms, if you don't understand that XBRL linkbases are semantic networks, then it is highly unlikely that you are a business person who is pushing for the correct software applications or that you are a software developer who is architecting or otherwise developing the correct software.
If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can communicate appropriately and convince other business people where things are going.
If you are a business person and you don't understand those sorts of terms, then it is highly unlikely that you can articulate to a software developer what software they should be building.
A business user needs to understand these sorts of things in order to understand what metadata they need, why they need it, and how to properly express that metadata.
A technical person who does not understand what a graph is won't realize that when most people create XML, the generally create trees which are more limited than graphs.
I could go on and on but if you will get my point, you probably already have.
Folks, syntax does not matter (or maybe it is better to say that it is only one thing that matters), it is the semantics that matter. XBRL is a technical syntax. It is just a format that you output to when you need the things XBRL has to offer. And XBRL has a lot to offer. It's status as a global standard is very important. All those standard taxonomies for financial reporting are important. But the biggest benefit XBRL offers is its business rules engine. RDF/OWL does not have this functionality. XML alone does not have it either. XBRL alone also has its disadvantages, for example limited functionality for expressing metadata.
RDF/OWL has its advantages, such as its inference engines. Anyone who thinks that they don't need to use XBRL or RDF/OWL because they already use XML does not understand the differences between those three technical syntaxes.
Semantics is where all the action is. That is what enables the sort of thing the SEC envisions and describes in that speech. You can have that sort of sophisticated processing also, internally, in your organization. This type of processing is by no means limited to external financial reports.
Interested in RDF? This Introduction to RDF provided by IBM is a good place to start. This RDF Tutorial is also quite helpful.




Repeat after me: "There is no syntax"
This article; Thinking XML: Basic XML and RDF techniques for knowledge management, Part 7; helps to make the point that syntax does not matter, it is all about the semantics.
These same ideas apply to XBRL.
Risk Modeling at the SEC: The Accounting Quality Model
Craig M. Lewis, Chief Economist and Director, Division of Risk, Strategy, and Financial Innovation
U.S. Securities & Exchange Commission, describes ways the SEC will use all that SEC XBRL financial information in his speech, Risk Modeling at the SEC: The Accounting Quality Model, to the FEI Committee on Finance and Information Technology.
There are two particular pieces of this speech which I would like to highlight. First, this statement about The Accounting Quality Model:
While we have several projects in development, we are particularly excited about what we call an “Accounting Quality Model” (AQM). This model is being designed to provide a set of quantitative analytics that could be used across the SEC to assess the degree to which registrants’ financial statements appear anomalous.
Anomalous. Deviating from what is standard, normal, or expected. Sticking out from the pack. Seems like a great way to stick out of the pack is modeling things incorrectly where most SEC filers do model thing correctly (see this analysis for the 271 of 8289 who stick out to me and my dinky little Microsoft Access database application).
To provide a little bit of an example of what the Accounting Quality Model is and how it would be used, Mr. Lewis provides the following example related to how analysis of discretionary accruals and non-discretionary accruals can help detect earnings management:
Second, we need to understand generally where it is possible to discern the effects of earnings management. Typically, they manifest in the discretionary choices that management can make under GAAP when reporting its financials. In accounting jargon, total accruals are the difference between free cash flows and income before extraordinary items. It is the difference between what accountants recognize as revenue and expenses and the actual cash flows available to shareholders. We can decompose total accruals into two broad categories: discretionary accruals and non-discretionary accruals. Non-discretionary accruals are accounting adjustments made in strict adherence to GAAP and are relatively objective. Discretionary accruals however, may be subjective and require the preparer to exercise considerable accounting judgment. As is generally recognized, this influence over the potential accrual values can allow for opportunities to, for example, smooth income and therefore, manage earnings.
What a great opportunity for filing agents and XBRL software vendors: validation/verification processes which make sure an SEC filing does not stick out.
Measures, counter-measures. The SEC will likely be hammering all that XBRL-based information. Clearly if the SEC processes cannot make heads or tails out of the information they will request a filer to correct their filing. That will improve information quality for everyone, making all that information usable by automated processes.



