Digital Financial Reporting

Distributed distributed ledgers (i.e. blockchain or otherwise) and XBRL are a match made in heaven.  Blockchain-anchored XBRL takes XBRL-based digital financial reporting to an entirely new level of usefulness.  Both transparency and trust are enhanced.

XBRL-based digital reports provide several capabilities: (1) a high-quality "payload" of machine readable reported facts, (2) a machine readable logical description of the "model" that payload, (3) machine readable declarative "rules" that help control processes and manage quality, and (4) a global standard technical syntax that enables the physical "transport" of the payload, model, and rules.

Digital distributed ledgers which a lot of people refer to as blockchain provides several additional capabilities: (1) an unchangeable record of a report transaction, (2) enhanced transparency because every detail can be tracked and repeated, (3) enhanced trust due to an inability to unintentionally or intentionally tamper with a report, (4) a plethora of service enhancements because of the enhanced transparency and trust.

While XBRL-based digital financial reports provide a high quality universal financial reporting framework that is both human-readable and machine-readable; general business reporting can benefit from the proven best practice based methods created for financial reporting.

I am not the only one that sees the benefits of blockchain, smart contracts, and the other "stuff" that makes up a digital distributed ledger.  XBRLChain has similar ideas. This one hour video explains what they are thinking.  Auditchain has their ideas which you can read in their white paper. Logical Contracts focuses on smart contracts that are logic-based declarative rules business professionals can understand (as contract to imperative or procedural software code as smart contracts).

If you don't understand the difference between imperative and declarative you should consider reading this article.

XBRLChain has a working prototype you can try.  I created a MOCK BLOCKCHAIN DIGITAL LEDGER to try and communicate my ideas. It does not actually work but it will give you an idea of what I am trying to achieve.

Logical Contracts has a prototype you can fiddle with related to smart contracts.

The Sustainability Accounting Standards Board (SASB) has published an XBRL Taxonomy that is worth having a look at.  This is the press release announcing the XBRL Taxonomy. Also, they are taking public comments.  You can download the SASB XBRL Taxonomy and fiddle with it, learn from it, test your software, etc.

If you want a quick way to look at the SASB XBRL Taxonomy (and you have a bit of patience as this page loads); this web page shows an overview of the  XBRL presentation relations of the entire XBRL taxonomy. (There are about 19,000 lines on the HTML page.)

You can get to the SASB XBRL Taxonomy terms online here:

https://s3-us-west-2.amazonaws.com/sasb.xbrl.taxonomy/sasb.xsd

Here is the SASB XBRL Taxonomy entry point:

https://s3-us-west-2.amazonaws.com/sasb.xbrl.taxonomy/sasb-entryPoint-all.xsd 

You can view the SASB XBRL taxonomy here.

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.