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 December 2016, the European Securities and Markets Authority (ESMA), the European Union agency responsible for the regulations that govern securities and the conduct of public markets within the EU, announced that starting January 1, 2020, public companies that prepare consolidated IFRS financial statements will provide them in the structured format XBRL.
ESMA is in the process of developing the detailed technical rules, will field test their system, and will submit the details of their proposed solution to the European Commission for endorsement by the end of 2017.
What does that mean? Well, it seems to mean that another 10,000 or so listed companies will be reporting using XBRL-based structured information. ESMA will be using Inline XBRLwhich basically XBRL embedded within XHTML. The SEC will likely move to Inline XBRL also.
Hopefully the ESMA will learn from the SEC experiences with XBRL and avoid the quality issues encountered in the XBRL-based public company financial reports. Time will reveal the answer. One advantage of Inline XBRL is that it helps separate the presentation of information (in the XHTML) and the representation of information (in the XBRL).
What will software vendors do? Will they build more bolt-on solutions to the current barbaric processes and procedures for creating financial reports or will they innovate and create intelligent XBRL-based digital financial reports using improved processes that truly leverage the technology? Will the quality pivot and the cost pivot occur?
Has the maturity levelof XBRL taxonomies, creation software, business rules available, and the knowledge of business professionals reached a point where the pieces can be put together appropriately?
Will Europe lead? Great opportunity to re-think financial reporting processes, bringing them out of the dark ages. Time reveals all.
I have made the comparison of digital blueprints, CAD, and digital financial reports before. Ask yourself a question: How useful would a digital CAD blueprint be if that blueprint had errors? If a construction contractor put together a building with a blueprint that had errors, or if someone tried to assemble an iPhone with pieces designed with blueprints that had errors, or if information was supplied to a numerically controlled machine that creates engine parts; how would that work out?
Clearly errors in XBRL-based digital financial reports would cause similar problems when investors, analysts, regulators, and others used information from the report.
So, how exactly does a digital CAD drawing achieve high quality? Why can CAD work as a global standard for the design, engineering, and creation supply chain; but XBRL-based digital financial reports have to be so error prone? What causes the difference?
How can it be that draftsmen, architects, engineers, designers, and others can successfully create near error-free digital blueprints but accounting professionals cannot create near error-free digital financial reports? Why is that?
Like many things, intelligent XBRL-based digital financial reporting will evolve and go through different maturity levels. Just like CAD, an intelligent XBRL-based digital financial report is a knowlege based system. Such a system has specific parts. This diagram outlines those parts and shows the relations between each part of a knowledge based system:
Here is an overview of each part part of a knowledge based system such as an intelligent XBRL-based digital financial report:
- Database of facts: A database of facts is a set of observations about some current situation or instance. The database of facts is "flexible" in that they apply to the current situation. The database of facts is machine-readable. An XBRL instance is a database of facts.
- Knowledge base (rules): A knowledge base is a set of universally applicable rules created based on experience and knowledge of the practices of the best domain experts generally articulated in the form of IF…THEN statements or a form that can be converted to IF...THEN form. A knowledge base is "fixed" in that its rules are universally relevant to all situations covered by the knowledge base. Not all rules are relevant to every situation. But where a rule is applicable it is universally applicable. All knowledge base information is machine-readable. An XBRL taxonomy is a knowledge base. Business rules are declarative in order to maximize use of the rules and make it easy to maintain business rules. Knowledge that makes up the knowledge base is acquired using manual or automated knowledge acquisition processes.
- Reasoning engine: A reasoning engine provides a machine-based line of reasoning for solving problems. The reasoning engine processes facts in the fact database, rules in the knowledge base. A reasoning engine is also an inference engine and takes existing information in the knowledge base and the database of facts and uses that information to reach conclusions or take actions. The inference engine derives new facts from existing facts using the rules of logic. The reasoning engine is a machine that processes the information. An XBRL Formula processor, if built correctly, can be a reasoning engine and can perform logical inference.
- Justification and explanation mechanism: When an answer to a problem is questionable, we tend to want to know the rationale behind the answer. If the rationale seems plausible, we tend to believe the answer. The justification and explanation mechanism explains and justifies how a conclusion or conclusions are reached. It walks you through which facts and which rules were used to reach a conclusion. The explanation mechanism is the results of processing the information using the rules processor/inference engine and justifies why the conclusion was reached. The explanation mechanism provides both provenance and transparency to the user of the expert system.
These four pieces are exposed to the users of the knowledge based system within software applications that is used by a business professional.
Software applications must provide all of these pieces. The law of irreducible complexitystates basically that "A single system which is composed of several interacting parts that contribute to the basic function, and where the removal of any one of the parts causes the system to effectively cease functioning." That means that each of the parts in the diagram need to exist for the system of an XBRL-based digital financial report to work correctly.
Further, the system must be usable by business professionals. The law of conservation of complexity essentially states, "Every software application has an inherent amount of irreducible complexity. That complexity cannot be removed from the software application. However, complexity can be moved. The question is: Who will have to deal with the complexity? Will it be the application user, the application developer, or the platform developer which the application leverages?"
Today's software applications do not provide all of these parts completely or in a form that is usable by business professionals creating intelligent XBRL-based digital financial reports. But when software does provide all of these pieces, two pivots will occur. The two graphics below show that the benefits of XBRL-based digital financial reporting will flip the dynamics of the financial reporting process. A disruptive innovation will occur. The barbaric processes used to create financial reports today will evolve and be replaced by new, better, faster, and cheaper processes.
These three things need to occur:
- More business domain knowledge in machine-readable form put into the knowledge base (rules).
- Better software applications which more precisely provide all the components of a knowledge based system in a form useable by business professionals.
- Business professionals need to learn a handful of things about knowledge engineering so that they don't need to rely of knowledge engineers or information technology professionals to create financial reports.
Blueprints made the flip to digital in the 1980s and 1990s. Do you believe these changes are possible for financial reporting?
Think artificial intelligence is just a buzzword? The following companies are members of the Partnership on AI:
- ACLU of Massachusetts
The following is the stated purpose of the partnership:
Established to study and formulate best practices on AI technologies, to advance the public’s understanding of AI, and to serve as an open platform for discussion and engagement about AI and its influences on people and society.
Don't be an information barbarian or fall for the hype of the snake oil salesmen. Learn about artificial intelligence. Articles such as Artificial Intelligence Demystified are good, but they don't help you understand how AI works. To truly understand capabilities, you have to understand how it works. Here are some helpful resources that business professionals can understand and that help you grasp how the technology actually works:
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.