Digital Financial Reporting

I have made available a significantly improved version of an XBRL-based Financial Report Ontology (FRO)prototype.  Again, this is still a prototype; but it yields lots and lots of information.  Fiddle around with it if you are interested.  Most business people probably won't understand what they see.  Truth is, most technical people probably won't understand what they are looking at either.  But both business people and technical people will start to understand more and more once they can see what you can do with all that "stuff".

There are a few things that I want to point out.  First, there is an index page that starts to summarize important pieces.

Second, there are a handful of prototype pieces.  Of particular interest is this: http://www.xbrlsite.com/2014/Protototype/fro/Test_Linkbases3.xsd

It may not look like much, but load that into a good XBRL tool and take a look at the XBRL definition relations and observe what is going on. If you don't have anything else, grab the Arelle GUI tool.  It is a bit hard to use and I cannot seem to get the definition relations to look exactly how I want them to look; but it does let you explore what is going on. If you want to spend the money, CoreFilings SpiderMonkey works nicely.

The image above is how these relations look in my tool (UBmatrix Taxonomy Designer).  If you look at that screen shot and then you step your way through the XBRL linkbase and XBRL taxonomy files, I think you will be amazed.  Or, maybe I am just easily amazed.

The problem with the graphic though is that you cannot see the details of the relations.  You have to see those within some software product. You also have to understand the specific meaning of the relations to fully appreciate what is going on.  The bottom line is this: generic, global standard way of expressing business rules. Why is that important?  Read here.

What you are looking at is numerous "layers" of information which fits together "perfectly".  What I mean by perfectly is not that what I am showing is 100% correct.  What I mean is that if there are errors in the representation, no problem that can be fixed.  But, what is really interesting is knowing THAT you can layer things together like this, THAT it works correctly in XBRL software (4 tools work as expected, 1 does not), and most importantly HOW to achieve this.

I am not going to explain this more right now, I will explain later.  But, I did want to get this out here for people who wanted to understand this sort of stuff and so that I can send something to people that helps them grasp this.

Kudos to the XBRL technical people.  You guys did an awesome job in architecting XBRL.  A lot of things they said along the way that I did not understand at the time, well, those things are making more and more sense.