Digital Financial Reporting

I am experimenting with a new prototype format.  I am using bootstrap.  Here is a resource for leaning about bootstrap.  I use these Glyphicons.

Here are some examples:

• Disclosures

I am trying to figure out how to incorporate all these other things into that one resource:

• Balance sheet; Income statement; Cash flow statement
• Cross reference
• Topics; Disclosures
• Older Ontology Format

In a prior blog postI made people aware of the OMG's Standard Business Report Model (SBRM).

So, what exactly is SBRM?  What problem does it solve?  Does it re-invent XBRL?  Is it a replacement for XBRL?  Is SBRM really necessary?

Here is how to look at the OMG Standard Business Report Model (SBRM): 

• Do you want information exchange to be a technical problem that computer scientists make money solving or do you want it to be a business problem where business professionals can make money? 
• Do you want each implementation of XBRL to be a unique, individual one-off point solution, reinventing the same wheel different over, and over, and over again; or do you want to solve the problem once and repeat that same proven and tested high-quality solution over and over? 
• Do you want individual technical professionals that really are not that experienced with XBRL to engineer what will likely be a sub-standard solution or do you want a group of world-class of software engineers to collaborate, solve the problems effectively and then let less skilled software developers use that world class standard solution?

Those are the sorts of problems that SBRM addresses.  SBRM is not a replacement for XBRL, SBRM is a necessary supplement to XBRL.  Read the problem statement of the RFP (section 6.1, pages 19 and 26).

In a world without SBRM, the world we have today, it takes technical professionals with world class experience to get XBRL to work correctly, each technical professional basically creating a one-off point solution that is commonly poorly engineered because they don't have a deep understanding of XBRL.  Plus, you still need business professionals with extensive skills knowledge engineering skills that they don't currently have to create low-level metadata without the assistance of high-level metadata and no real "instructions" that are helpful in getting their XBRL taxonomies to work effectively and per their expectations. 

Just look at what is going on with the US GAAP XBRL Taxonomy and the IFRS XBRL Taxonomy.  Both are incredibly important but currently sub-standard.  The business professionals mucked up the XBRL taxonomies because they don't consciously understand the knowledge engineering rules that make such a taxonomy work effectively.  And because of the errors and omissions of the US GAAP and IFRS XBRL taxonomies you get errors in XBRL-based financial reports that are submitted to the SEC. 

The only way anyone can possibly disagree with these observations is for them to be ignorant of the facts or in denial of reality.

But SBRM, or something like SBRM, changes all of this. 

In a world with SBRM or something like it, technical professionals with world class experience create a standard approach to impending XBRL-based reporting; a framework, a metamodel, and instructions. Other technical professionals with only average skills can then construct software applications using commonly understood techniques and practices; and those lesser skilled software developers can leverage the framework, metamodel, and instructions provided by SBRM, or something like it.  This yields software applications that actually work effectively and where the technical aspects of information exchange is buried deep within software applications, exposing only logical problems to business professionals to solve.  Business professionals already have an innate understanding of logic to solving logical problems.  But, with about one day's worth of training (literally) and the right software applications created using the SBRM metamodel, framework, and method; business professionals such as accountants can effectively create high-quality, high-resolution XBRL-based financial reports consistently and correctly without ever having to wade into the technology or asking an information technology professional for assistance.

That is what SBRM is about.

I know that all of this is true.  How do I know?  Do I have some special skill to understand all this?  No.  I have actually created such software (a working proof of concept) and the high-level metadata for four different reporting schemes, a method for achieving success, a metamodel, a framework, and a logical theory that describes how all this works.  And so, I already have "something like SBRM" already working, tested, and proven.  A software engineer and I used these ideas and techniques to create a working prototype expert system for creating a financial report.

And so that is why having SBRM is desirable.  It will mean more work for me because I have to adjust my implementation to be consistent with what SBRM becomes.  But, I am confident that SBRM will be better than what I have created because I am conscious of the fact that I am not a world-class engineer.  But, what I have created does work thanks to the 10 years I spend in meetings participating in the process of creating XBRL and another 10 years hammering on XBRL-based financial reports that are being submitted to the SEC.

Certain people have the experience and imagination to understand all of this simply by having this information explained to them.  But the average professional accountant cannot, they need something more tangible. So, once someone can demonstrate such software, it will be easy for the average professional accountant to understand all of this.  I will have that software (a working proof of concept) within weeks.  I already have the metadata (enough for a working proof of concept), and a framework for creating more metadata, and a method for making all of this work.  It will now become trivial to demonstrate these ideas and perhaps convince average business professionals of these details and the utility of XBRL-based digital financial reports.

OMG did not come to me and say, "Let's build SBRM".  The way it worked was OMG came to me to explain XBRL to them at an OMG conference in Seattle last December.  I asked the OMG members what they already knew about XBRL.  Those OMG members had some big misconceptions as to what XBRL really was.  I invited a technical person who I commonly collaborate with, Rene van Egmond, to come with me and help me explain XBRL to the folks at OMG.  Rene discussed the problems that standardized business reporting (SBR) implementations were commonly experiencing (i.e. one off point solutions, not properly engineered, not really standard) and the need for a true standard approach to implementing XBRL within an enterprise.  OMG pointed out that some enterprises had a preference for RDF and OWL or JSON LD.

And so, again, that is what SBRM is intended to become.  SBRM is a metamodel (perhaps even a meta-metamodel), a method, and a framework that consistently yields high-quality with high-resolution by providing a proven, tested framework that outlines the "guard rails" or "bumpers" as some people call them. SBRM forces every XBRL implementation to "stay within the lines" when they are coloring.  SBRM forces conscious decisions as to where you need to be on the ontology spectrum to meet the needs of your application.  SBRM shows a conscious understanding that there are multiple technlogy stacks that people can choose from and have arbitrary preferences for.

SBRM is about accounting, reporting, auditing, and analysis within a digital environment within the enterprise.  This blog post highlights 10 use cases such as Deloitte's vision of The Finance Factory or Blackline's vision of the "modern finance platform", the vision of "AI assisted audits", PWC's vision, and DFIN's vision.  There is one thing in common with all of these things...they are visions.  They are not yet real.  SBRM will contribute to making these visions real. 

If you are not following this, I would strongly encourage you to read the document Computer Empathy.  It is that information that helped me put all of these pieces of the information exchange puzzle together.  That information might help you understand better.

In December 2018 I gave a presentation to the FIBO working group of OMG a presentation about XBRL.  That presentation started a chain of events. That chain of events led to the creation of SBRM. This two page summary describes SBRM as:

SBRM formally documents a logical conceptulization of a business report in both human-readable and machine-readable models.

The Object Management Group (OMG) has issued a request for proposal for the creation of Standard Business Report Model (SBRM). You can find information about the SBRM working group here.

You can download the SBRM RFP here.

The purpose of SBRM is to define business reports in terms of the logical components of a business report (structure and facts).  This is as contrast to defining a report using technical terms that are alien to most business professionals.

This is achieved by specifying a Standard Business Report Model (SBRM) that includes a metamodel for generic representations of report definitions (including component structure, patterns and rules) and report submissions; and can be linked to independent information models or ontologies and transformed into different technical formats including XBRL and Inline XBRL.  Other targeted formats are RDF and OWL and JSON-LD.

Essentially, SBRM is similar in nature to an application profile of XBRL.  It helps people implementing XBRL become more conscious of what they are doing.  For example, becoming aware of the ontology spectrum. Today, people creating XBRL taxonomies tend to not employ XBRL as effectively as it could be employed.

Some of the best insight provided by the RFP can be gleaned by looking at the reporting scenario categories of standard business reporting:

1. the data set collection scenario: in this case the regulator requests a table of a predefined structure. The scenario doesn't require any structure for the business report type other than a single table form with predefined columns for collected facts.
2. the data form collection scenario: in this case the regulator has defined a form that has every data point uniquely defined and there is a presentation aspect to the solution such as predefined labels for the facts and predefined report rules about the facts.
3. the semi-extensible report scenario: in this case the regulator defines structural components and required facts and the reporting entity is allowed to extend the content of the report with additional details at given positions in the report.
4. the extensible report scenario: in this case the regulator doesn't prescribe the structure of the report but the reporting entity needs to comply with externally defined domain-specific reporting principles that might include variability of reported information (i.e. not a form); the ability of reporting entities to reconfigure the model (which they must do correctly); add additional information within the existing model (i.e. extend the model); and not reporting certain specific line items which leads to the need to use deductive logic to impute unreported line items during analysis,
5. spreadsheet: in this case regulators and organizations replace the exchange of presentation-based spreadsheets (workbooks, worksheets, rows, columns, cells) with meaning-based reports (facts, dimensions, controlled vocabulary, rules, relations) which might then be rendered statically (similar in appearance to a spreadsheet) or dynamically (similar to a pivot table).

That is basically the spectrum of business reporting use cases.  My interest is primarily #4 and also #5.

What OMG is explicitly acknowledging here is that (a) business reporting is a spectrum and that (b) the use cases fit somewhere on the ontology spectrum.  The use case itself "picks" where you need to be on the ontology spectrum.  Many people creating XBRL taxonomies or systems are completely oblivious as to the existence of the ontology spectrum or what it takes to exist at some specific point within that spectrum.  The result is quality problems.

This blog post explains all this in terms of XBRL-based digital financial reports.

Another thing that the OMG RFP does extremely well is explain something like XBRL in context of the enterprise.  XBRL-based reporting has to work correctly to be useful internally within an organization.  It has to be easy enough for business professionals and accounting professionals to approach and make use of the technology.  Forcing business and accounting professionals to learn technical details simply will not work.  Software engineers need to be smarter about implementing things like XBRL-based financial reporting and other business reporting use cases.

I predict that the next three years will bring profound change to the world of "XBRL".

For more information about SBRM see the SBRM wiki provided by OMG.  If you are a member of OMG and are going to respond to the RFP, let me know.  If you are not a member of OMG and want to be on a response team contact me and I will help you get on a team.

Essentially, this is where I think SBRM will go, something similar to my implementation of the Logical Theory Describing a Business Report that I created using pure, 100% global standard XBRL:

• Framework: Open Source Framework for Implementing XBRL-based Digital Financial Reporting
• Entities and relations: Logical model: Logical model
• Method: Method of Implementing a Standard Digital Financial Report Using the XBRL Syntax
• Ontology: US GAAP Financial Report Ontology (Prototype)
• Result: Self-Guided Tour of XBRL-based Digital Financial Report

Currently, I am aware of three implementations of my logical model. On of the implementations is a good old expert system. It leverages the structures talked about by OMG. I call the structures "blocks".  Blocks are not my idea.  Others use the idea of blocks.  I got the idea from Blockly and Scratch.  Our ideas and experiences are documented here and here. All this is tested and proven.

SBRM will have to be what I created or better. It cannot be less or worse. SBRM will help business professionals create the rocket fuel that will cause XBRL-based digital financial reporting to really take off.

If you think otherwise, tell me why.

The U.S. Federal Energy Regulatory Commission (FERC) announced that they are adopting XBRL for utilities reporting.  See the final rule for more information.

Software vendors are providing a pretty poor level of functionality when it comes to finding information within an XBRL financial reporting taxonomy.  What is the state-of-the-art? Text search.

But I think there is a significantly better way, so I created this prototype to brainstorm and solidify my ideas.  I then created this prototype wizard. This is a web service where you provide an element name and it returns information for the requested report element name. This is the same information in machine-readable form.

But this is the best working prototype that I have for now.  That is for US GAAP, it does not incorporate the more advanced graph-type searching.  But, what this will allow me to do is communicate with software engineers and others better.

This prototype combines a bunch of things together and has a nicer user interface.

Not sure where to put these roll up relations. Ah!  I just had an idea.

The idea is that the search would leverage metadata and other information in order to provide a significantly more precise information retrial mechanism.

So the US GAAP XBRL Taxonomy has 17,077 elements.  That is a lot to work with.  But, you can break that full set into lots of different groupings.  For example, those 17,077 elements are comprised of:

• 325 Tables
• 251 Axis
• 1,783 Members
• 330 LineItems
• 2,537 Abstracts
• 183 Level 1 Note Text Blocks
• 311 Level 2 Policy Text Blocks
• 474 Level 3 Disclosure Text Blocks
• 10,883 Concepts

Further, some of those groupings are still quite large so you can break them down by data type, period type. balance type, authoritative reference, etc.

If you did a raw text search on say "Cash" (you can try that here) you get 552 hits.  Somewhat helpful, but not quite what is needed.

But what if you could do a search and specify:

• The concept contains the text string "Cash".
• It relates to ASC topic "230"
• You want only concepts
• The concept is a "credit" and has a period type of "duration"
• The concept is monetary in nature.
• And it relates to the disclosure "CashFlowStatement"

I think you get the idea.  Lots of different ways to specify what you might be looking for.  Financial reporting concepts and terms, such as the US GAAP, are filled with a rich set of relations.  If you put that information into machine-readable terms, then the machines can perform what seems like magic.