Digital Financial Reporting

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:

1. 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.
2. 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.
3. Unformatted facts in inline XBRL: This document basically has a list of raw facts, basically unformatted.
4. 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.
5. 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.
6. 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.

Robert Kugel of Ventana Research wrote an excellent article, Welcome to the Age of Robotic Finance.  In addition, Mr. Kugel explains this in more detail in a very informative 35 minute webinar.

Ask yourself a question, "Where is all the machine-readable structure information going to come from that these applications and 'bots' will be using."

XBRL is an excellent candidate for describing information, transporting information, and verifying the quality of information.  XBRL is a technology that enables these other technologies.  Keep this in mind as you watch the video.  If you are finding it hard to get your head around what Mr. Kugel is saying, you may want to consider reading Closing the Skills Gap.

More ambitious?  Check out Intelligent XBRL-based Digital Financial Reporting.

Coupling the ideas of robotic finance and the ideas of "lean finance" and you really have something. Another term for the process improvement piece is lean six sigma.  Most people think of lean six sigma in the area of operations.  But the ideas are very useful for processes such as the process of creating a financial report.

I mentioned LEI (Legal Entity Identifiers) in a prior blog post.  Seems like the LEI folks have made some very significant improvements in their offerings.

First, they created an ontology.

Second, they already had the ability to search for legal entities (not sure if this changed).

Third, they have provided a bunch of data formats.  I counted 15 different data formats!  (See the EXPORT button on the left hand side)

Fourth, this is a really nice HOW TO USE page.

Here is an example using Microsoft:

• Search: This is the search page results.
• Human readable: Click the FOURTH ITEM, Microsoft Corporation, and you get a human readable representation of information about that legal entity.
• Machine readable: Go to the EXPORT button and you can download information in machine readable form.  Or, just put ".xml" on the end of the LEI, and you get machine readable information.

I don't know how things are going in terms of getting relationships between legal entities entered into the LEI repository.  My personal wish list is that:

• The FASB and IASB come up with a common description of the components of an entity and use those terms consistently within US GAAP and IFRS.
• The SEC starts allowing or requiring LEIs in XBRL-based financial filings to the SEC.
• The SEC starts requiring public companies to report exhibit 21, the schedule of subsidiaries, in machine readable form rather than in HTML. LEIs should be used to identify registrants and the subsidiaries of the registrant.
• The IFRS and US GAAP XBRL taxonomies coordinate their XBRL dimensions or [Axis] for breaking down an entity into components such as "Business Segments" and "Geographic Area" and such.  Preferably, those dimensions would be defined by XBRL International or mapped from US GAAP to IFRS using XBRL definition relations such as "essence-alias".

This is a great step forward for Fintech and Regtech!

As I have pointed out in the past, you need syntax rules, business domain semantics (or business logic) rules, and workflow or process rules to effectively exchange information.

Having figured out the syntax and business domain semantics pieces, I am not diving into workflow.

An excellent tool relating to workflow that I have discovered is the yED Graph Editor.  The reason the yED Graph Editor is so good is that (a) it is free, (b) it works on Windows and the Mac OS, and (c) it supports a couple of different standard workflow syntaxes.

Accountants are trained to understand workflow, document workflow, and read workflow documentation. However, accountants still tend to focus on human-readable workflow documentation and never really consider the idea of machine-readable workflow documentation.  This will change.

There are two workflows that I am focusing on currently.  The first is financial report creation workflow.  The second is accounting process workflow starting at the general ledger level.

More to come, so stay tuned.

Here is an online version of the yED Graph Editor.

The state of Florida is passing legislation that would require about 1,600 cities, counties, and special districts in that state to report using XBRL. Florida is likely to be the first of many states that ultimately leverage the functionality of XBRL to improve their reporting systems.

In the United States there are about 90,000 state and local governmental entities.

I don't understand the process in the state of Florida; but what I can say is that the bill passed the House, it passed the Senate unanimously, and it is likely to be signed into law by the governor.  I guess this will play out over the next several days or weeks.

Look at the legislation lines 319 to 350 (on the left hand side of the PDF). You can track the history of the legistlation here.

Reck and Snow paper:https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2474922