Digital Financial Reporting

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:

• Example Implementation: This is an example implementation of a financial reporting scheme, FRF for SMEs, using this tool.  It helps you see the end result. (Note the bottom of the HOME page for example reports. Here are examples for five different financial reporting schemes. Here are some inline XBRL examples.)
• Framework and Theory: This is the framework and theory that was used to create the tool.
• Method: Included in that framework and theory is the method I used to create the example implementation.
• Technical Description of Framework: This document provides a technical description of the open source framework that is used to implement this tool for accounting, reporting, auditing, and analysis.
• Accounting, Reporting, Auditing, and Analysis Application Profile: This document provides documentation of the XBRL application profile that is used to implement the technical framework.  The XBRL application profile documents the restrictions imposed on the XBRL technical syntax use and approaches to using XBRL when alternatives exist.
• XBRL Technical Specifications: All of the above is built on top of and 100% consistent with the global standard XBRL technical specifications.  This includes XBRL 2.1, XBRL Dimensions, XBRL Formula, Inline XBRL, the XBRL Link Role Registry, and other supporting specifications.

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.

• Pessearct is a working proof of concept that a software engineer and I have created to test and prove this framework and architecture.  Pesseract is 100% consistent with this architecture, supports all five reporting schemes, and is an incredibly robust and useful application which is being used by some in the process of creating XBRL-based reports that are submitted to the SEC.  We are working to turn Pesseract into one or more commercial products.  Pesseract is free to download and use for noncommercial purposes.
• XBRL Cloud is about 98% consistent with this framework and architecture in terms of precision and completeness.  XBRL Cloud supports three of the five reporting  schemes that I have created and two of the reporting schemes, US GAAP and IFRS, are used to verify the quality of XBRL-based financial reports submitted to the SEC by public companies.  XBRL Cloud performs all the validation and processing for my quarterly quality measurements of XBRL-based financial reports submitted to the SEC.
• XBRL Query has been supporting this framework and architecture for about 9 months. If nothing else, this framework has contributed to the tuning of this high-quality open source XBRL processor.
• Lodgeit cut their teeth on XBRL in the Australia SBR project.  They totally get the vision and have contributed to my thinking in many ways. That is all I will say for now.
  

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.