This blog post pulls together into one place the information necessary to understand the framework and architecture that I use to create high-quality, high-fidelity, high-resolution XBRL-based financial reports. These same ideas can be applied to general business reports, what I call fact ledgers, accounting process automation, AI assisted audits, etc.
It is true that right now, this information is not particularly well organized. The reason for that is that I documented a lot of this as I was creating it. The lab notes that I created where periodically summarized and synthesized into a set of documents. I will go back and reorganize all of this at some point. This blog post pulls the most important information into one place.
So WHY did I create what I created? People have visions of "mirror worlds", "the finance factory", "financial transformation and the modern finance platform", "digital transformation", "continuous accounting", I could go on and on and on. But all of this things are just visions. How do you actually turn those visions into reality?
That is why I created what I created, to implement those visions. WHAT I created is a best practices-based, global standards-based, and open source tool for implementing that vision for accounting, reporting, auditing, and analysis. I am conscious of what it takes to make such a tool work effectively; this important information related to artificial intelligence and knowledge engineering. (Computer Empathy is an older version of that same information that has a little more detail in some areas.)
This global standards-based and open source tool was created using the engineering design process. Steps to create it were conscious, deliberate, and rigorous. Brick by brick, the pieces were put together.
One of the primary requirements is that the tool had to deliver high-quality, high-resolution machine-understandable information related to accounting, reporting, auditing, and analysis. Quality is paramount. The flexibility/variability inherent in this process has to be managed and controlled effectively so that quality remains high and reliable automated processes can be created.
Working top down, here is the most important information that is useful in understanding the approach that I am using to implement XBRL-based digital financial reporting:
Again, I am well aware that the organization of this information is not yet optimal. But this is what I currently have. Over time I will further distill, organize, summarize, and synthesized this information such that it is more useful. But, for now, this imperfect documentation gets the job done. Now that I have the right software tools, I can create the correct documentation.
I have implementations that prove this approach in US GAAP, IFRS, XASB (a reporting scheme I created for testing purposes), IPSAS, and FRF for SMEs. All of these implementations use exactly the same application profile.
All of what I have created can best be described as informally documenting a business report model. But this is in the process of being formally documented. What I have created will be “tuned” to adjust to the forthcoming OMG Standard Business Reporting Model (SBRM). SBRM will formally document a logical conceptualization of a business report in both human-readable and machine-readable models. I participated in creation of the SBRM RFP and I am on a team that is responding to that RFP.
There are now four software vendors that are consciously supporting my framework and architecture that I am aware of. There could be more, I don't know. This does not count the software vendors that support SBRM in the OMG working group.
Three of the four above implementations support the common conformance suite provided for this framework. The renderings of the pieces of a financial report are all very consistent and so the model of a business report looks literally identical in all three software applications.
This framework and architecture is based on the model of XBRL-based reports, both US GAAP and IFRS, that are submitted to the SEC. As such, 100% of those creating XBRL-based financial reports for public companies COULD be consistent with all of this framework, but because they cannot process the framework rules they have to check their business report logic manually rather than using automated processes. But, all of the approximately 20 software vendors are already consistent with most of this framework and architecture.
To be crystal clear here. A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things. This framework and architecture is about ONLY letting user use best practices and leveraging those best practices to create high-fidelity, high-resolution XBRL-based financial reports that are also high-quality. No magic; conscious attention to detail; good engineering.
Theoretical, philosophical, or religious debates have no role in determining the best way to implement XBRL-based digital financial reports. This is an engineering exercise.