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.
One approach to understanding something that I use is to try and create a spectrum of all possible options. In applying this to a situation that I have been involved with for 15 years, I think I realized something. While people use the term "standard" and think they understand the term, it seems as though a lot of people are misinterpreting the term. Let me explain.
First, we need to be sure we are on the same page when it comes to certain specific terms. These are the terms I am using with definitions provided by Google and the Merriam-Webster dictionary. The terms are broken into sets with go together: (bear with me here)
Term set 1:
- Standard: used or accepted as normal or average (Google); something established by authority, custom, or general consent as a model or example (MW)
- Arbitrary: based on random choice or personal whim, rather than any reason or system (Google); depending on individual discretion (as of a judge) and not fixed by law (MW)
Term set 2:
- Nuance: a subtle difference in or shade of meaning, expression, or sound (Google); a subtle distinction or variation (MW)
- Subtle: so delicate or precise as to be difficult to analyze or describe (Google); hard to notice or see : not obvious (MW)
- Negligible: so small or unimportant as to be not worth considering; insignificant (Google); so small or unimportant or of so little consequence as to warrant little or no attention (MW)
Term set 3:
- Objective: not influenced by personal feelings or opinions in considering and representing facts (Google); based on facts rather than feelings or opinions : not influenced by feelings (MW)
- Subjective: based on or influenced by personal feelings, tastes, or opinions (Google); based on feelings or opinions rather than facts; relating to the way a person experiences things in his or her own mind (MW)
- Judgment: the ability to make considered decisions or come to sensible conclusions (Google); an opinion or decision that is based on careful thought (MW)
Term set 4:
- Policy: a course or principle of action adopted or proposed by a government, party, business, or individual (Google); definite course or method of action selected from among alternatives and in light of given conditions to guide and determine present and future decisions (MW)
- Requirement: a thing that is needed or wanted (Google); something that is needed or that must be done (MW)
- Choice: an act of selecting or making a decision when faced with two or more possibilities (Google); the act of choosing : the act of picking or deciding between two or more possibilities (MW)
- Option: a thing that is or may be chosen (Google); the opportunity or ability to choose something or to choose between two or more things (MW)
So this is my argument, given the terms as used above:
The purpose of a standard is to create some accepted "norm". As I explained in a prior blog post, there are certain advantages to creating and agreeing on standards.
To create a shared reality to achieve a this specific purpose: To arrive at a shared, common enough view of "true and fair representation of financial information" such that most of our working purposes, so that reality does appear to be objective and stable. So that you can query financial information reliably, predictably, repeatedly, safely.
By way of contrast, a standard is different than arbitrary. To arrive at standard, personal preference, individual preference, individual discretion, convenience, randomness and such are given up to arrive at some greater good.
Now, what is given up? Things that are negligible are given up. Things that are subjective are given up. It should NOT BE THE CASE that important nuances, subtleties, or things that are objective be given up. If the nuances, subtleties and other things which are in fact objective are not considered, the system becomes too simplistic and such a poor representation of reality that the system is not useful.
How can you tell the difference between something that is negligible and something that is an important nuance, subtlety, or something else which is objective? That is the nature of the agreement by which one arrives at some standard. To make this distinction between what is important and what is not important requires two things: professional judgment and an understanding of the pros and cons of the decision.
In another blog post I elaborated on why this process can be difficult. Getting computers to do things is not that tough for IT professionals. Look at all the things computers do for us today. Consider accounting systems. Sure beats keeping the books using paper journals and ledgers. Accountants provided a lot of input over the years to get the accounting systems to work as they need the accounting systems to work.
Now we are taking things up a notch. Now IT professionals can help business professionals create financial statements in more efficient and effective ways. The question is not whether this is possible or whether it will be done. It will be done.
The question is, will that software be more standard and therefore do more for accountants and cost less; or will it be less standard and cost more. Will the software be more standard and therefore less ambigous and therefore easier to use; or will it be less standard, have more options, and therefore be harder to use.
Financial reports have certain requirements? Of course. Do accountants have choices? Sure they do. US GAAP has options. Once certain choices are made by a company, then a policy is set as to how things are to be done.
So, whether disclosures will be digitized is not what should be at the forefront of a professional accountants mind. What should be on their mind is whether it will be expensive or will it be less expensive. The more standard things are, the less they will cost and the easier they can be to use. The more arbitrary they are, the more they will cost and the harder they will be to use. Another term for arbitrary is proprietary. Software vendors love proprietary. Proprietary creates software lock in which is good for software vendors, but bad for software buyers.
None of this has to do with dumbing down financial reports, taking away important areas of flexibility which enable reporting entities to communicate nuances, important subtle distinctions or other objective considerations. In fact, dumbing down financial reporting needs to be avoided at all costs.
But to the extent negligible and therefore unimportant individual personal preferences can be eliminated, financial reporting can be made less costly, more timely, and higher quality by leveraging machines to automate certain specific tasks. Not all tasks. Just the tasks which make sense for computers to perform.
In my view, this is an appropriate high-level architecture to build the underlying "engines" or "processors" which make digital business reporting and digital financial reporting work as business users need it to work:
So let me explain why I think this and what the pieces are. First, if you follow Grady Booch's five common characteristics to all complex systems, you break the complex pieces into smaller less complex pieces. Second, you expose business users to things business users understand.
Working from bottom to top, this explains the pieces:
- XBRL Processor: Most software vendors who support XBRL understand what this is and are very comfortable with this level. This is the "techie level". You read the XBRL Technical Specification, you test against the XBRL Conformance Suite, and you are off to the races.
- Business Report Processor/Engine: The next level is a generalized version of a business report. This is defined by the XBRL Abstract Model 2.0. I would go one step further and define a more constrained application profile or even better a handful of application profiles. Here is one example general business reporting application profile which is based on the US GAAP Taxonomy Architecture. Basically, this profile does not allow tuples and the other stuff the US GAAP Taxonomy Architecture prohibits, but is more restrictive and safer to use because it forces better consistency. A proof by the Financial Report Semantics and Dynamics Theory shows that 99.9% of SEC XBRL financial filings follow these semantics and fit into this representation.
- Financial Report Disclosure Processor/Engine: Building on top of the business report processor is another processor which is unique to financial reporting. There may be a desire to split this out even further to US GAAP, IFRS, and maybe even SEC specific financial reporting. That is to be determined and the answer will unfold as the classes are built out.
There are WAY, WAY more pieces than what I am showing in the graphic above: import/export, rendering, validation, workflow management, content management, query. But I left those pieces out to better focus on the differentiation of these specific pieces.
Most software does not break these out correctly. That causes reduced software flexibility and harder to use software. It also causes error prone SEC XBRL financial filings. What if software did not allow you to create mismatched Level 3 text blocks and Level 4 detailed disclosures such as the ones documented on this page? Or better yet, what if the financial report disclosure processor had an intimate understanding of these digital financial report principles so you could never make these sorts of mistakes? That is the entire point of having the disclosure processor/engine.
Can anyone point me to a better architecture that actually works correctly? I would recommend that you may want to go back to the blog post Data and Reality before you tell me that this cannot work.
I wish I knew 15 years ago what I know now. When I learned some things about the IT world, I made two mistakes. First, I thought these things had been around for quite some time. Object Oriented Programming is actually relatively new. Second, not everyone in the IT world understands this stuff. There are people who are good at object oriented programming, and there are those who are not.
This document, Object Oriented Programming by Carl Erickson, provided some enlightening information about the creation of software.
On page 40 of the PDF:
A study in 1999 by Elemer Magaziner of requirement specifications found that they are typically only 7% complete and 15% correct.
Except for very constrained domains, re-implementations of existing functionality, or trivial applications, the process of defining requirements is almost guaranted to result in:
That is pretty low. Even the statistic was three or even four times what it is, it would still be low. Most of the stuff that I work on are things which have never existed before. It is no wonder that they tend to not work as I would expect.
On page 7 of the PDF:
Booch identifies five common characteristics to all complex systems:
1. There is some hierarchy to the system. A minute ago we viewed hierarchy as something we did to cope with complexity. This view says that a complex system is always hierarchic. Perhaps people can only see complex systems in this way.
2. The primitive components of a system depend on your point of view. One man’s primitive is another complexity.
3. Components are more tightly coupled internally than they are externally. The components form clusters independent of other clusters.
4. There are common patterns of simple components which give rise to complex behavior. The complexity arises from the interaction or composition of components, not from the complexity of the components themselves.
5. Complex systems which work evolved from simple systems which worked. Or stated more strongly: complex systems built from scratch don’t work, and can not be made to work.
Also on page 40:
Generality is good, but comes at a cost. Some balance must be met. Developers who really become OO (object oriented) are particularly prone to this problem. The elegant, complete, general solution to a class design becomes a goal unto itself. You’ve got to know when good is good enough.
I cannot tell you how many conversations that I have had with software developers about them over-generalizing something. Take an "element" in XBRL. When you generalizing everything down to an element, you totally lose important differences between the categories of elements: hypercube, dimension, member, primary items, concept, abstract.
To create good software you need three things:
- Extremely deep business domain expertise for the business domain for which the software will be developed.
- Extremely deep technical expertise and at least some of this expertise should be in the form of a technical architect/engineer. Now, I don't mean engineer how many IT people use the term engineer. Many IT people tend to think that everyone who understands how to program is an engineer. This is NOT the case.
- Extremely good communication between the deep domain experts and the deep technical experts. This is extremely hard.
Developing good software is hard work. It is no wonder that business users don't particularly care for software which is used to create SEC XBRL financial filings. Not only is the software hard to use but they don't even work correctly for their intended purpose. Now I understand why this is the case.
So don't get me wrong here. I am NOT saying that software vendors are the problem. I mention THREE points above. You need all three. Business domain professionals are just as culpable as the technical experts. Clearly the requirements or purpose of the software are not being communicated effectively.
More to come...
- Disobedience over compliance. You don't win a Nobel Prize by doing what you are told, you win Nobel Prizes by questioning authority and thinking for yourself.
- Emergence over authority. How does the authority of a system exist? Authority is not about someone with a title, authority is about leadership.
- Practice over theory. It is better to have a fact than a theory.
- Learning over education. Education is what others do to you, learing is what you do to yourself.
- Pull over push. Pull from the network as you need it rather than stocking what you think you might need.
- Compasses over maps. You need to have a compass heading of where you want to to, not an entire map.
- Resilience over strength. Understand how to recover (bounce back, resilience) rather than focusing on how not to fail.
- Systems over objects. Focus on the system, not the objects in the system.
- Risk over safety. Take risks, don't spend your entire time figuring out how not to fail.
I am in the process of comparing the results of obtaining financial information from SEC XBRL financial filings from four different software algorithms (four different software vendors and working on a fifth). This document shows the current results of that analysis. (If you are a software vendor and you have an API which provides financial information from SEC XBRL financial filings and want to be included in this analysis you can see how to extract this information here, contact me when this is working and I will add you to the analysis.)
One thing this analysis shows is exactly what is necessary to make use of the information in SEC XBRL-based financial filings. What that means is that there is no reason to be ignorant about the impact of making specific choices about how information is represented.
These three resources provide detailed information related to reading this information:
- Understanding the Minimum Processing Steps for Effective Use of SEC XBRL Financial Filing Information
- Arriving At Digital Financial Reporting All Stars
- Getting the Current Balance Sheet and Income Statement Start Date Right (This issue was not explained completely in the first document, this clarifies one important issue.)
There are two key pieces of getting the fundamental accounting concept information which provides clues as to what is necessary to get ANY information from an SEC XBRL financial filing.
The first is the mapping between the US GAAP XBRL Taxonomy and the fundamental accounting concepts. This is the XBRL-based machine readable information which contains that mapping. Clearly if different software programs use different mappings, the results the software program will be different. Since the XBRL-based machine readable information is hard for humans to read, I generated this human readable version of the exact same mapping information.
Two of the more interesting mappings are for net income (loss) and equity. Go look at the document or consider this screen shot (click image for larger view):
What is that mapping saying? Well, it says that the same line item "Net Income (Loss)" is being reported using different concepts from the US GAAP XBRL Taxonomy. Those six cover most cases. Now don't get confused here. I really mean the exact same line item, not "Net Income (Loss) Attributable to Parent" or "Net Income (Loss) Attributable to Noncontrolling Interest" or "Net Income (Loss) Available to Common Stockholders". I mean the EXACT SAME LINE ITEM.
There are exactly two reasons this is happening: (a) the concepts available in the US GAAP XBRL Taxonomy, (b) the interpretation of how filers are told to file per the Edgar Filer Manual. I am not going to go into details and explain this, that would take an incredible amount of time and we would have to dig into the details. There is no need to do that though, the SEC XBRL financial filings speak for themselves.
The bottom line is that this inconsistency in which net income (loss) concept to use to report what information is unnecessary. There is no technical reason, you don't get more information if this approach is used, it is flat out unnecessary. In fact, it is unnecessarily confusing.
Look at the concept "Equity". That also provides good insight.
The second key piece are the rules which are necessary to impute fact values which are not reported but that you need to both analyze information and as checks to make sure your data does not contain errors. This is the set of impute rules necessary to get the fundamental accounting concept information.
Looking at impute rule BS-Impute-04, it basically says "IF Assets is not equal to ZERO and if Current Assets is not equal to ZERO (i.e. both Assets and Current Assets are reported); THEN Noncurrent Assets is equal to Assets - Current Assets (i.e. if the filer did not report Noncurrent Assets which is common, just calculate it).
Pretty straight forward why you would need to do this, to both get values you need and cross checks to make sure the information that you are working with is correct.
The impute rules show three important things. First, that you can do this to get and work with the information you need. Second, it shows the extent to which you MUST do this given the way SEC XBRL financial filings are created. Third and most important, that if you CANNOT get certain values there is no way you can create an automated set of impute rules the only alternative is to manually map each SEC XBRL financial filing where you cannot get the values you need.
A good case in point is revenue. Some filers don't report the concept "us-gaap:Revenues". No problem, just use those mappings. Right? Wrong. There is so much variety in terms of what concepts filers use to report revenues and some filers do not provide a total for revenues that it is impossible for the CORRECT value for revenues to be sorted out. So again, what this means is that humans have to get involved to overcome this issue, potentially for thousands and thousands of filings.
By contrast, almost 100% of all filings have the concept "us-gaap:Assets", a total for assets. It is trivial and safe to obtain that reported value. Most information can safely be obtained, it is the exception that is unsafe, revenue is one example. Operating expenses is another. There are a handful of other exceptions.
So you get the financial report, you run software against that report, you obtain results. This is the result I obtained from the Home Depot financial filing:
Four different software programs, EXACT SAME RESULT! So what is so surprising about that, you would expect the software to get the same result, right? Why would software get different results? Do you WANT software ever getting different results for financial information?
No, you DON'T want different results. You want the software returning the results to safely, reliably, predictably and repeatedly give you the correct information, over and over and over no matter what software application you are using. Is that not the promise of XBRL?
By way of contrast, do you want obtaining even this basic information to be a guessing game? Do you want software vendors to write individual software programs which might return different results? I am making a coordinated effort to make certain that these software vendors return the exact same information to achieve a purpose. The purpose is two things:
- Show that it is possible
- Show what it takes
Go back to the mappings and the impute rules and really look at them. Would you want those mappings and impute to be as complex as possible or as simple as possible to try and help software vendors to be able to write consistent query tools? Clearly this is a rhetorical question, but it makes the point. The simpler the better.
Look at the mappings and the impute rules. What can be done to make those simpler?
This analysis is less about ***the*** fundamental accounting concepts and more about the process. Anyone could create any defined set of concepts they might desire. The process is EXACTLY the same, just different concepts. So please don't focus on the specific concepts.
On the other hand, this set of concepts and relations is provably 100% complete for extracting information from not only the primary financial statements, but also from any disclosure which is linked to the primary financial statements. For example, if property, plant and equipment is broken down into its components in the disclosures, these fundamental accounting concept relations force the disclosures which hook to the primary financial statements correctly to likewise be correct. That is the beauty of these fundamental concepts and relations, they form quite a nice "skeleton" into which everything fits.
Please do not misinterpret anything that I am saying to indicate that I am saying that financial reports need to be "forms" in order for XBRL to work for something like SEC XBRL financial filings. To the contrary, the same skeleton which the fundamental accounting concepts provide also provides a framework for extensibility. A discussion of extensibility is beyond the scope of this blog post. I would point out that different concepts need different types of extensibility rules and different types of relations between report elements. Properly implemented, extensibility works well and is definitely needed for US GAAP based financial reporting.
I will be doing this analysis for each of the DOW 30 companies, then the Fortune 100, then the S&P 500. My goal is to tune the software, the impute rules and if necessary the fundamental accounting concepts themselves. I have already found a couple of additions which makes this process more reliable.
Creating a safe, reliable, predictable, repeatable process is a choice. If you are ignorant of the moving parts of the puzzle, you might make the wrong choice. This helps see the moving pieces, it makes the moving pieces quite clear. There is pure science, no subjectivity or judgement is involved.
This information is helpful in improving the excessive tolerances in the SEC XBRL financial filings system and by others creating systems to avoid these excessive tolerances.
Consistency is a conscious result of removing inconsistency.