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.)

I don't really know python, but I hear a lot of really good things about it. I do know a lot about Excel. But, it seems that combining these things would be incredibly useful:

• Arelle: An open source XBRL processor built using python.
• IronSpread: A way to use python within Excel.
• Python-Excel: Other stuff related to getting things into and out of Excel using python.

This I absolutely agree with: "learn to code".  You don't need to learn to be a programmer, just learn to code.  Huge difference.

Introduction to Python video

Parsing XBRL with Python

I have fiddled around with programming my entire career.  I started with Lotus 1-2-3 macros, rBase which is a relational database, moved to Excel when it still used the old macro language, really jumped into Excel when it moved to VBA, jumped into programming even more when Microsoft Access which was released (started with macros, but then switched to VBA), and even fiddled with Visual Basic .Net.  I like VB.Net and wish Excel and Access would switch from VBA to .Net; not sure if that will ever happen.

Along the way I learned SQL, HTML, HTTP, XML, XSLT, regular expressions, ASP, CSS, RDF/OWL, XSL-FO, XQuery, XML Schema, and other odds and ends to varying degrees.  It is a hobby which fits nicely into the accounting work I do. And yeah...I learned a bit about XBRL also!

Programming is fun, but I would not want to do it for a living.

I have long called for and pushed for a global public standard logical model of the semantics of XBRL-based information.  XBRL International took a huge step in that direction today when it released the second version of the XBRL Abstract Model.

As of this point I have not read this document thoroughly, but I am quite confident that this is a very significant improvement over version 1.0 of this document which was a muddled UML model of the XBRL technical syntax. 

The scope of the XBRL Abstract Model 2.0 is a good summary of what they are now trying to achieve:

Scope: The abstract modelling task force will be responsible for delivering an UML model which captures the semantics of the XBRL 2.1 core specification and the Dimensions 1.0 specification. The UML model will capture the fundamental¬structures and design of XBRL and XBRL Dimensions as standalone UML artefacts, decoupled from any specific XML syntactical details. The scope was expanded in December 2011 to include the use of these semantics by XBRL extension modules including Formula, Table Linkbase, Versioning, and to base the meta-model on accepted industry meta-modeling technology.

What does all this mean?  Well, one thing that it means is that it validates all the work I have been doing in this direction since about 2007.  What I have come up with is summarized here, Digital Financial Reporting.

While my terminology is different, the fact that I do have a logical semantic model means that all I need to do is map my logical semantic model to this XBRL International XBRL Abstract Model.  Further, my model builds on the XBRL Abstract Model.  My model builds on the base logical model adding in the specific things necessary for the financial reporting domain; leveraging not the XBRL technical syntax, but rather the semantics of XBRL.  Said another way: basically I am in really good shape.

Further, the US GAAP Taxonomy and SEC XBRL financial reports will be distilled into the XBRL Abstract Model 2.0.  Why? Well, they have to be able to be distilled down into this model or the XBRL Abstract Model 2.0 does not work.  If the US GAAP Taxonomy and SEC XBRL filings don't fit into this model, the model will be tweaked (it is only a public working draft) until it does.

I would encourage anyone building software to both read and understand this XBRL Abstract Model 2.0 and to provide feedback during the public comment period so that the recommendation is as good as it can be.