XBRL-based Report Repository

Trying to extract information from a repository of XBRL-based financial reports and compare the extracted information from information extracted from other reports can help one see and understand a fundamental aspect of what most people are getting wrong about such XBRL-based financial reports.

I have been able to effectively extract information from both US GAAP and IFRS XBRL-based financial reports submitted to the U.S. Securities and Exchange Commission's EDGAR system. (See here and here for US GAAP information; see here for IFRS information)

The fundamental issue with extracting and comparing information from XBRL-based reports is this: Financial statements created using US GAAP and IFRS are not, and should not be, forms.  Meaning, the designers of both US GAAP and IFRS intentionally provide flexibility within the prescribed financial reporting standards to reporting economic entities which allows those economic entities to (a) report using different report line items, (b) report using different totals and subtotals, (c) pick from different reporting alternatives, and (d) to add additional information to their financial report that enables the reporting economic entity to "tell their story their way".

For example, a reporting economic entity is not only allowed, but encouraged, to break out the details of revenue in ways that help financial report readers understand the reporting economic entity better.  So, say, Apple and Microsoft do not break out the details of revenue in the same way.  Sure, the grand total of reported revenue are the same concept; but the details can be different.

Now, I am not saying financial reports are random.  Far from that.  They are absolutely not random.  What I am  saying is that there is more than one logical pattern which financial report information follows. Here are my reporting style summaries for both US GAAP and IFRS.

What does this mean?  Well, this means that extracting information from such reports is a little more complicated than extracting information from a form because of this allowed customization of a report model.  First, you have to understand that there are different reporting styles (use different line items, different subtotals, different grand totals) and what they are.  Second, you need to have the machine-readable rules necessary to extract information from those reports. Interestingly, the rules for extracting information are exactly the same rules that are used to verify that the reports are following the permitted reporting patterns.

To help people understand this and see what is going on, I created this small prototype repository of XBRL-based report information.  (Screenshot below) Sure, this repository of reports is small, but it can be used to make my point.  I use this repository for testing, experimentation, education; it has a lot of great uses.

Included with that repository is an Excel spreadsheet application that extracts information from the reports in the repository. You can use the Excel code to understand the details related to effectively extracting information from each of the reports in the repository, each of which has a different reporting style.

Now, as those that understand the analysis of financial information understand; there is a difference between "as reported" information and "normalized" information. To do a normalization, you need to extract the information from the as reported report.  So, the test is can you extract information from as reported information (i.e. the actual report).  Getting the information is one thing.  That is a cake walk.  The trick is to effectively compare report information across multiple reports, including when different reporting styles are used.

Additional Information:

Comments

Popular posts from this blog

Getting Started with Auditchain Luca (now called Luca Suite)

Relational Knowledge Graph System (RKGS)

Professional System for Creating Financial Reports Leveraging Knowledge Graphs