This blog post builds upon the post Digitizing Disclosures (Part 1). In Part 1 I shows that a disclosure can be broken down into pieces. Some people call this "structured", I call it "digitizing" the information. In this part I try and paint the big picture and point out the advantages of digital financial reporting and point out where we fall short today. Part 3 will show exactly how disclosures are digitized, how business rules help quality, and how to create an automated digital version of a disclosure checklist.
This is a summary of the pieces which you want to keep straight in your mind.
First, external financial reporting managers and other such accountants create reports such as financial reports. I am focusing on financial reports as an example because I am an accountant. But these ideas also follow for other types of reports.
Second, these reports are can be very complex. There is lots of information which must be correct, complete, consistent, and accurate. To make a mistake is to risk noncompliance with laws/regulations. How do the accountants who create and publish this information get the job done?
- Vast amounts of knowledge and skill they have crammed into their brain
- Resources which the accountants use to find the things that don't know off the top of their head, for example a disclosure checklist which they use as a memory jogger
- Lots and lots of manual effort
- Software publishing tools which has zero knowledge of financial reporting; these tools may have some information extraction capabilities and/or content management capabilities, but they truly know nothing about financial reporting
Why is this process used? Well, because up until now there has been no other alternative. How might this alternative work:
- Take as much knowledge of financial reporting as possible (necessary) and put that information in not only human readable form, but also into machine readable form
- Take other resources which accountants use and put that into human readable and machine readable form also
- Manual effort, but replace as much manual effort as possible with automated processes
- Use software which leverages the machine readable information which has been expressed about how to correctly, completely, consistently and accurately create a financial report and therefore can appear to understand financial reporting and actively assist and even guide an accountant through that process of creating a financial report
Note that I am NOT saying that this process will be 100% automated, NOT saying that computer will exercise judgment because they cannot, NOT saying professionals will be eliminated from the process; what I am saying is that what can and should be automated will be automated and what cannot be automated or should be manual will be manually performed by humans.
How is this possible? Magic? There is zero magic involved. Artificial intelligence? No artificial intelligence at work. Hard work and attention to detail? Lots of that. Beating down complexity by simplifying as much as possible? Yes. And I don't mean make things simplistic. Simplicity and elegance are the ultimate sophistication. Simplifying is extremely hard work.
This graphic explains visually how this will be achieved:
(Click image for larger view)
Here is the narrative with walks you through the graphic.
First, there are a lot of different ways to express information in a machine readable format: CSV, Excel, JSON, XML, XML plus an XML Schema, RDF, RDF with a schema, RDF with a schema and ontology, or XBRL. The XBRL syntax is a global standard format for doing this.
Next, you take all the things which make up a financial report and you express them in a machine readable form, such as the way the US GAAP XBRL Taxonomy does this for US GAAP and the IFRS XBRL Taxonomy does this for IFRS. Eventually other taxonomies will do this same thing for State and Local Governmental financial reporting. The specific format matters less, what matters more is how much meaning or "semantics" which you can pack into machine readable form. You need all the "things" and the "relations between the things" which make up a financial report. Not everything related to accounting and reporting, just the stuff that ends up in a report.
If you notice the graphic, you can see that there is a correlation between the level of semantics (weak or strong) and the reasoning capacity of a machine such as a computer (low or high).
Part of the necessary semantics are the relations between the things in a financial report. One of the things which plagues SEC XBRL financial filings to day are errors in the relationships. The following succinct statement summarizes the reason why data quality problems exist in SEC XBRL financial filings:
The only way a meaningful exchange of information can occur is the prior existence of agreed upon technical syntax rules, domain semantics rules, and workflow/process rules.
Digitizing disclosures has little to do with XBRL mandates.
An external financial reporting manager needs to create external financial reports in an efficient and effective manner and insure compliance with legal requirements to minimize the risk of lawsuit, regulatory non-compliance, other reporting error, or other risk factor. Software companies began creating disclosure management software long before the SEC mandated reporting by public companies in the XBRL format. Clarity (now IBM FRS), Hyperion (now owned by Oracle), cundus (now owned by SAP), WebFilings, Trintech and others all were creating disclosure management systems before they retrofitted their software to support XBRL.
But each of these software solutions, while they can output XBRL formatted financial reports; none of these systems actually understands financial reporting semantics. This software does not fit the digital financial reporting bill because it does not provide the necessary functionality. For example, none of these software products, to the best of my knowledge, offers a digitized disclosure checklist which replaces the manual "memory jogger" approach.
I would argue that the market for disclosure management software, if it provided the correct functionality, is not the 10,000 public companies which file with the SEC. I personally see the market as being approximately the following in the United States alone:
- Those 10,000 public companies
- Private companies who provide audited or reviewed financial statements in support of commercial loans, I hear that there are between 14,000,000 and 24,000,000
- Not for profits who provide audits in support of grants, about 360,000 as I understand it
- State and local governmental entities required to create financial reports, about 90,000
But none of these reporting entities would ever purchase software that works the way software works today for creating SEC XBRL financial filings. That software provides no real benefit when working with structured information, only additional work. And besides, there is another problem: quality.
The XBRL syntax is fine, 99.9% of SEC XBRL financial filings have the proper XBRLtechnical syntax. Domain semantic rules are not even remotely sufficient, however, so the SEC XBRL financial filings have a boatload of quality problems. See the quote above, pretty straight forward. You can tell by the patterns in the errors that not one software application has the processes in place to systematically detect errors. Software has systemic process problems.
So, that is why quality issues exist in SEC XBRL financial filings, missing domain semantics rules or "business rules" they are commonly called. Plus, even if they magically existed, the software does not leverage those rules. The best that software today could do is run the rules after the digital financial report is created. That is helpful in creating proper XBRLformatted financial reports, but it is of no help in actually creating the report in the first place. The XBRL formatting is simply bolting on additional work to the end of an already complex process. What needs to change are the fundamental work practices.
Seem impossible? It is not impossible. Two things are necessary to make digital financial reporting work: (a) the metadata which assures a meaningful information exchange and (b) software which understands and leverages the metadata to guide the accountant in the process of creating a financial report. The software will be simple to use but will provide sophisticated functionality because the complexity of dealing with the thousands and thousands of individual pieces of a structured report and the relations between the structures are managed, behind the scenes, by the software.
While validation software such as XBRL Cloud's Edgar Dashboard or the SECXBRL.info validation of basic financial information is helpful, that validation needs to be imbedded in software so the software will not let business users make these mistakes. Further, this validation must be comprehensive. Rather than covering, for example, a set of minimum criteria; all aspects of every disclosure must be verified by creation software.
As I will show in Part 3 of this series, there is not that much of a difference between verifying the minimum criteria and verifying disclosures. Stay tuned.
To start thinking about this "digitation" process, first take a look at this HTML and this XML (here is a rendered version of the XML if you don't understand how to read the XML).