BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. It is for innovators and early adopters who are ushering in a new era of digital financial reporting.
Much of the information contained in this blog is summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the three documents on this digital financial reporting page.
XBRL-US announced a new product yesterday, the US GAAP Pension Analyzer. This tool, made available for free to public company reporting managers, is announced in this press release, XBRL US GAAP Pension Analyzer Identifies Significant Errors in XBRL SEC Filings for Q1 2014.
This tool is a sign of things to come. This is what I mean.
First, the pension disclosure(s) is only one of many disclosures made within a financial report. Here is a prototype list of disclosures required by US GAAP. Why couldn't disclosure analyzers be created for every disclosure? If you read the press release, it describes the US GAAP Pension Analyzer as performing the following:
The rules check each concept and combination of concepts to identify incorrect sign (negative or positive), invalid axis/member and axis/line item combinations, problems in roll forwards, missing values and incorrect dates, among other potential problems.
Second, while XBRL US started at one end of the problem, I started at the other end. What I mean is XBRL US has their consistency suite which checks an SEC XBRL financial filing. Now they have their US GAAP Pension Analyzer. Is that everything necessary to validate an SEC XBRL financial filing to be sure that filing is correct? Certainly not and they are not holding these validation steps out as being comprehensive.
Now I started on the other end. I have my seven minimum criteria which I use to verify the usability, and therefore the fundamental correctness, of an SEC XBRL financial filing. Are my criteria sufficient to be sure that everything about an SEC XBRL financial filing is correct? No, I make it clear that they are likewise not comprehensive.
You need both what I created, which is a framework and high-level criteria, plus what XBRL US created which is more lower-level detailed criteria, plus you need those "analyzers" for all the other disclosures which might exist in an SEC XBRL financial filing. It is the combination of all these things which is significantly closer to what is truly necessary to get all the details of these digital financial reports correct so that the information within the reports will be usable. You likely need even more.
Third, I cannot speak to precisely what the US GAAP Pension Analizer does, but I can safely say that it goes far beyond XBRL technical syntax validation. Go back and read the quote above. "Problems in roll forwards" has nothing to do with syntax, that is semantics (meaning). "Incorrect dates", that is meaning. "Invalid axis/member combinations", meaning. There is a lot of US GAAP related stuff which can be verified because of the structured nature of the information reported in an SEC XBRL financial filing. That has tremendous value to external reporting managers. Detecting accounting anomalies will start to show the power of XBRL-based digital financial reports over traditional financial reports. When this happens, external reporting managers of not only public companies will value XBRL-based digital financial reports. Private companies will also, whether they press the "save as XBRL" button in the application or not.
Fourth, back in the 1970's the way automobiles and other things were made change dramatically because of two things: a guy named Deming and Toyota. Toyota adopted Deming's principles, I learned them as "World Class Manufacturing Techniques", and changed the auto industry forever. The old way was: build, find mistakes, fix mistakes. The new way was: fix processes, build, (i.e. don't make mistakes).
The point is this: why would you want to build your financial report incorrectly and then validate that report after-the-fact and correct the report for errors detected? Why not use the business rules to not let you create the mistake in the first place?
It is the integration of the sorts of validation offered by things like the US GAAP Pension Analyzer into the financial report creation workflow which will change accounting work practices. Just as a CAD (computer aided design) program understands the relation between a window and a wall; a digital financial reporting software application will understand the relation between assets, liabilities and equity, and a balance sheet. Does your current financial report creation software understand these sorts of relations?
That is why the US GAAP Pension Analyzer is a sign of things to come.
TechTarget published an article, Digital financial reporting harnesses computers for speed, accuracy.
The key to making XBRL extensibility work correctly is the notion of "controlled flexibility". Having those extending XBRL-based taxonomies do so randomly can never work. Further, if one can make XBRL's extensibility serve you it seems that an entirely new class of software application is possible.
This is what I mean. First off it is important to understand the spectrum of flexibility. There are two extremes:
- Form: At one end of the spectrum you have a form which is an example of 100% control. With a form someone specifying some information they want to collect can "specify blanks" and then the user basically "fills in the blanks". Seems pretty straight forward. Now, if you think about this a little more you start to realize that you have another layer of control even with a form. For example, if you have a box that specifies an answer and you mean for the person filling out the form to enter "YES" or "NO"; but you don't control that appropriately and some people enter "MAYBE" then your data fields might be specified and users must fill in each field, but you will have data errors because what the user enters is not controlled appropriately. That is what something like XML Schema Data Types is all about, restricting what someone can enter into a form. Going further, if the form says the user needs to supply the value for "Assets" and also the value for "Liabilities and equity" and those two values must agree, but the form does not enforce that then you can get errors in your data. Something like XML Schema Data Types cannot enforce even that type of mathematical computation. So the reality is that even with a form where you "fill in the blanks" you still have to do other work to make sure that the quality of the information put into that form is intact.
- Freeform: At the other end of the spectrum you have "freeform". The definition of freeform provided by Google is "not conforming to a regular or formal structure or shape." An example of freeform is creating a Microsoft Word document such as a financial report. You have all sorts of issues controlling what a user does (i.e. the user has a lot of flexibility). From the perspective of the creator, they have a lot of flexibility to "fill out the form" however they see fit because there is basically little constraining what they create. From the perspective of a consumer of that information; while the information is richer because of the flexibly the user has in providing the information (i.e. they are not forced to fill in a form), using that information poses challenges because of the lack of structure.
But what if there were another way? What if there was something in between "form" and "freeform"? Would all information fit into that middle category? No. Are there advantages of having a middle category? I propose that there is.
Let me repeat the definition of freeform: not conforming to a regular or formal structure or shape.
First off, does something like XBRL have a "regular or formal shape"? Most people would say no, but they would be incorrect. XBRL does have a formal shape. If you look at the XBRL Abstract Model 2.0 you can see that formal shape. If you tried to map that XBRL Abstract Model 2.0 to things that exist in the real world you can also see that shape. I mapped the XBRL Abstract Model 2.0 to my model of a financial report expressed in the Financial Report Semantics and Dynamics Theory.
And I went even a step further. I tested 100% of SEC XBRL financial filings (all 10-Ks) to see if they fit into that model. Guess what: 99.99% of all representation or model structures and 95.8% of all such XBRL-based filings fit into that structure.
And so, XBRL-based business reports "fit" into a regular, formal structure/shape. But is that enough to capture high quality information? Well, first understand that XBRL uses XML Schema Data Types to enforce field level data quality. XBRL uses XML Schema Data Types. You can use any of the data type restrictions to provide things like enumerated lists of values such as "YES" or "NO", very powerful. XBRL also uses XBRL calculations and the more powerful XBRL Formulas to enforce mathematical computations. So those two pieces mentioned above are covered.
Is that enough? No.
Proof that that is not enough is the quality of today's SEC XBRL financial filings themselves. They don't have the quality they need. So what is missing? Well, here are specific things which are missing:
- Extension points: Where an XBRL taxonomy can and cannot be extended is not communicated in either the US GAAP XBRL Taxonomy or SEC Edgar Filer Manual (EFM) rules. For example, financial statements have "Assets" and they have "Liabilities and equity". Should SEC filers be allowed to create an extension at this level in the US GAAP XBRL Taxonomy, creating another category of financial information? Probably not. And they generally don't because the financial reporting rules are pretty clear that you cannot. But, a mechanism which controls where an XBRL taxonomy can be extended is not provided. But what if such a mechanism to control extension points was provided?
- Extension rules: How to properly extend the US GAAP XBRL Taxonomy is not controlled nearly enough. An example of a seemingly good control mechanism can be a good example of the possibilities. First of, suppose that every report element in the US GAAP XBRL Taxonomy were categorized into one of the 10 elements of a financial statement defined by the FASB in the US GAAP Conceptual framework: Assets, Liabilities, Equity, Revenues, Expenses, etc. Next, when an extension is created, the filer creating the extension must SPECIFICALLY associate that extension with one of those 10 core elements of a financial report? That is an example of control. This can be achieved using XBRL definition relations. Now, that list is not sufficient in my view, I use those 10 elements of a financial statement to make a point. Controlling extension rules is possible.
- Unchangeable concept framework: Imagine that a report had some sort of a "skeleton" or framework which every report followed. The fundamental accounting concepts is that framework for financial reports. Testing of SEC XBRL financial filings shows that financial reports follow this framework 98% of the time. It makes no sense for a filer to change the category of a concept. For example, if the US GAAP XBRL Taxonomy defined a concept to be an "Asset" and a filers used that concept on the cash flow statement, that would make no sense. It would likewise make no sense for a filer to change the relations between two of these concept categories. For example, "Assets = Current Assets + Noncurrent Assets"; why would a filer need to change that relation? Now a filer might not have noncurrent assets because they provide an unclassified balance sheet. That does not break the rule, that rule would not apply to them. If a filer did have a classified balance sheet but did not report noncurrrent assets, that would likewise not break this rule because noncurrent assets can always be imputed by: Noncurrent assets = Assets - Current assets. (If a filer does provide a classified balance sheet, they will ALWAYS provide assets and they will ALWAYS provide current assets. And so this set of unchangeable concepts and unchangeable relations between concepts controls extensibility by making sure SEC filers representing their information don't break that framework.
- Leverage common relation patterns: The elements which make up the "regular or formal structure or shape" have common patterns. These common patterns can be leveraged for many, many purposes. One of these purposes is managing extensibility. This is what I mean. First, there are two primary categories of relation patterns. The first are "member arrangement patterns" or "whole-part" type relations. The second are concept arrangement patterns: roll up, roll forward, adjustment, variance, hierarchy, etc. (For the back of your mind, another use of these common relation patterns is rendering of information in human-readable form.) Again, controlling extensions can be achieve by specifying the patterns that extended information fits into. For example, it makes little sense to have a roll up which has no total or two totals.
It might be the case that I am missing something, but I am pretty certain of two things: (1) If a system is not controlling the things mentioned above problems will occur which relate to how different creators of information extend an XBRL taxonomy; (2) if the things above are specified appropriately, it will control the flexibility offered to users of the system to employ and that controlled flexibility offers very useful between what is offered by a "form" and what is offered by "freeform" information gathering systems.
While I am providing SEC XBRL financial filings as an example of how controlled flexibility can make extensibility work for financial reporting, what I am showing is more generally useful. Perhaps a taxonomy has different extension points, different extensibility rules, a different unchangeable concept framework, and different common relations patterns; it is the creation and management of these which will make extensibility work for other business reporting domains.
Finally, the notion of "extension points", "extension rules" and "patterns" are not my idea. These ideas were origionally discussed as a group of us created the US GAAP XBRL Taxonomy Architecture. That document talks about the notion of "diciplined extensions".
For more information see this blog post.
Don't understand Big Data? Here is a fantastic timeline which explains the history of big data. A good way to go through this is to start at the very beginning of the paging thing in the center of your screen and check out the pieces you like. The slides link to source information which you can drilldown into as you might desire.
Yesterday I posted this. I adjusted this creating the following significant updates.
- I added presentation relations for everything.
- I created one schema which combines everything together, see "All Combined" below.
- I changed the cycles attribute on the arcroles I am providing from "none" to "undirected". I was getting some cycle errors; the cycles are OK where I have them.
- I updated the Financial Report Ontology a bit, adjusting and adding some things.
Here are the most current versions: (If you are not technical but interested in this, you want this HTML.)
- All combined: XSD | HTML | XML
- Financial Report Ontology (fro): XSD | HTML | XML
- Topics: XSD
- Disclosures: XSD
- Key ratios: XSD
- Fundamental accounting concepts (fac): XSD
- Fundamental accounting concept rules (XBRL Calculations): XSD
- Fundamental accounting concept rules (XBRL Formula): XBRL Formula
- Map US GAAP XBRL Taxonomy to fundamental accounting concepts: XBRL Definitions
- Arcroles (which provide semantics): XSD
What I want to do next is decouple the schemas and linkbases, making this more modular. I have documentation and references for a lot of stuff, want to provide that and references.
Most of this information is in a Microsoft Access database. All the XBRL is generated via software, no XBRL taxonomy editor necessary.