Digital Financial Reporting

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.