Digital Financial Reporting

I would be the first to admit that this still needs a lot of work, but I did aggregate and try and organize all the information that I have toward implementing a report level semantics "layer" or "level" into one narrative.

This narrative ties together the Financial Report Semantics and Dynamics Theory report level model, US GAAP Taxonomy/SEC XBRL Financial Report semantics, the XBRL International XBRL Abstract Model 2.0, and the RDF Data Cube Vocabulary which was created by the W3C Government Linked Data Working Group.

You can grab a copy of this aggregation of information and mappings between these things here on my blog.

Bottom line: Bye, bye XBRL technical syntax, hello easier to use semantics and an increased level of interoperability.  Be very, very careful if you are too focused on XBRL and not focused enough on digital financial reporting and/or digital business reporting.

XBRL has ended up where it should have begun, with the creation of a business/financial report level semantics layer.  But now we have achieved the possibility of two parts of the three piece stool which the HL7 points out is required for effective business system interoperability.

Onward toward workflow interoperability.

A milestone of 75 disclosure templates has been reached. This creating these disclosure templates is a lot of work, but as you might imagine one learns a great deal from the exercise.

One thing I am discovering is that good models produce good renderings from good rendering engines. I am looking at these disclosure templates using the renderings of the SEC viewer, CoreFiling Magnify(a document review application), and the XBRL Cloud Viewer(the same application used by the XBRL Cloud Edgar Dashboard).

I distill "good model" down to the following essence:

• Model the information, not the presentation
• Use good, meaningful labels
• Create logical, usually smaller, pieces which go together (as opposed to packing a bunch of reportable information into one big piece which is usually not logical, which might go together in the presentation but is logically separate pieces)
• There are WAY, WAY more business rules than I anticipated (this is a good thing, it helps you verify that you modelled the information correctly)

As I mentioned in another post, I found an SEC filing (Google) which had the characteristics of a good filing.  Well, there are others. For example, FERRO CORP (their XBRL instance, their documents on the SEC web site) is another generally good modeling.

Take a look at both of these filings using the SEC viewer, Magnify (ask CoreFiling for a 30 day trial), or XBRL Cloud (see Ferro Corp here, Google here). 

Also, if anyone is aware of other publicly available viewing software please let me know about it.

There is another discovery or realization.  The SEC viewer does not allow you to "pivot" the information reported by an SEC filer.  Both the XBRL Clould viewer and the CoreFiling Magnify viewer do allow you to pivot the information. 

I would say that upwards of 80% of well modeled information looks good on the first rendering that you see from all three of these rendering engines.  If the rendering is not what you want, the CoreFiling and XBRL Cloud applications allow you to "tweak" the rendering by pivoting it, you can configure some options.  That gets the number of financial report components which look good upwards of 95% or so.  You cannot do this with the SEC viewer unfortunately.  Maybe some day, maybe not.

I would speculate that the software can be improved and get the good renderings in the neighborhood of 98%, maybe higher, for good modelings.  But, there are there are four specific issues that I see here:

1. Document of record: Is it the right thing to do to allow users of financial information to render the information in different ways than the creator of that information created it?  Frankly, you cannot stop an investor or analyst from doing this; but is it the right thing to allow from the SEC public company filer's "document of record".  Personally, I don't have any problem with this but I would be the first to admit that I don't understand all the legal or societal issues. Another way of saying this is that different users of the same information will have different views of the information using different software applications.  Is that a good thing?
2. Not 100% readable:  In an HTML filing, PDF, or some other "presentation" oriented format, the information is 100% readable.  The format is also "locked" (i.e. #1 above).  So, if you cannot read 100% of the information, what good is the filing?  It does not seem that we could live with 98% of the information rendering in a usable format.  It really needs to be 100%, all the time.
3. Difference between "Readable" versus "Pixel perfect" renderings: There is a difference between "readable" and "pixel perfect" renderings.  What is the required target?  Users are use to pixel perfect.  Will they accept readable renderings in exchange for the ability to pivot information, easily load information into analysis software, etc.? 
4. Lots and lots of pieces: Presentations organize lots and lots of small models into logical pieces, presented for easy consumption.  If you look at the Google and Ferro SEC XBRL financial reports, they are readable, but there are lots of pieces and you have to work a little harder to relate some of the pieces how you want them related.  On the other hand, software can help you navigate through the many small pieces and put the pieces together in way, way more presentations than you could the one single HTML rendering.

What will be acceptable to the creators and users of this information?  How much better can software tools do to fill some of these gaps in usability?  Will the trade-offs be understood by both creators and users of this information?

Time will tell.

Bye, bye XBRL technical syntax; hello report level semantics! Well actually, the XBRL technical syntax is not going away, it will just be hidden behind easier to use business report semantics.

Who will be the first software vendor to make the leap?

I created a mapping from the SEC XBRL financial report model to XBRL International's public working draft XBRL Abstract Model 2.0. You can see a PDF of that mapping here.

Mapping from SEC Reporting Model Semantics to XBRL Abstract Model 2.0 Semantics

In that same PDF I also did a mapping from the Financial Report Semantics and Dynamics Theory semantics to XBRL International's XBRL Abstract Model semantics.

Mapping from Financial Report Semantics and Dynamics Theory to XBRL Abstract Model 2.0 Semantics

If you go to section 6 Secondary model - Financial Report Logical Model you will see a UML diagram which maps an SEC Filing to the XBRL Abstract Model 2.0.  The diagram is rather rough, but there are some interesting tidbits of information which you may find interesting.  I will dig into those later perhaps.

I want to point out a few statements from that XBRL Abstract Model 2.0 public working draft:

• Section 1.3 Model vs. meta-model: "... it is important to understand the distinction between modelling and meta-modelling. Whereas a model is typically a representation of some phenomena in the real world, a meta-model is more concerned about describing and defining the actual modelling framework that is used to construct the model."  (So it seems to me that: the XBRL Abstract Model 2.0 is actually a meta-model; the US GAAP Taxonomy is meta-data; SEC XBRL financial filings are the actual models)
• Section 1.3.1 Domain modeling: "However, it is anticipated that instances of this meta-model will eventually be created to communicate how XBRL has been applied in specific projects and taxonomies."  (Meaning: people who build XBRL taxonomies need to explain their models by mapping them to this XBRL meta-model.)
• Section 1.4 Layered modeling: "the Primary Layer - captures the pure semantics of XBRL and thus, as much as possible, is independent of the XML syntax" and "For this reason, the reader should be aware that syntactical artefacts of XBRL (such as Contexts, Arcs, and Locators) do not appear in this model as they have been considered to be artefacts of syntax rather than having any semantic significance."  (Semantics matters, not syntax)

There is a lot of technical stuff in this document.  But, there are some key definitions you should care about. These are the key definitions from the XBRL Abstract Model 2.0.

• Model element: named elements or objects or classes of the meta-model.
• DataPoint: defines a reportable item of business information.
• Aspect: defines an identifying or describing characteristic of a business information item data point.
• AspectValue: defines a specific instance of a value of an Aspect.
• Relationship: defines a logical relationship between pairs of Aspects, AspectValues, DataPoints, Resources, and between Aspect and AspectValue, Aspect or DataPoint and Resources.  (They seemed to have left out relationships between Cubes, or the sequence/ordering of Cubes.)
• Manifest: defines what is packaged in the Document. (I don't quite get this, does not seem like 'document' is defined well enough, or it is syntax.)
• Cube: defines a collection of CubeRegions that are associated with specified aspects to report. (Note that I do not believe that they mean "aspect" as defined above when they use "aspects" here. Could be wrong.)
• CubeRegion: defines a cartesian product, or set of Aspects, of enumerable AspectValues (corresponding to XBRL hypercubes after subtraction of negative hypercubes from positive hypercubes).  (This is a mouth full.  Eyes glazing over.  Don't quite get this.  It may be an irrelevant technical detail, business users may only need to understand what a Cube is.  Frankly, I don't know at this point.)