BLOG: Digital Financial Reporting
This is a blog for information relating to digital financial reporting. This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting. This is my brain storming platform. This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.
Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.
Entries from October 1, 2019 - October 31, 2019
Global Standard Machine-Readable Logic Framework for Business
My testing of XBRL-based digital financial reports has lead me to the point where it is pretty obvious that there would be great benefits to business if there were a global standard machine-readable logic framework for business.
This is what I mean. There are many domains that use logic. Philosophers invented logic and tend to use propositional logic, electrical engineers use logic gates to design electronic circuit, designers of complex systems like nuclear power plants use Z-notation, computer scientists use predicate logic which is an extension of propositional logic, etc.
But why does business not really have a logic framework? Perhaps it is not a fair or even appropriate comparison. But it might be. Business professionals use electronic spreadsheets for solving all sorts of problems. The electronic spreadsheet is more of a presentation-oriented (sheet, column, row) modeling tool as contrast to a logic modeling tool.
Let us suppose that business professionals needed some sort of logic modeling tool. What terminology might that tool use? There is no real standard terminology for working with logic that I have seen. However, the terminology can be created. If I were to create standard terminology, the terms would be: theory, model, structure, term, association, assertion, and fact. These are all statements. All these statements need to be complete, valid, consistent, and sound. The system needs to be fully expressed. Graphically, I created the following depiction: (here are the definitions of the terms used)
Now, this graphic communicates an idea, not a logical thing that can be measured. I would like to come up with a better graphic.
Think of this as a complete set of statements that have to be consistent and everything has to be valid and if you achieve this then the system is sound. If all those four constraints are met and the system is fully expressed, then the system is functioning properly. Two different people can look at the same set of statements and reach the same conclusion.
What is more, you can prove that the system is functioning properly, the full set of statements is like a “parity check” or a “check sum”.
I see this as having similarities to the double-entry accounting system.
Single-entry accounting is how 'everyone' would do accounting. In fact, that is how accounting was done before double-entry accounting was invented. Double-entry accounting adds an additional important property to the accounting system, that of a clear strategy to identify errors and to remove the errors from the system. Even better, double-entry accounting has a side effect of clearly firewalling errors as either accident or fraud. This then leads to an audit strategy. Double-entry accounting is how professional accountants do accounting. Double-entry accounting was the invention of medieval merchants and was first documented by the Italian mathematician and Franciscan Friar Luca Pacioli.
Double-entry accounting is one of the greatest discoveries of commerce and its significance is difficult to overstate. Which came first, double-entry accounting or the enterprise? Was it double-entry accounting and what it offered that enable the large enterprise to exist; or did the large enterprise create the need for double-entry accounting?
The key idea here is the “clear strategy to identify errors and remove errors from the system”.
This is what I see some sort of global standard machine-readable logic framework for business doing. If the logic of the system has no boundaries what-so-ever; then who is to say if something is right or wrong? If you cannot determine if something is right or wrong; then how could it possibly be of any use?
Here is all my current brainstorming that I have done on this topic. More is still to come.
####################




PWC to Invest $3 Billion in Upgrading Skills
Accounting Today, PwC invests $3B in "New World, New Skills" Program:
Big Four firm PwC is launching a new program, entitled “New World, New Skills,” that will focus on the growing mismatch between people’s existing skills and the new skills demanded by the digital economy. The firm will invest $3 billion over the next four years in upskilling — primarily in training PwC staff, but also in developing and sharing technologies to support clients and communities.
The digital revolution requires a skills revolution. The skills revolution is about helping people build their digital awareness, understanding and skills to fully participate in the digital world — and it needs to start now.
Do you want to upgrade your skills? It is time for professional accountants to understand digital financial reporting. Start here, Artificial Intelligence and Knowledge Engineering in a Nutshell. Also see Digital Maturity.




Proving Accounting, Structural, Mathematical, and Other Logic of XBRL-based Financial Reports
There are nine specific identifiable situations which occur in XBRL-based financial reports which cause accounting logic, mathematical logic, structural logic, or other types of logical errors. The document Proving Accounting, Structural, Mathematical, and Other Logic of XBRL-based Financial Reports explains each of these situations and explains how to eliminate the situation.
Here is a summary of the nine situations:
- Using an existing base taxonomy concept intended to represent one class of concept inadvertently to represent some other class of concept.
- Lack of clarity of the meaning of extension concepts.
- Unreported high-level subtotals.
- Variability allowed for reporting high-level accounting relationships.
- High-level financial report line item inconsistencies and contradictions.
- Presentation relations model structure relations illogical.
- Verification that each report fragment is created correctly.
- Mathematical relations are not explained using machine-readable rules and then verified against that machine-readable explanation.
- Verification that each report fragment that is required to be disclosure exists within the financial report.
All of these nine situations are observable in the thousands and thousands of XBRL-based financial reports that have been submitted to the U.S. Securities and Exchange Commission. XBRL Cloud provides what the call the Edgar Dashboard which shows summaries for many of these situations.
It is highly likely that ESMA is going to repeat many of these same sorts of errors. While the ESMA has done some additional things such as added anchoring, they have not consciously engineered a system which eliminates each of these situations. Therefore, they will experience errors and quality issues.
Consider something. Let us turn all of this around. Let us wonder what might happen if someone implemented XBRL-based financial reporting, they used an architecture similar to the SEC, they adjusted the SEC architecture to add the features articulated in the PDF that explains how to eliminate all of those situations/issues. Perhaps they add a few additional best practices that have been proven over the past 10 years of submitting XBRL-based reports to the SEC.
What would you get? Well, you would get a much better system that has higher quality XBRL-based reports. This video walks you through how software can leverage rules and use automated machine-based processes to (a) explain what "correct" looks like, verify that a report is consistent with that explanation, and (c) be used by those wishing to extract information from such report effectively and reliably.
This video playlist shows a working proof of concept that demonstates XBRL-based financial reporting does not need to be "technical" and "complex". It actually can be simple and elegant.
#########################




Revisiting the Knowledge Representation Spectrum
I discussed the knowledge spectrum and reasoning capacity in another blog post several years ago. It is time to have another look.
This graphic from Mills Davis' presentation AI - Externalization of the Mind, slide 66, depicts the relationship between knowledge representationn and reasoning capacity:
(Click image for larger view)
So, there is a little more to achieving the capability of a machine to reason. Yes, you do need an approach to representing knowledge such that a machine, such as a computer, can leverage that knowledge to perform useful work.
- You need a global standard technical format to represent the knowledge. (i.e. XBRL)
- You need standard models that you use to represent the knowledge. (i.e. business report model)
- You need to put knowledge into that format using that model. (i.e. FRF for SMEs; US GAAP)
- You need standard software that can read the knowledge that exists in that technical format and perform the required work. (i.e. Pesseract; XBRL Query; XBRL Cloud)
- You need to prove interoperability between standard software. (i.e. comparison of Pesseract, XBRL Query, XBRL Cloud; conformance suite)
Once you have all five things above, then you simply have a commodity; you have all the pieces of the "mouse trap" (law of irreducible complexity). One should be able to demonstrate why the system works. Here is my demonstration: machine-readable | human readable.
A kluge, a term from the engineering and computer science world, refers to something that is convoluted and messy but gets the job done. Anyone can create something that is complex. But it is hard work to create something that is simple.
Welcome to the Fourth Industrial Revolution! Do you and your organization have the digital maturity necessary to compete? Are you a novice or an expert? What will you create? What role will you play? Do you need to improve your digital maturity?





Understanding the Possibilities Offered by Logic Programming
SWI-Prolog is an interesting tool. The book Simply Logical helps you understand how to use SWI-Prolog. The book makes use of an online application SWISH to demonstrate SWI-Prolog and logic programming.
SWISH is an online, collaborative tool for learning about and using logic programming. This resource, Using SWISH to realise interactive web based tutorials for logic based languages, is also incredibly helpful in appreciating SWISH and SWI-Prolog.
Here is a basic, quick and easy explanation of how to use SWISH. But before you walk though the explanation, click on the image below and just look at the graphic which will help you see what you are doing:
The steps are the following: First, click on this URL to open up an example. Second, copy and paste the query "houses(Houses)" into the query window as shown, and then press the blue "Run" button in the lower right hand corner.
Notice the table that appears.
Don't misinterpret what you are observing! This is NOT about getting accountants to write the ugly looking syntax on the LEFT. This is about creating a rock-solid and crystal-clear logical model of a financial report so that programmers can do what appear to be magical things like the table that appears on the RIGHT.
If a financial report has no high-level logical model that is explained in terms a business professional can understand, then you are STUCK USING THE UGLY LOW-LEVEL XBRL TECHNICAL SYNTAX!!! It is really that simple and straight forward.
Yes, some accountants will learn the low-level logic programming. Maybe some auditors also. But this will be a small portion of accountants and auditors. A few people create the tools; millions of accountants use the tools.
This is about helping professional accountants and auditors to understand that for software engineers to do a good job, they need something like the four clear logical models that I use to describe a financial report.
It is incredibly dumb for each regulator to invent their own implementation of XBRL. Proof of this is that the SEC cannot seem to get XBRL-based reports to be of the required quality, each regulator impementation is slightly different, and no one is really very pleased with the software that they are provided to create XBRL-based reports.
This is the problem the OMG Standard Business Report Model (SBRM) is trying to solve. SBRM provides the needed logical conceptulization of a business report and allows for standard metadata (like this) to be created and then leveraged. All this is explained here.
Also, I am NOT SAYING that SWI-Prolog is the right logic programming language. As I understand it (a) prolog is backward chaining which is limited and we need forward chaining or forward AND backward chaining; (b) DATALOG is a safer version of PROLOG; (c) other alternatives exist such as answer set programming and Logtalk or CLIPS or even in other languages.
++++++++++++++++++++++++++++



