Digital Financial Reporting

The International Journal of Digital Accounting Research (IJDAR) has published an article by María Mora Rodríguez and I titled Digitizing Financial Reports – Issues and Insights: A Viewpoint. This is an abstract of the article:

The era of digital financial reporting has arrived. However, many questions persist relating to how digital financial reporting will actually work and what is necessary to make it work appropriately. Technologies such as XBRL must be well understood in order to harness their power. This paper is intended to provide a thought-provoking summary of the moving pieces that must be considered by accountants and other business professionals when evaluating how digital financial reporting will be best employed for financial reporting. The paper is intended to help these business professionals understand the issues related to digitizing financial reports and maximize the potential contribution the accounting profession can make to the achievement of successful and appropriate digital financial reporting. The end result will be well-thought-out digital financial reporting. Any expression of digital financial reports must be in a form that business people understand because they are the ones who create these reports and verify that they are a sensible, logical, faithful, true and fair representation of the reporting entity’s financial information. The XBRL taxonomies have been the most serious effort thus far to formalize the business rules in XBRL implementations. The XBRL technical syntax interoperability is very good, but the semantics is still a challenge. To face this, effective communication between accounting professionals and IT professionals is key.

Digital financial reporting is not only inevitable, it is imminent. We hope accountants find this article useful in understanding why their participation in digitizing financial reports is crucial.

(Sorry about the typo in the title, cannot change it or it changes the link.)

In a post to the XBRL Public discussion group, Louis Matherne who works at the FASB and is responsible for the US GAAP XBRL Taxonomy made the following statement:

At the FASB, we are consciously moving in the direction of focusing more on the semantic model in our modeling process.  It is not an easy transition because we are obliged to build to our 'legacy' XBRL implementation but it is certainly in our collective best interest to start thinking and acting this way.  And as I stated at the beginning, the key bit here is getting everyone in this space to start thinking this way.  One of our goals is to get preparers and data aggregators to start focusing on the semantic model when they build and use financial statements (rather than the simple print statements).  Once our constituents start thinking this way, the rest will become much easier.

If you have been following my blog you know that I have been trying to push things in this direction for quite some time. While seven years ago I could not even distinguish between "syntax" and "semantics"; I have learned quite a bit about the difference between the two.

If you want to "go semantic" and not be left behind, a good place to start is by reading this document: Financial Report Semantics and Dynamics Theory.

If you need an even more basic explanation of XBRL and the difference between syntax and semantics, try these resources:

• How XBRL Works: This video has been viewed 26,000+ times now and helps people understand the very basics. This blog post is also helpful.
• Differentiating syntax and semantics: This video helps you understand the difference between syntax and semantics.
• The big picture: The big picture is explained on this blog post.  There is a lot of information being thrown at you, but the information is critical.

Stay tuned!

DisclosureNet published a very nice presentation titles Common XBRL Misconceptions.  Here is a summary of those misconceptions. Check out the presentation as it is nicely done and provides necessary details for understanding the XBRL misconceptions and the reality:

• XBRL Misconception #1: When unsure about which standard tag to use, create an extension tag.
• XBRL Misconception #2: Outsourcing XBRL tagging is the best option.
• XBRL Misconception #3: XBRL makes companies too transparent.
• XBRL Misconception #4: SEC penalties for XBRL non-compliance aren’t a concern.

People are starting to recognize that the crackdown is coming.

A post from XBRL Europe to a number of news lists states that the European Parliament passed a law yesterday which requires all listed (public) companies in the European Union to report in one standard electronic format.

This is the agreed to text of the law:

(21a) A harmonised electronic format for reporting would be very beneficial for issuers, investors and competent authorities, since it would make reporting easier and facilitate accessibility, analysis and comparability of annual financial reports. Therefore, preparation of annual financial reports in a single electronic reporting format should be mandatory with effect from 1 January 2020, provided that a cost benefit analysis has been undertaken by ESMA. ESMA should develop draft regulatory standards for adoption by the Commission, to specify the electronic reporting format, with due reference to current and future technological options, such as eXtensible Business Reporting Language (XBRL). ESMA, when preparing the draft regulatory technical standards, should conduct open public consultations for all stakeholders concerned, make a thorough assessment of the potential impacts of the adoption of the different technological options, and conduct appropriate tests in Member States on which it should report to the Commission when it submits the draft regulatory technical standards. In developing the draft regulatory technical standards on the formats to be applied to banks and financial intermediaries and to insurance companies, ESMA should cooperate regularly and closely with the EBA and the EIOPA, in order to take into account the peculiarities of these sectors, ensuring cross-sectoral consistency of work and reaching joint positions. The European Parliament and the Council should be able to object to the regulatory technical standards in line with Article 13(3) of the ESMA Regulation, in which case these standards shall not enter into force."

See this press release for more information.  Here is a link to the directive.

While the law does not specifically state that XBRL must be used, and the fact of the matter that it really makes zero difference what format is used, financial reporting is going digital in Europe. So, for Europe to achieve meaningful information exchange they will do one of two things:

• Analyze the experiences of the US SEC and proactively make any necessary adjustments to not repeat mistakes
• Repeat the same mistakes as the US SEC and then realize what they need to do successfully exchange information electronically

Time will tell what the EU chooses to do.

Mike Willis of PriceWaterhouseCoopers wrote a good article about how disclosure management software is improving the process of creating financial reports by 30%. In that article Mike mentions the notion of a reporting template.

Last year I created a set of 75 reporting templates. I have updated those reporting templates to the 2013 US GAAP Taxonomy, corrected a few XBRL Formula errors, and updated the visual of the reporting template.  Other improvements have been made.  You can take a look at these updated reporting templates here.

One of the more useful things that I added to the library of reporting templates is this visual index of all 75 reporting templates.  This visual index is interesting to me for two reasons: (1) It quickly allows you to find a reporting template, (2) It shows renderings which are generally pretty good.

The renderings of each reporting template are provided by XBRL Cloud.  The renderings are screen shots of the renderings provided by the XBRL Cloud Evidence Package and/or XBRL Cloud Viewer (click on the "Viewer" button on that page).

Personally, I think the renderings are pretty good.  Granted, they are not perfect and there are other disclosures which are more complex and maybe they would not render so good.  However, I am not so sure that even complex disclosures would not render correctly or at least good enough to be readable.

There are two things which contribute to poor renderings as I mentioned on my blog a year ago:

• Poorly represented information (i.e. bad modelings)
• Poor rendering engines

If you have a poorly represented disclosure there is no rendering engine which would be capable of rendering that poor representation correctly.  Likewise, you can have the best representation in the world but if the rendering engine is not so good you could likewise not get a good rendering.

So both the representation AND the rendering engine contribute to achieving a usable/readable rendering.  I am not talking about a pixel-perfect rendering.  I am not talking about a rendering exactly as one person might want the rendering to be.  Specifically satisfying every person's preference with one rendering approach is impossible.  Not is that a use case for XBRL as I see it.

The goal is a usable and readable rendering for any disclosure.

Something like Inline XBRLcan get a rendering closer to "pixel-perfect". The Table Linkbase created by the folks pushing the Data Point Modelcan help also.  But are Inline XBRL and the Table Linkbase really necessary?  I am not so sure.  Constructing the Inline XBRL or Table Linkbase information includes additional work.  Perhaps there is some benefit for some specific use cases but personally I don't want custom renderings; what I want is to be able to compare information.

But don't rush to judgment.  Be sure you are looking at a good information representation using a good rendering engine before you determine that XBRL can or cannot be rendered correctly.