BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Updated Digital Financial Reporting Conformance Suite Results

I have updated the results of my testing of consistency against a conformance suite that I have created for XBRL-based digital financial reporting.

There are now at least three software vendors that provide consistent support for the 11 concept arrangement patternsthat make up the core of XBRL-based digital financial reporting. 

Here is a comparison of the 11 concept arrangment patterns for those three software vendor applications.

Believe it or not, every XBRL-based report submitted to the SEC using US GAAP or IFRS can be broken down into these 11 concept arrangement patterns.  A test set of 6,023 reports which contain 8,532,275 facts can all be arranged into information model that contain these 11 concept arrangement patterns. These and other patterns are the basis for my Financial Report Semantics and Dynamics Theory and the Logical Theory Describing a Business Report.

An ontology is essentially taking the information from those two documents above and representing them in machine-readable form.

I don't know if I should say that something like the US GAAP Financial Report Ontology is the basis for the concept arrangement patterns of if it is the case that the concept arrangement patterns enable the creation of such ontologies.

These same ideas apply not just to US GAAP or IFRS; rather the ideas apply to any financial reporting scheme.  Further, the ideas can be applied to non-financial reporting schemes.

All of this is currently informally standardized using my open source approach. OMG's SBRM is about making my informal standard that I am using for financial reporting more formal plus it is about expanding the ideas created specifically for financial reporting and applying them to the more general use case of general business reporting.

Posted on Monday, July 1, 2019 at 07:27AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

New Prototype Format

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:

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

Posted on Wednesday, June 26, 2019 at 06:55PM by Registered CommenterCharlie | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding the Role of SBRM

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.

Posted on Wednesday, June 26, 2019 at 08:02AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Object Management Group and the Standard Business Report Model (SBRM)

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:

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.

Posted on Tuesday, June 25, 2019 at 08:45AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Federal Energy Regulatory Commission (FERC) Adopting XBRL 

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

Posted on Thursday, June 20, 2019 at 10:34AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint