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.
In his book Models. Behaving. Badly. the author Emanual Derman points out:
Theories discovered by great leaps of individual insight eventually become transformed into formulas anyone can learn.
Not that I think we are there yet, but we are getting closer. It takes hard work to master a model or create a theory. A creator is attempting to discover the seemingly invisible principles that hide behind appearances. Theories don't simplify. Theories describe the principles by which the world operates. A theory is characterized by its intent: the discovery of essence.
Theories make things easier to understand. Theories articulate rules that anyone can follow.
Rene van Egmond and I have been collaborating, trying to figure out how to properly apply XBRL to financial reporting since the very first XBRL International meeting in 1999. Rene has a strong technical background, I have a strong financial reporting background. We both know people all around the world who know bits and pieces about XBRL. We have both looked at this information attentively. We have both looked at it closely. We have both looked at it over, and over, and over. I was funded by UBmatrix to do nothing else but understand XBRL for over 12 years and took full advantage of that opportunity. I worked with world class accountants on creating both the IFRS and US GAAP XBRL taxonomies. I was lucky.
Rene and I put our knowledge together to create the Financial Report Semantics and Dynamics Theory two years ago. We are in the process of updating that document, the update which is a work in progress is available here. Suggestions, feedback, and other comments which lead to improving the document are greatly appreciated.
Nothing significant has really changed in this document. We are mainly honing and tuning. What is significant is that there are two commercial implementations which make use of the model of a financial report proposed by this document: Edgar Report Information web service of XBRL Cloud and SECXBRL.info of 28msec.
The most interesting of the two is SECXBRL.info because anyone can see the implementation for free because 28msec makes the DOW 30 information available for free. The XBRL Cloud implementation costs $9.95 per month to use.
Neither of these impelmentations provides a complete financial report model processor. Both focus on the underlying information which is the first step. Both implementations are a big step in the right direction of providing real value to business users and prove the model.
Another important thing to understand is that the partial proof which was undertaken in the document has been repeated two more times and results are consistent with that first partial proof. Basically, SEC XBRL financial filings prove this theory.
"What?", you ask. "That seems to be a contradiction. What good is the Financial Report Semantics and Dynamics Theory if SEC filings follow that theory but the quality of SEC filings is so poor? How does that compute?"
Well, you can see what is going on if you have a look at the Digital Financial Reporting Principles document or if you look at the Understanding Minimum Processing Steps for Effective Use of SEC XBRL Financial Filing Information document which explains how to look at certain specific details of SEC XBRL financial filings.
Basically, this is a TWO step process, not a ONE step process. You don't just blindly consider the SEC filing. You must consider the filing itself and the CORRECTNESS of the thing that you are looking at in the filing. The perfect example of what I am talking about is the part of the theory which says "Assets = Liabilities and equity" because I checked 100% of the population of SEC XBRL financial filings.
Let me walk you through this so that you are clear as to what I am saying.
First, I wanted to pick something which was absolutely uncontroversial and probably had the fewest errors so that I can test 100% of the population. That is why I picked "Assets = Liabilities and equity". The accounting equation. No rational accountant disputes this fact.
Second, you apply pure logic. Nothing subjective, nothing which can be remotely disputed; logic and common sense. Either an SEC filing's current balance sheet balances or it does not. This is the process of seeing if the balance sheet balances:
- You have to have the financial report with the information in it.
- You have to figure out the accounting entity or "entity of focus" to use from the report.
- You have to figure out what the current balance sheet date is of that report.
- You want to get the correct concept(s), two concepts in this case, "Assets" and "Liabilities and equity" from the report.
- You want to be sure that you don't get the wrong facts, the incorrect reporting scenario or some other aspect which you did not want.
- You want to see if the two concepts have the same value, see if the balance sheet balances.
- You repeat this process for 100% of the population of reports.
You perform those steps and you look at the results. I have performed this task numerous time, here are the results for the last time. On page 7 you see the results for this one test.
Of 6,674 SEC filings, I was able to obtain 6,674 reports (#1). I was able to figure out the "entity of focus" for 6,622, all but 52 (#2). I manually looked at all 52 that I could not discover the entity of focus for. Because of the process I was using, the error related to either not finding the entity of focus (#2), not being able to figure out the current balance sheet date (#3), or not being able to find the concept "Assets" or "Liabilities and Equity" (#4). Common errors included representing the entity of focus incorrectly, an inconsistent articulation of the balance sheet date, the wrong current balance sheet date, the filer incorrectly creating an extension concept for expressing "assets" or "liabilities and equity", or using the wrong concept from the US GAAP XBRL taxonomy such as "us-gaap:AssetsNet" to express "Assets". Basically, every fact was accounted for and I could prove that they were correct or that they had an error.
For the 6,622 where the facts were found, I found the concept "assets" and I found the concept "liabilities and equity" and the two fact values were the same which is what I expected for 6,593. That left 29 filings where the balance sheet did not balance. I looked at each of those manually and found that either the filer was using a "tolerance" (i.e. they had a small rounding error), they transposed numbers in their report, they provided the wrong fact in their XBRL which did not match the value in the HTML, or they simply make a mistake and their balance sheet did not balance.
And so, 100% of the set of filings was accounted for. Of the set, on ever occasion "assets" SHOULD have equaled "liabilities and equity" or it ACTUALLY DID.
My hypothesis was correct! Balance sheets balance.
OK, so the logic seems to work. Can the same logic be applied to other situations? Well, turns out that there are plenty of situations where the logic can be applied. First, all the things in the Financial Report Semantics and Dynamics Theory. That is WHY those things were put into the theory, BECAUSE they apply.
How do I know these things apply? Well, go read the FASB conceptual framework of financial reporting. If that is too hard, the Wiley US GAAP guide and the intermediate accounting text book (a) explain the conceptual framework in terms which are a little easier to understand and (b) they are likewise consistent with the Financial Report Semantics and Dynamics Theory.
Digging in a little further, you see other logical and sensible situations articulated within the Digital Financial Reporting Principles document which you would always expect to be true. You can summarize this stuff and organize it into what I am calling a digital disclosure checklist.
Folks, this is stuff that accountants do today! Now, two things are going on. First, external financial reporting managers are simply misapplying XBRL. Here is an uncontroversial example of that. Can a fact be both a finite lived and an indefinite lived intangible asset at the same time? Or course it cannot. But that is exactly what this filer is saying in this disclosure. This has nothing to do with someone's opinion. XBRL works in specified ways (i.e. the XBRL Specification is called a specification for a reason). You don't get to make stuff up. Besides, suppose you could just make stuff up. How would that work for exchanging information?
Am I seeing things incorrectly? If I am, please enlighten me. All Rene and I are trying to do is create the best, most elegant and well crafted work that we can. Is there some more logical, rational approach which works and all those SEC XBRL financial filings are really right, it is just that no one understands how to interpret them? Something else, some other theory? Some other model?
If someone knows about some other theory which explains what is going on, please enlighten us. Alternatively, if you are looking for some way to wrap your head around what is going on with SEC XBRL financial filings, Rene and I hold out to be a model what works. Leverage our formula. Our formula is proven by SEC XBRL financial filings themselves and by two commercial implementations of the base model.
Any ideas or other feedback to make this theory even better would be gladly accepted.
For 100 years or so financial reporting has been paper based. It was only in the last 25-30 years that financial reports been created electronically in a word processor and then printed or saved to an electronic format such as PDF or HTML.
During the age of paper, paper-based spreadsheets were used to summarize, aggregate, or other organize detailed information which made its way to the financial report. Electronic spreadsheets replaced paper-based spreadsheets.
External financial reports can be required to be provided to a regulator such as the Securities and Exchange Commission (SEC), such is the case for public companies. Certain industries comply with the requirements of other regulators such as financial institutions provide financial information to the Federal Deposit Insurance Corporation (FDIC).
Private companies provide external financial statements to commercial lending institutions in support of commercial loans. State and local governmental entities provide external financial statements to voters and to lenders who provide bonds and other financing. Not-for-profit entities provide financial statements in support of federal grants.
The flip side of compliance with the rules and regulations related to external financial reports is noncompliance. Noncompliance is a risk which is managed by those creating external financial reports.
Because, historically, external financial reports were unstructured; there was no other way to ensure compliance then by throwing humans at the problem. Compliance involved humans doing lots of work. Pretty much all the work really.
When information is structured something very significant changes. While unstructured information is not understandable by machines such as computers; structured information can be understood. How much can be understood is dependent on the nature of the structure. The richer the structure, the more information that can be provided in machine readable form. The more information provided in machine readable form, the more a machine can understand.
But the structure alone is not enough to provide much value to those creating external financial reports. When computer readable business rules that articulate information about the structured information, very interesting things start to happen.
As I said earlier, humans were the only way to make sure the information of unstructured external financial reports were in compliance (correct, complete, accurate, consistent).
When information is structured and when a rich set of business rules is created, some of the tasks associated with compliance can be moved from manual tasks performed by humans to automated tasks performed by machines. How much which was manual can be automated? That depends on the structure and on the business rules created.
Why turn manual processes into automated processes? Why do auto makers use robots and other machines in the process of creating cars? Automation can be cheaper than humans in many cases. Machines make way fewer mistakes than humans when repetitive tasks are performed. Machines are faster than humans. Machines are more consistent, tolerances are tighter, quality can be better in certain areas.
Can 100% of the process of creating an external financial report be automated and performed by machines? No way. There is a tremendous amount of professional judgment which is required to create an external financial report. Tasks that require human judgment can never be automated. However, there are repetitive, mindless tasks that are also part of the external financial report creation process. Many of those tasks can be automated.
What are the benefits of successfully automating here-to-for manual tasks? This is the value proposition:
- Taking manual processes and automating those processes using structured information and machine readable business rules. This can save time, reduce costs, and improve quality.
- Taking complex tasks which require significant knowledge and reducing the knowledge which is required by having a machine assist the business user, supplementing that human's knowledge.
- Reducing the time needed to create an external financial report.
- Increasing the quality of the external business report by leveraging automation, thus reducing human error by reducing the tasks which humans perform.
- Reducing the risk of noncompliance.
- The discipline and rigor of defining the rules in machine readable form causes an increase in the clarity of the business rules articulated over the current approach of defining these business rules which tend to have gaps, inconsistencies, ambiguities, duplication, etc.
Now, if you take current processes, leave those processes in place, and then try and structure information after the fact it is very hard to grasp the value of structured information. But if you totally reengineered the process of creating an external financial report, the value is easy to understand.
How many business rules are we talking about? Many thousands potentially. Sound overwhelming? Well, those business rules already exist. They are organized in the brains of the humans who perform those manual processes. A human gets sick, a human finds a new job, the knowledge leaves the organization. Machine readable business rules becomes part of the organization's knowledge base and internal processes. A significant amount of the value is the business rules themselves. Many of these business rules are documented, but documented in forms not readable by machines.
Business users are in control of the metadata and business rules, not IT departments. Applications are driven by models, metadata, and business rules. Rather than IT departments hard coding rules which business users have to then rely on IT departments to change when the business environment changes; business users reconfigure metadata and change business rules to adapt systems to new business circumstances. This is a new paradigm, machines driven by models and metadata controled by business users.
Business users will work with software which have financial disclosure models and financial disclosure processors. These software applications understand the structured information, metadata, and business rules. The software does not force business users to deal with the underlying technologies. Complexity is hidden from business users by the models and processors.
Which technical syntax is used to structure information and articulate business rules is a secondary consideration. Global standard technical syntaxes are better than proprietary technical syntaxes. More expressive technical syntaxes are better than less expressive technical syntaxes. Internet enabled structured information is better than non-Internet enabled structured information.
Pressing the "Save as XBRL..." button is of secondary consideration. Whether the structured information is used for further analysis is a by product of properly creating the structured information. Using the information for analysis has nothing to do with whether structured information has value in the creation process.
If value can be created in the process of creating external financial reports, it is highly likely that value can be created in other domains using the same or similar technologies and techniques.
But to realize this value the system needs to work. The information created and exchanged to a consumer of the information must have the same meaning to both parties. The system should be reliable and predictable. Processes must be repeatable and safe. This cannot be a guessing game if it is to be useful.
Achieving the value proposition is a choice. All the necessary technology exists.
The most amazing thing happened today.
Here are some demo applications which make use of Blockly.
While I think Blockly is amazing, that is not the amazing thing that happened. The amazing thing is that the guy who told me about Blockly said that he heard about Blockly from the FASB! Someone named Andie.
Turns out that Andie is a data modeler and likes ontology:
Andie joined the IFRS XBRL team at the beginning of 2012 and is now a part of the wider Disclosure Initiative which looks at all things disclosure and taxonomy. She is a data modeler, XBRL expert and quite keen on Ontology. Average working days include anything from working on ways to improve extensions in XBRL, modeling IFRS standards, working with the Conceptual Framework team, analysis of IFRS disclosures and developing the future model and management of the IFRS Taxonomy. She manages the consistency of the taxonomy with XBRL specifications and is currently a member of the XII Taxonomy Architecture Task Force. In previous roles she has worked at Ernst & Young with their XBRL team, for Atos Origin working on the Banco de España XBRL project and in the dim mists of time at DecisionSoft/Corefiling. Andie has also plied her trade as a data modeler and XML consultant on a number of other projects involving no XBRL whatsoever! In her spare time she dabbles in data analysis, photography and archaeology none of which bear any relation to her degree in Biological Sciences from Oxford.
THIS IS AWESOME!
The most awesome thing about all this is that Andie is a data modeler and does not have an IT background.
What seems to have happened is that the people who created Scratch, which I pointed out on my blog back in 2009, helped Blockly get going or something. Don't know, does not matter, it is just great that Blockly exists. That should help people understand that all digital financial reporting does not have to be complex.
Many people pushing XBRL as a digital financial reporting format point to transparency as one of the benefits of leveraging that technology. Well, you can get a glimpse of what they are talking about today. Admittedly there is a ways to go, but the path has been set and we are rapidly moving down that path.
These are some visualizations and this is an accounting tool which I created using information obtained about SEC XBRL financial filings using off-the-shelf software provided by UBmatrix (Taxonomy Designer, XBRL Processor), XBRL Cloud (Edgar Report Information API), 28msec (SECXBRL.info API), Tableau (Tableau Public), and Microsoft (Access, Excel).
The visualization above are for report element extension and errors. This visualization shows Fortune 100 information(prototype). I am pulling information which I extracted from the SEC XBRL financial filing. If the filer reported it wrong or made me guess, reported information may show up in this visualization incorrectly. Personally, I don't think using this information should be or needs to be a guessing game.
So, people who want to get at this information can get the information. But, there are three pieces left as I see it:
- Improve quality. The quality of SEC XBRL financial filings needs to improve and they will. Transparency will help detect and correct errors. Something like this digital disclosure checklist will help reduce errors. The more business rules, the more which can be automated. Automating as much information verification is the key to information quality.
- Eliminate guessing game. Using this information should be safe, predictable, reliable, repeatable. Software vendors should not need to spend untold hours unraveling this information. That is costly and causes the system to be brittle. This information should be easy for a machine to interpret.
- Make things easier for business users. Admittedly I have a deep, deep knowledge of the moving pieces and am very fortunate to understand both the financial reporting aspects and the technology aspects at work. For that I am grateful to all those who have helped me over the past 15 years. But building these pieces needs to be easier for business users who have less knowledge, particularly technical knowledge.
This document, Digital Financial Reporting Principles, is my best effort at collecting and organizing information which can be used to improve quality, eliminate the guessing game, and making things easier for business users.
Think about the sorts of things you can see from these examples and from other software products and services which leverage the XBRL-based financial information mandated that public companies report to the SEC. Project from what you see to other possibilities. These are only a few examples.
While US financial reporting is on the leading edge of digital financial reporting, think of other domains where these same technologies and techniques can be applied. Think of other products which will likely be created by the market.
Don't let people fool you into thinking that all this is hard and has to be complex. It doesn't. Beat down complexity. If I can do this, others can do this also. If what you have been trying seems hard or complex, try something different.
Two quotes from Albert Einstein:
Insanity: doing the same thing over and over again and expecting different results.
Any fool can make things bigger, more complex, and more violent. It takes a touch of genius-and a lot of courage-to move in the opposite direction.
Simple is the ultimate sophistication. Simple is elegant.
The above examples will give you an idea of the level of transparency which is on the way. Empowering business users to employ these sorts of technologies and techniques is valuable.
Man, this is incredibly interesting and useful stuff. This visualization "Errors and Report Elements" tab or "Dashboard 2" shows Errors on the vertical axis and the number of extension report elements on the horizontal axis. The two screen shots below are for LARGER and SMALLER reporting entities. You can select which groups you want to see. The really interesting thing is to look by Generator!
This is a visualization of errors and extension concepts for larger entities: (fewer errors, more extension report elements)
This is a visualization of errors and extension concepts for smaller entities: (more errors, fewer extension report elements)
Reach your own conclusions.