Digital Financial Reporting

When you build a structure, if the foundation of that structure is not sound and plum, the structure will not be sound.

About 15 years of effort has yielded both a proof of high level financial reporting semantics and an implementation of those semantics, the logic of a financial report, in the XBRL technical syntax. (Click the image below for a lager view)

This proof allows for many things.  First, the proof can be used to evaluate important XBRL taxonomies such as US GAAP, IFRS, UK GAAP, Australian IFRS, and others. My analysis shows taxonomy creation errors, taxonomy creation inconsistencies, and obvious missing pieces.

Second, the proof can help accountants understand and communicate about financial accounting, reporting, auditing, and analysis more effectively and precisely.  Fundamentally, all financial reporting schemes have the same foundation, see the Essence of Accounting.

Third, the proof can help you understand how to effectively convey information using the XBRL technical syntax.  For example, consider these different representations of exactly the same information: (i.e. each Inline XBRL report looks 100% the same) 

1. Reference Implementation: This is the basic reference implementation of the proof.  Note the organization and the abstract concepts that help organize the report model. (all information)
2. Reference Implementation Removing Abstract Concepts: This is the same facts as the first report but abstract concepts were not used to help organize the report model. The report is just a little harder to read but not that different. (all information)
3. Reference Implementation Removing Unnecessary Hypercubes: This report is also the same as the first but in addition to removing the abstract concepts, I also removed all hypercubes that are not required.  Again, the report does not look that different. (all information)
4. Reference Implementation Combining Hypercubes and Networks: This report is likewise the same as the first but in addition to removing abstract concepts and hypercubes, I combined information within networks somewhat arbitrarily where the combination caused no conflicts.  As you can see by looking at the report, it becomes harder to understand and sometimes even confusing. (all information)

What is my point?  Well, there are several points.  First, each Inline XBRL report looks identical.  Second, whether you include or exclude an abstract concept is a preference.  Third, whether you use a hypercube in some cases is a preference but other times hypercubes are REQUIRED because you must add noncore dimensions and that can only be done when you use a hypercube.  Finally, how you organize information into networks is sometimes a preference, but other times you simply cannot combined disclosed information because conflicts would occur (i.e. that is WHY networks exist, to avoid those information conflicts).

While using things that are preferences can yield elegant looking XBRL-based financial reports and not using them can yield ugly and hard to read reports; these preferences do not impact the meaning conveyed by the XBRL-based financial report.

But being logical is not a preference or a subjective decision.  Being logical is objective and can be measured.  For example, these rules related to mathematical relationships in each of the four reports yield the exact same verification results in any of the four reports shown above.  That proves that the logic of the report does not change when you do, or do not, add abstract concepts or certain hypercubes or put a disclosure in one network as opposed to some other network.

No one really disputes these high level financial report sematics.  No one can really dispute the XBRL-based representation of those semantics either; simply running the reports through an XBRL processor and XBRL formula processor indicates whether something is consistent or inconsistent with the XBRL technical specification.

You can have a preference for whether you want to represent a prior period adjustment using one of the two approaches I provide in this PROOF.  You can even perhaps create another way to represent that same disclosure and prove that your new way also works.  You can prove that your new approach interacts with each and every other piece of a report.

But you cannot dispute the fact that the PROOF works and is consistent with the rules of accounting.

##################################

Fundamentals

I have updated and improved what I am calling my PROOF BASELINE.  Sometimes people think fast and shallow.  Other times people thing slow and deep.  For the past 15 or so years I have been thinking slowly and deeply about XBRL-based financial reporting.  I have taken all the information I have accumulated, synthesized that information into this PROOF BASELINE and using a theory, framework, and method based on proven best practices and global standard XBRL figured out one way to make XBRL-based digital financial reporting work. (Click image for larger view)

The updates and improvements include: 

• Synchronizing the representation of the financial reporting scheme knowledge graph, financial report model, and toolkit for scrutinizing reports to be sure they are properly functioning.
• Settled on terminology that will be used.
• Incorporated the ideas of the OMG Standard Business Report Model.
• Created a more complete set of examples that exercises and proves the theory, framework, and method.

I am not holding out this approach to be the only approach or even the absolutely best approach.  This is more of a starting point than the end game.  I have shown that XBRL-based digital financial reporting can work and I have not seen anything that works better to meet the use case of US GAAP or IFRS based financial reporting where report models can be changed and therefore must be controlled to maintain high quality.

Believe it or not, the PROOF BASELINE not only incorporates all complexity that you would find in any US GAAP or IFRS financial report; it is also reconciled to US GAAP, IFRS, UK GAAP, and Australian IFRS.  All of this is rigorously and thoroughly tested using four different software applications including: 

• Pacioli
• XBRL Cloud
• Pesseract
• XBRLQuery

Finally, using this theory, framework, and method significanlty reduces software development time at the same time information quality is enhanced.

Stay tuned for more information.

You can now get a Neo4j database in the cloud for $.09 per hour of operation.  I am fiddling around with the graph database using my accounting knowledge graph examples.

Most accountants don't recognize this yet, but many of the current practices used for creating financial reports are obsolete.  It is true that a new paradigm has not yet been fully and completely worked out yet but that new paradigm is well on it's way.

Remember the good ole days when we used to create financial reports using clay tablets?

Accounting and reporting has moved beyond clay tablet first to papyrus then to paper.  In the 1970s and 1980s, paper was replaced by word processors and electronic spreadsheets.  Effectively "e-paper".  Now we are moving to digital.

Single entry ledgers were improved by using two synchronized ledgers (i.e. double entry accounting).  Double entry ledgers are about to be improved by adding a third synchronized ledger (i.e. triple entry accounting).

It is time for the next step in the evolution of accounting and the financial report.  No one can really say with certainty what the next step in this evolution will bring, but there are a few things that are certain. 

1. Some sort of change is inevitable.
2. Modern technologies exist that will be employed such as artificial intelligence, structured information, digital distributed ledgers, knowledge graphs, etc.
3. The same technologies that cause the problems of information overload and information complexity will be used to solve those same problems.
4. Standards will play a significant role. 

Here are a few prototypes that I have created that help accountants understand that change is inevitable and what these new accounting, reporting, auditing, and analysis tools might look like. 

• Pacioli, a Toolbox for Auditors: If an accountant cannot prove to themselves or to others that something like an XBRL-based financial report is (a) properly functioning and (b) conveying the meaning that is intended to be conveyed; then digital financial reporting is a non-starter. So, that tool for making sure financial reports are correct is fundamentally necessary.
• Pesseract, an Expert System for Creating Financial Reports: The creation of financial reports needs to be "self-service", meaning accountants need to be able to fundamentally create the reports.  Pesseract is a working proof of concept for creating XBRL-based digital financial reports. (If you are an accountant and want a license to try this software out, please contact me and I will send you a license good for one year.)  This free, open source tool can get you started with understanding digital financial reports.
• Financial Reporting Metadata: Without high-quality metadata, digital financial reporting is a non-starter because it would be impossible to (a) meet the demands of robust financial reporting schemes such as US GAAP, IFRS, and others and (b) make it impossible to create software applications that are easy enough for the average professional accountant to use.
• Proven, Best Practices based Framework and Method: Accounting, reporting, auditing, and analysis is complex.  If you read through the Essence of Accounting you will understand the specific complexities.  Per the law of conservation of complexity you cannot remove complexity from a system; however, you can move the complexity around.  Being smart and clever plus hiding complexity from end users can make XBRL-based digital financial reporting work effectively and be easy to use. Per the notion of irreducible complexity, you cannot simply remove something that is necessary from a system and expect that system to work effectively.  Removing complexity is not an alternative, but hiding complexity can work effectively.  My method shows you how to achieve this. My framework and method works effectively per implementations in four software applications: Logical Contract's Pacioli, XBRL Cloud's Evidence Package, XBRLQuery, and Pesseract which is a working proof of concept.

Here is an example of what is achievable.  Because of the mathematical foundations of double entry accounting it is particularly well suited to leveraging computers to achieve work.  And while it is the case that accounting, reporting, auditing, and analysis will be the first areas of knowledge to digitize because they are so well suited; they will not be the last.  Computational Professional Services is a real thing. Think electronic semantic spreadsheet.

Things are already changing; the signs are all around you if you look.  Be careful not to hold on to obsolete practices too long as that can reduce your value. Here is everything you need to master XBRL-based digital financial reporting.

Here are two very good FREE resources for understanding knowledge graphs and graph databases.  O'Reilly is publishing a book, Graph Databases, which can be downloaded for free.  It has a few ads from Neo4j at the very beginning.

Neo4j provides the Neo4j Sandbox which is a cloud-based graph database implementation that you can spin up in your web browser.  To get started with Neo4j you can watch this video (about 15 minutes) and/or work through this Neo4j tutorial.

There are plenty of other graph databases such as TigerGraph and Grakn.  Each has pros and cons.  I will use Neo4j to provide some examples for you.

The Neo4j syntax is Cypher.  Here is a Cypher example that you can load into Neo4j for the FASB's SFAC 6 Elements of Financial Statements. When you load the Cypher example, it will look something like this in Neo4j: (Click image for larger view)

As I pointed out, accounting is an area of knowledge that can be organized into a knowledge graph. There are principles for using knowledge graphs properly. The Cypher syntax is one approach to organizing and using this information.  XBRL is another.  Prolog is another.  You can convert bidirectionally between Cypher, XBRL, Prolog, and RDF+OWL+SHACL.

Here is my Logical Theory Describing Financial Report.  Here is the essence of that theory represented in Cypher syntax. When you put the Cypher into the Neo4j graph database sandbox, it will look like this: (click image for larger view)

Another view of the same information is this representation in Javascript. Here is that same information in the XBRL syntax. This is a human readable rendering of the XBRL.

XBRL is both machine-readable and can be easily converted to machine-readable.  XBRL syntax can be converted to the technical syntax of your choice.  What is consistent between all of these representations is the logic that is represented.

If you distill accounting down to its essence the importance and potential ramifications of all this becomes quite clear.  If you want to learn how to represent information using XBRL, here are the essentials. Here are a bunch of really good accounting related examples. Here is what you need to master XBRL-based digital financial reporting.

Don't be left behind.