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.
We live in the Information Age (also known as the Computer Age, Digital Age, or New Media Age). The Information Age was brought about by the Digital Revolution.
But many business professionals, including accounting professionals, are information barbarians. Their information tools are primitive and unsophisticated. Their information skills, let's just say, lack refinement and grace.
How did this happen? It seems to me there are three reasons:
- A rapid pace of change.
- College education is not keeping up.
- Supplemental learning is not appropriate.
There could be other reasons. How we got where we are is likely interesting, but what is more important is fixing the problem.
One wrong approach to fixing the problem is the "learn to code" hysteria. As I have pointed out, I am not alone in thinking that "learn to code" is misguided. And besides, as I also pointed out, the Wired magazine article The End of Code points out that we won't be "coding" in the future, we will be training computers like we train dogs. Sure, learning to code would not hurt anything. But, learning to code will not turn an information barbarian into a civilized member of the information age.
Another wrong approach was proposed by the CFA Institute in a paper. While the CFA Institute did articulate an excellent vision of how structured data can be used to fix the currently inefficient process (i.e. barbaric) of financial reporting; they call for auditors to receive "increased education in technology". Personally I think that is not the right approach. The right approach is to provide auditors with better software tools.
I am not sure if is a complete solution to the problem, in fact I don't think that it is. But part of the problem business professionals have will be solved by understanding a set of 15 principles that I find helpful when thinking about digital financial reporting. Here is a summary:
- Prudence dictates that using financial information from an XBRL-based digital financial report should not be a guessing game.
- A near zero defect financial report is useful, a defective financial report is not.
- Rules prevent anarchy.
- The only way to achieve a meaningful exchange of information without disputes is with the prior existence of and agreement as to a standard set of technical syntax rules, business semantics rules, and workflow rules.
- Explicitly stated information or reliably derived information is preferable to implicit information.
- Digital financial reports can be guaranteed to be defect free using automated processes to the extent that machine-readable business rules exist.
- When possible to effectively create, machine-based automated processes tend to be more desirable than human-based manual processes because they machine processes are more reliable and cost less.
- Computers have limited reasoning capacity.
- Business rules should be created by knowledgeable business professionals, not information technology professionals.
- The stronger the problem solving logic, the more a machine can achieve.
- Catastrophic logical failures are to be avoided at all cost; they cause systems to completely fail.
- Complexity cannot be removed from a system, but complexity can be moved.
- Part of a system is not really that useful.
- Simplicity and simplistic are not the same thing.
- Apply double-entry bookkeeping procedures, processes, and techniques to digital financial reports.
There is nothing technical or hard to understand about those principles. Most are simply common sense. But, if you don't have that framework it is hard to keep in mind what is important.
In another Wired article, Barack Obama, Neural Nets, Self-driving Cars, and the Future of the World, the ex-president pointed out another issue:
"There are gonna be a bunch of choices that you have to make, the classic problem being: If the car is driving, you can swerve to avoid hitting a pedestrian, but then you might hit a wall and kill yourself. It's a moral decision, and who's setting up those rules?"
As I previously pointed out, that statement which relates to self-driving cars points out two things that accounting professionals and other business professionals need to consider when thinking about something like intelligent XBRL-based digital financial reports:
- WHO: who writes the rules, the logic, which software follows,
- HOW: how do you write those rules and put them into machine-readable form and get all this to work reliably?
The changes will not be from sustaining innovations, they will be disruptive innovations. Things like XBRL are new knowledge media that offer completely new capabilities. As the currently barbaric financial reporting processes are transformed, one should consider learning from other such transformations. For example, the evolution of drafting from vellum to computer, can be learned from. Emulate the good, avoid the bad.
In my view, what business professionals need to understand to thrive in the information age are the following two fundamental things:
- First, business professionals need to understand that computers work using the rules of formal logic. Formal logic is a discipline of philosophy. Computers work based on the rules of mathematics. Mathematics is based on the rules of formal logic. Understanding how to think using formal logic will help you understand the real capabilities of computers.
- Second, business professionals need to understand a few basics about knowledge engineering. This will allow business professionals to more effectively communicate with information technology professionals.
That is really it. None of this needs to be a mystery or some "black box" that you don't understand how to properly employ. Artificial intelligence is more than a buzz word; but right now there is a lot of hype related to that word. On the one hand, don't fall for the sales pitches of the many snake oil salesmen. On the other hand, don't ignore good capabilities.
The XASB Financial Report Proof of Concept is exactly that, a proof of concept. What I am doing is stealing every good idea of every taxonomy I have been exposed to, using those ideas in this proof of concept and avoiding all the mistakes others have made that lead to problems. This financial reporting proof of concept uses the imaginary XASB accounting standards, so I can avoid any constraints imposed by the FASB's US GAAP XBRL Taxonomy and/or IASB's IFRS XBRL Taxonomy in my working prototype.
Further, any public company can use these ideas to file their XBRL-based financial reports to the SEC. Why? Because that is where I got most of what went into this proof of concept: by reverse engineering public company XBRL filings to the SEC. What this proof of concept does is decouple what the SEC requires that would not be applicable to other financial reporting schemes.
What is the point? To create a perfect, or as near as perfect as possible, zero-defect intelligent XBRL-based digital financial report. Why? Software testing.
Here is my first working prototype:
- Reporting checklist rules (what must be reported)
- Disclosure mechanics rules (logical, mechanical, mathematical relations between the things that make up a disclosure)
- Fundamental accounting concept relations rules (basic accounting relationships within and between disclosures)
- Model structure rules (relationships between the basic structural elements that are used to express disclosures)
- Business rule arcroles (used for representing reporting checklist and disclosure mechanics rules, rules-arcroles.xsd)
- Other arcroles (used for representing other relationships and rules, fro-arcroles.xsd)
- Conceptual model (building blocks of a digital financial report)
- Base XBRL taxonomy (financial and nonfinancial conscepts and characteristics, including XBRL formulas which represent relations between concepts, used to create report)
- Company extension XBRL taxonomy (economic entity specific businesss rules, including XBRL formulas, used to create report)
- Financial report XBRL instance (the actual financial report)
More to come so stay tuned! Don't make the mistake of misinterpreting what you see. Lots and lots of stuff is going to change in the taxonomy itself. Also, the modularity of this is not what I want, so that will likewise change. Also, I need to tune the conceptual model.
If you have any comments or suggestions, please send them to me if you so choose. Great way to learn!
To understand the details, please see Intelligent XBRL-based Digital Financial Reporting.
In a prior blog post I mentioned the world's first XBRL-based machine-readable digital financial reporting checklist.
I made some improvements:
- Natural language tree view of rules: Before I simply provided a flat list of rulesand a JPEG image of what shows up in an XBRL taxonomy tool when the tool reads the rules. That view still exists, but the natural language tree view is easier to use for many things. If you click on a disclosure, you will note that you are taken to the disclosure mechanics rules.
- Tuned the arcroles: I made a few tweaks to the arcroles based on actual usage of the arcroles in software.
- Processing steps view: I created a view that breaks down the rules by processing step. This helps me think through some things.
- List of disclosures reference by the reporting checklist: This provides a list of each of the disclosures referenced by the reporting checklist.
- Multiple reporting checklists: When I started the fundamental accounting concept relations I made a basic mistake. The mistake was that I tried to put all the relations into one set. Ultimately I realized that there was not one set of fundamental accounting concept relations; rather there were multiple sets. That is where the notion of reporting styles comes from. Banks, insurance companies, and real estate investment trusts have different reporting checklists than say a software company. And software companies have different reporting checklists than say an airline.
- Natural language representation of disclosure mechanics rules: I now have a natural language representation of disclosure mechanics rules. I have this working but I have not made this publicly available yet. See more below.
Now, what is becoming apparent is how the reporting checklist rules and the disclosure mechanics rules work together. And, it is seeming like the fundamental accounting concept relations fits into the mix here but I don't quite have that dialed in yet. This is how I differentiate the two:
- Reporting checklist rules: A reporting checklist and it's rules help make sure you are providing the appropriate disclosures in a financial report. Some disclosures are always required, some are required if a specific line item is reported, and other disclosures can exist but there is no way to use automated processes to test whether they should be provided or not. Also, disclosure alternatives are provided for. So, for example, a reporting entity could provide (a) a separate income statement and statement of comprehensive income; or (b) a combined statement of income and comprehensive income. The reporting checklist rules seem to relate to WHAT must be provided.
- Disclosure mechanics rules: The disclosure mechanics rules are used to check the logical, mechanical, mathematical, and some accounting related relations within the "stuff" that makes up a specific disclsoure. So, if you provide a specific disclosure the disclosure mechanics rules specify WHERE it is provided an HOW is is provided.
What it is looking like to me is that the fundamental accounting concept relations rules will migrate into the disclosure mechanics rules. I don't really want two separate things when one thing will do.
Also, as I mentioned above, I have natural language representations of the disclosure mechanics rules. While I have not provided this publically yet, here is an example. Consider the disclosure of the components of inventory:
Business rules for disclosure: disclosures:InventoryNetRollUp. The disclosure...
- goes into a Network with the SEC Sort Code: Disclosure (alternatives are Document, Statement, Disclosure, Schedule)
- must be represented as the concept arrangement pattern: Roll Up (alternatives are Roll Up, Roll Forward, [Text Block], Hierarchy, Adjustment)
- must be represented as using the Level 3 Disclosure [Text Block]: us-gaap:ScheduleOfInventoryCurrentTableTextBlock
- OR, alternative, the Level 3 Disclosure [Text Block]: us-gaap:ScheduleOfUtilityInventoryTextBlock
- the fro:RollUp total must be represented as the Level 4 Detailed Concept: us-gaap:InventoryNet
- requires the policy to be reported using the Level 2 Policy Text Block: us-gaap:InventoryPolicyTextBlock
- OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryMajorClassesPolicy
- OR, alternative, Level 2 Policy Text Block: us-gaap:InventorySuppliesPolicy
- OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryWorkInProcessPolicy
- OR, alternative, Level 2 Policy Text Block: us-gaap:InventoryFinishedGoodsPolicy
- requires the note to be reported using the Level 1 Note Text Block: us-gaap:InventoryDisclosureTextBlock
Believe it or not, the information above and this XBRL definition linkbase say exactly the same thing. In fact, the human readable version above was generated from the XBRL definition linkbase!
Which is easier for you to read and use? Which is easier for a machine to read and use? Is there anything particularly technical about the natural language articulation of the rules? That is the point!
Now, imagine how much a machine can help the creator of an XBRL-based financial report if it understood the information above. And that is how you make intelligent XBRL-based digital financial reporting work.
Finally, think about this: What if you never pressed the "Save as XBRL..." button of your software application. Would those machine-readable rules still be useful?
Here is a great video on disruptive innovation: https://www.youtube.com/watch?v=yUAtIQDllo8
I took a prototype XBRL taxonomy that I had, modified it, and created three different XBRL taxonomies that help people focus on and see one specific thing related to XBRL Dimensions. The specific area of focus is the use of hypercubes.
In XBRL there are three general approaches to representing information:
- Mixtue of dimensional and nondimensional
XBRL International has issued guidance that says"Don't mix dimensional and nondimensional models." XBRL International's guidance (Recommendation 3.5) states, "Where a taxonomy makes use of dimensions, all concepts should be associated with at least one hypercube, even if that hypercube has no associated dimensions."
Both the US GAAP and IFRS XBRL taxonomies violate that guidance. I predict that ultimately, both of those taxonomies will be corrected.
Now, if you are using a dimensional model, using XBRL Dimensions, the next question you might have is HOW should you be using XBRL Dimensions. The one specific aspect that I want to focus on is the naming of hypercubes.
There are FOUR possibilities:
- Unique hypercubes: Give each hypercube a unique name.
- Single hypercube: Create ONE hypercube and use that for representing EACH set of facts you report.
- Single hypercube, single line items: This is the same as #2 but in addition to unique hypercubes you also have one unique concept for representing the primary items dimension or what the US GAAP and IFRS taxonomy call [Line Items].
- Nonunique hypercubes: Give each hypercube different meanings from time-to-time.
Below I will explain each alternative, provide an example XBRL instance and XBRL taxonomy for the alternative (i.e. download), an HTML page you can use to view the taxonomy (i.e. view), and highlight the pros and cons of each alternative.
By unique hypercube I mean that each hypercube has a different unique name and is used to represent one specific report fragment. In the example below you see the hypercube label "Financial Highlights [Table]" which has the corresponding name "gaap:HypercubeTable". Note also that the primary items are labeled consistent with the hypercube, "Financial Highlights [Line Items]. (Download | View)
The primary advantage of this approach is that you can extract information from an XBRL instance using the hypercube. Because each hypercube has a unique name such as "BalanceSheet" or "IncomeStatement", you can identify the report fragment using the hypercube to reliably extract information because each hypercube is unique.
The primary disadvantage of this approach is that you have to provide all of those hypercube names and the related names for the primary items.
By single hypercube I mean that you create a single hypercube, say labeled "Hypercube [Table]" and named "gaap:HypercubeTable", and then use that single hypercube to report each report fragment. Note that the primary items are still unique to the report fragment represented. (Download | View)
The primary advantage of this approach is that you don't need to create all those hypercube names.
The primary disadvantage of this approach is that you cannot use the hypercube to extract information for fragments of the report because each fragment uses the exact same name.
Single hypercube, single line items
This is the exact same as "single hypercube" above, but you also use one concept to represent each set of primary items. Note below that the primary items are labeled "Hypercube [Line Items]" and named "gaap:HypercubeLineItems" as contrast to the unique label and name above. (Download | View)
The primary advantage of this approach is that like having one concept that is used for each hypercube; if you use one concept for the primary items of each hypercube, you don't have to fiddle with coming up with all those names.
The primary disadvantage; well, I really don't see any disadvantage. Having a single concept such as "Hypercube [Line Items]" helps you realize that the primary items is really just like a dimension. The only difference between primary items and members is that primary items have data types because they will contain fact values.
"Nonunique hypercubes" is a possibility, but I reject that approach because it really does not make much sense. Why would you do this? An example of this is some XBRL-based public company financial reports to the SEC. One example is Microsoft. They use "us-gaap:StatementTable" for each of the primary financial statements, for some disclosures, and then specific hypercubes for other disclosures. (Download)
There are no real advantages to this approach really. Frankly, it is confusing. You can see that confusion when you compare how different public companies report information to the SEC.
The disadvantages of this approach is that, again, you cannot use the hypercube to extract information for a specific report fragment from a report.
So there you have it. Which alternative is best? Well, that depends on what you want to achieve I guess.
Most people think about XBRL in terms of what it is. Using that definition, XBRL is a global technical syntax for exchanging information. Another way of looking at XBRL is in terms of the value it provides. Using that definition, XBRL imparts knowledge. XBRL is a new medium. XBRL is a high-fidelity knowledge media.
In his book, Systematic Introduction to Expert Systems, Frank Puppe discusses the notion of knowledge media. This figure, a modified version inspired by Frank Puppe's Figure 3.2, shows some knowledge media in order to contrast some specific advantages and disadvantages of the different media. This will help you see the value of the XBRL knowledge media:
The graphic shows a knowledge bearer on the left which imparts some knowledge to a knowledge receiver on the right via some knowledge media. Just a few knowledge media are shown. Here is a summary of some of the advantages and disadvantages of the list of knowledge media which are shown in the graphic above:
- Direct contact between knowledge bearer and knowledge receiver: With some media you need direct contact between the bearer and receiver of knowledge. For example, with Word of mouth you generally need direct contact. With a Book, a Video, or XBRL you don't need direct contact.
- User control over information access: Word of mouth, Book, and Video all tend to be sequential access to the information. You tend to receive information in a specific order. With XBRL, it is easy to reorder or reconfigure information. The user can easily control of the order of information access.
- Verifiability of information: Verifying the information you receive is possible using any media. However, because XBRL is machine-readable; automated testing can be used to verify information and experimentation is easy. For example, I can test the complete set of XBRL-based public company financial filings using software in a matter of a few hours. Word of mouth, Book, and Video media is not machine-readable.
- Testing information ambiguity: Because XBRL is machine-readable in terms of meaning but Word of mouth is not machine-readable and Book and Video are not machine-readable in terms of meaning; XBRL can be used to measure the ambiguity of information conveyed. The effects of vagueness and poorly articulated information can be made very clear using testing, and so such ambiguity can be minimized between the knowledge receiver and knowledge bearer.
- Information fidelity: Fidelity is the degree of exactness with which something is copied or reproduced. With Word of mouth the fidelity tends to be maximized because the bearer and receiver are communicating directly. If there are issues in understanding, questions can be asked. With a Book or Video, there tends to be a bit less fidelity perhaps. With XBRL, because information is converted from what is more an analog (paper) to a digital representation, their might be a loss of fidelity if the digitization is not done well. It is sort of like the difference between a record which is analog, a CD which is digital format, and a MP3 which is compressed digital format. The price you pay for the smaller MP3 files is lost fidelity, but what is lost is the frequencies far beyond a human's ability to hear. Everything is a tradeoff.
- Reach versus richness: In their book Blown to Bits, Philip Evans and Thomas S. Wurster point out the new economics of information. In the past, you could have reach or richness, but typically not both at the same time. The internet completely changed this economic equation. Reach is access to information. Richness to quantity, timeliness, accuracy and variety of information. Word of mouth tends to be the richest information, but the reach can be lower. Books have excellent reach, but less richness. With XBRL you can have excellent reach and richness.
However, in order to make use of a knowledge media effectively, the following three conditions must be satisfied:
- Easy for knowledge bearer to represent information: The effort and difficulty required for the knowledge bearer to successfully formulate the knowledge in the medium must be as low as possible.
- Clear, consistent meaning: The meaning conveyed by the knowledge bearer to the knowledge receiver must be clear and easily followed by human beings and be consistent between different software applications. The result cannot be a "black box" or a guessing game and users of the information should not be able to derive different knowledge simply by using a different software application.
- High-quality information representation: The form in which the knowledge is represented to the receiver must be as good as possible. The quality must be high whether the knowledge receiver is a human-being or an automated machine-based process. Sigma level 6 is a good benchmark, 99.99966% accuracy.
The knowledge conveyed by a zero defect intelligent XBRL-based digital financial report as to the financial condition and financial position of an economic entity is just an example of the capabilities of the XBRL knowledge media. Digital business reports of other sorts are possible also. Think semantic spreadsheets. See here and here.