Digital Financial Reporting

I have always thought Datomic was interesting.  Datomic Cloudis even more interesting.  Datomic Cloud is even more interesting on Amazon Web Services.

See this Introduction to Datomic video.

Here is a list of reasons why I find Datomic so interesting:

1. Datomic is a fact database, organized similar to EAV (entity, attribute, value) or RDF.
2. Datomic has an integrated rules engine, datalog.  See this video.
3. You can never delete facts from the database.  You can mark them deleted, but you cannot make facts go away.  That means excellent audit trail.

++++++++++++++++++++++++++++++++

SirixDB

LearnDatalogToday

JUXT XTDB

I built a working prototype XBRL-based financial report validation tool in Excel probably four or five years ago.  That tool was used to test the feasibility of some ideas which I had.  Those ideas have turned into commercially available software products/solutions.  One software vendor, for example, offers a suite of validation products.  Another commercially available product is being made available. And I have been working with another software engineer to test some other ideas.

These tools might look like toys.  But if you understand disruptive innovation and you look closely; you will realize that these are far from toys.  This is experimentation that will lead to new products and services.

I have updated my older prototypes and synchronized them very closely to the commercially available validation products for my fundamental accounting concept relations continuity cross checks.  You can get Excel spreadsheet applications that currently cover almost 70% of all public companies that submit XBRL-based financial reports to the Securities and Exchange commission.

Here is the VBA Code if you want to check the code before you download or run the macros.  All the spreadsheets have basically the same code, just different mapping rules, impute rules, and consistency check rules.

These two videos help you understand the tool:

1. Video 1 - Overview
2. Video 2 - Additional Information

All the spreadsheets basically work the same, they just have different metadata for the different reporting styles of public companies.  You can use these spreadsheets to analyze across entities like in most of the examples that I have provided.  But, you can also analyze all the filings of one company across all their filing periods.

Here are some examples:

• NO ERRORS EVER: Apple, Google, Urban Outfitters, and Red Hat have never made an error related to the fundamental accounting concepts continuity cross checks.
• ERRORS FIXED: AT&T is an example of a public company having errors; but the errors were subsequently fixed.
• ERRORS:  Fossil, Nexus Enterprise Solutions, Simpson Manufacturing, Tiger Reef, and United Natural Foods are examples of existing errors that still need to be fixed. (Compare those filings with these 1,642 public companies that use the same reporting style but don't have any errors.)

To make the Excel based tools work, you have to get the URL of the file you want to validate or you can put the full path to any local file you want to validate.  You can get file locations from the SEC EDGAR system, from XBRL Cloud's EDGAR Dashboard, using an API such as XBRL Cloud's (human readable, machine readable); lots of different ways to get the files.

By the way, this works with local files also.  See this example. (Clearly this will not run; you need to put the path in to your files.)

You have to understand the reporting style of the company.  Here is a list of reporting styles for all public companies (not all styles are supported yet). Notice the URL; select from the list or just put in the beginning of the name of the company and you will get a list.  XBRL Cloud has an API for getting this information as well.

From the list of reporting styles you can get to a summary of the reporting style; here is the main entry point of the metadata.

Again, the metadata is near commercial quality.  I am not sure how close I will make this, I don't want to take away business from people who have existing commercial products.

Companies that are going to file with ESMA are going to need similar functionality.

Ignorance is defined as a "lack of knowledge or information".  All this information is an excellent opportunity to vanquish ignorance related to how XBRL-based digital financial reporting actually works.  What I discovered from all this poking and prodding of XBRL-based financial reports submitted to the SEC is that validation metadata is the same metadata that you need to extract information from those reports effectively.

But don't believe me.  Fiddle with the Excel spreadsheets.  They are great learning tools.  The code is terrible and you can clearly undrestand the problems of embedding business rules in software code.  Bad idea.

I have further updated, expanded, and tuned the XBRL-based financial report extraction tools that I posted last week. Here are the improvements:

1. 3,865 financial reports of public companies (about 65% of the total) all of which pass 100% of the fundamental accounting concept validation cross checks. (The prior version had 3,015 companies or about 50%)
2. Synchronized all the validation rules to the commercially available versions provided (99.9% consistent)
3. Changed the "IF...THEN" rules which were hard to edit/maintain to immediate IF functions per the suggestion of some.  This was REALLY helpful.  This change makes maintenance significantly easier.
4. Nine reporting styles are provided for. (Prior version only had four)

I really cannot overstate the usefulness of these Excel spreadsheets.  What I have stumpbled across is the fact that the same business rules that I use to validate an XBRL-based financial report can be used to extract information from reports.  Today, each data aggregator that extracts information from reports had to create their own set of algorithms and rules for doing so.

Here are the revised versions: (This video will help you understand how to use the tool)

• COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6:  1,642 public companies
• COMID-BSC-CF1-ISS-IEMIB-OILY-SPEC1:  714 public companies
• COMID-BSC-CF1-ISS-IEMIB-OILY-SPEC2:  653 public companies
• INTBX-BSU-CF1-ISS-IEMIX-OILN:  416 public companies
• COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC9:  143 public companies
• COMID-BSC-CF1-IS3-IEMIB-OILN:  83 public companies
• INSBX-BSU-CF1-ISS-IEMIX-OILN:  94 public companies
• COMID-BSC-CF1-IS6-IEMIX-OILN:  79 public companies
• COMID-BSC-CF1-IS4-IEMIB-OILN:  41 public companies
• Total provided:  3,865 public companies (65% of all public companies)
• COMID-BSC-CF1-ISS-IEMIT-OILY-SPEC2: 38 public companies
• COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6-SCI2: 37 public companies
• COMID-BSC-CF1-ISS-IEMIB-OILY-SPEC2A: 64 public companies
• COMID-BSC-CF1-IS8-IEMIB-OILN: 56 public companies
• Net total provided: 4,060 public companies (68% of all public companies)

Comparisons by period for: (one ZIP file containing 9 Excel files, about 1 MEG)

• Apple, Google, Microsoft, Toys R Us, MetLife, Wells Fargo, Dominos Pizza, Urban Outfitters, Red Hat

 Download all: (each reporting style above and all comparisons, about 3.1 MEG)

• Download all files

Here are a few tips for using the examples:

1. All the spreadsheets come pre-populated.  But, you can re-run the extraction routine and populate the spreadsheet by pressing the button on the "Compare" sheet.
2. The "List" sheet is where the list of XBRL-based financial reports from which information will be extracted and validated.
3. If you put an empty row in the "List" spreadsheet, the extraction/validation will stop when it hits that row.
4. If you want to validate a local file, simply put the local path to the file or files in the "List" spreadsheet.

AsReported has provided a set of measurements related to the quality of XBRL-based financial reports created by different software vendors and filing agents.  Here is their blog post that has the measurements.

What AsReported is measuring is a bit different than what I am measuring.  My focus is on accounting and reporting logic.  AsReported is more focused on mechanical, structural, mathematical, and some logical relations at this point it seems.  What is interesting is that they give each filing agent/software vendor a score (see the right most column).  They call this the "Quality Score" and discuss that metric on their blog.

Another software vendor taking measurements is XBRL Cloud.  They provide details for each filing on their EDGAR Dashboard.  You can search by company name and get details by public company.  Here is an example.

I have updated Excel tool and expanded the set of reporting styles covered by the tool which extracts information from XBRL-based financial reports submitted to the SEC.  The set of tools below covers 50% of all public companies that file with the SEC.  The tool accurately extracts fundamental high-level financial information from the 3,015 covered economic entities.

So in my commercially available metadata set, my coverage is higher, 90% or more which is explained here in this document.  But only about 87.9% report all of their high-level financial information correctly.

In this set of 3,015 public company financial reports, all the information is consistent with expectation and FOUR different report styles are covered. So the proof is in the pudding here. If you REALLY want to understand what it takes to get these reports correct and to extract information from the reports correctly; these Excel tools will help you understand that:

• SPEC6: 1,445 public companies (this is by far the most popular reporting style)
• SPEC1: 629 public companies
• SPEC2: 566 public companies
• INTBX: 375 public companies
• Total 3,015 (See page 6 of this document for more detailed information about reporting styles; see this web page to understand the details of a reporting style)

This step-by-step explanation helps you understand how the Excel extraction tool works.  Note that while I am showing the extraction of primary financial report information, this same scheme applies to the disclosures also.  And, while this Excel extraction tool only pulls information for the current reporting period, this same scheme can be used to get prior period information in a report also.

Each Excel spreadsheet has the information preloaded.  But if you press the button on the "Compare" spreadsheet, the application will re-extract information directly from the public company's XBRL-based financial report.

My goal is to provide similar spreadsheets for a handful of other reporting styles and to synchronize the business rules in this application 100% with the commercial quality tool metadata used by XBRL Cloud and Pesseract.  So, I already solved one of the two problems I am having.  The commercial tools use declariative business rules that are provided via the XBRL technical syntax.  You will note that my business rules (mappings, impute rules, consistency check rules) are hard-coded.  That is not good.  But, because I am not a very good programmer, that is the best that I can do.  But, what I was able to achieve is to generate the VBA code from reading the XBRL-based information.  For example, here are the mapping rules for the SPEC6 reporting style.  I am not auto-generating the VBA code for the mapping rules from those XBRL definition relations.

I am also going to reorganize the XBRL files that provide this information.  I have a lot of unnecessary duplication right now.  That duplication resulted from the fact that I really did not know exactly how this process of creating the metadata would turn out when I started.  I know now, so I am going to refactor the way I physically represent the information so that it is easier to debug and maintain.

One very important thing that I am observing is the difference between a "top down" and "bottom up" approachto creating XBRL-based taxonomies.  I am still trying to figure out exactly how to articulate this. I don't know that "top down" and "bottom up" are the right terms.  Other terms are "publisher focus" as contrast to "consumption focus".  Another term is "restrict then loosen" as contrast to a "slack then restrict".

If you understand the principles at workwhen you take an existing reporting scheme and decide how you will make that work using XBRL, there are lots of things that need to be considered.  Theoretically, the best way to implement is to create a restrictive as possible model; then incrementally loosen what is allowed to allow more within the system.  That keeps everything in control.  Alternatively, the approach where you provide a very loose model; but then you incrementally restrict the model to make it tighter and tighter looks very "sloppy" because you initially get a lot of errors.

While I am noticing that I am doing 80% (maybe more) additional work having to overcome things that were not included, but should have been included, with XBRL-based financial reporting; I really cannot see any other way to make this work other than how the SEC is approaching it.  The "loose model" that the SEC started with was smart.  Why?  Because if a restrictive as possible model was used initially, public companies would likely have rioted.

Those incremental restrictions are emerging slowly but surely.  Things like my fundamental accounting concept relations continuity cross checks, the disclosure mechanics rules, the reporting checklist rules, the XBRL US Data Quality Committee rules, etc.; those are incremental restrictions what will improve information quality and therefore make the information more useful.