XBRL-based structured digital financial reporting - Blog: Digital Financial Reporting (using XBRL)

I am continuing on with my brainstorming related to robotic finance and accounting process automation using XBRL.

While a lot of people are talking in general high-level terms about "robotic finance" or "process robotics" or "accounting process automation" or "financial report creation automation"; fewer are talking about these things at the level of detail that it actually takes to implement these sorts of things.

So here are details. I created the DRAFT document Guide to Implementing Robotic Finance. This is mostly brainstorming and collecting my thoughts at this point. If you are interested in this sort of stuff the document is definitely worth reading through.

I am contemplating two XBRL formats, trying to figure out which is the best format all things considered. I don't think this is an "either/or" type of question. The two formats are:

Raw XBRL
Inline XBRL

Each format has its pros and cons. Both formats are worth considering. To add some contrast to this discussion, consider the W3C working draft HTML Microdata. This is someone similar to Inline XBRL but it has one fundamental flaw: it does not support multidimensional information.

Now, the W3C has a recommendation The RDF Data Cube Vocabulary. (They seem to be working on updating this recommendation.) That seems to focus on SDMX.

The first point that I want to make here is that (a) you will ultimately realize that you need a dimensional model and (b) XBRL has a solid, tested multidimensional model that works for the sorts of things you want to do in financial reports. XBRL Dimensions does have a few issues, but within the set of 6,000 XBRL-based financial filings submitted to the SEC you can pretty much understand that dimensions work and how to represent things if you understand what you are looking at. Be careful; there is a lot of garbage out there you have to wade through. Dimensions work with either raw XBRL or inline XBRL.

The second point is that as far as I can tell, it does not matter whether you use raw XBRL or inline XBRL. Both will work. Inline XBRL appears to have some advantages but all things considered it really distills down to two things: (1) having a sophisticated rendering engine and (2) the complexity of the information that you want to or need to represent.

Here is what I mean. First, download this Excel spreadsheet which lets you extract information from Raw XBRL or Inline XBRL documents. The demonstration is not sexy or anything, it simply pulls information from a raw XBRL document and five different versions of inline XBRL documents. Extracting information from either is rather easy.

So now look at each of the documents:

Raw XBRL: So raw XBRL is not understandable to humans. But you can convert the raw XBRL into something that is readable by humans. Here is an example. So, you can turn machine-readable raw XBRL into human-readable form to the extent that you have a sophisticated rendering engine and up to the point of complexity supported by the rendering engine functionality.
Hidden facts in inline XBRL: This document has all but one fact represented as "hidden" from the HTML rendering. Not much of a point in doing this.
Unformatted facts in inline XBRL: This document basically has a list of raw facts, basically unformatted.
High-quality formated facts in inline XBRL: This document has formatting of the quality of the HTML documents of financial reports submitted to the SEC. It takes a lot of work to create that formatting.
High-quality formated facts with business rule validation results in inline XBRL: This document has the same high-quality, precise formatting as above; but added to it is information about the validation results of business rules. The information in the document needs to be consistent with business rules to make sure information quality is intact.
Good-quality auto-generated formated facts in inline XBRL: This document is of good quality and the formatting is auto-generated by machine-based processes which outputs inline XBRL. Now, this version does not include the "green" cells which show that the information is consistent with applicable business rules; but that could be added with little effort really.

So what is my point here? My point is that for many use cases, machine-generated formatting will work just fine and there is no need to have humans create the human readable formatting. Now, you WILL ALWAYS need both human-readable and machine-readable information when you are doing "robotic finance". There is no way around that. Financial reporting CANNOT be a black box. And quality does matter. The information that is processed by the finance function is very, very high quality. Due to the nature of this information, there can be no compromising on quality. Low quality is a non-starter.

Here is a more complex XBRL-based report, the XASB reference implementation. That inline XBRL was auto-generated.

As such, as I pointed out above, the extent that auto-generated inline XBRL can be generated is directly dependent on:

the sophistication of the rendering engine
the complexity of the information you are working with

There are a lot of tricks that you can use to increase the sophistication of the rendering capabilities of a rendering engine. Hard coded information and metadata-based information are both helpful. Again, information quality and the ability for an accounting professional to understand what is going on are paramount. No black boxes. Not technical oriented renderings or informational messages.

More coming soon so stay tuned.