BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. It is for innovators and early adopters who are ushering in a new era of digital financial reporting.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Further Updated and Expanded XBRL-based Financial Report Extraction Tools

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)

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

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

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.
Posted on Thursday, January 11, 2018 at 12:20PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

AsReported XBRL-based Public Company Financial Report Quality Measurement

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.


Posted on Sunday, January 7, 2018 at 11:23AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Updated and Expanded XBRL-based Financial Report Extraction Tools

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:

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.

Posted on Sunday, January 7, 2018 at 07:54AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Step-by-Step Explanation as to How My Automated Reporting Checklist Works

I was asked a question on the XBRL-Public discussion group related to exactly how the validation that I have created is detecting accounting and reporting errors in XBRL-based reports of public companies that are submitted to the SEC.  This blog post "weaves" all of this information together as best that I can currently to explain how all this works.

There are a couple of good things to understand before you read this explanation.  To begin with, I am showing some prototypes that are used to detect fundamental accounting concept relations continuity cross check mistakes made in reports.  I am using that because it was the first initial prototype that I created to prove this concept and explain to software vendors how to implement this functionality.  The disclosure mechanics and reporting checklist came later.  HOWEVER, both processes fundamentally work the same way.  In fact, I really don't think this should be two separate processes; what I need to do is combine both of these separate processes into ONE process.  Also, there are other pieces of this that I am not covering such as the "model structure relations" checks and the "type/class relations" checks.  They also work using the same basic approach.

Here is an explanation of the method that I use to create what I am calling my "automated reporting checklist" which is similar to the manual "memory jogger" many professional accountants and pretty much all auditors use today to make sure a financial report is created correctly.  This automated reporting checklist leverages the structured nature of an XBRL-based financial report

STEP 1: First you have to understand the “business logic” of the report; basically what is required to be reported.  A financial report is made up of many different specific disclosures.  Each of those disclosures can be identified.  Here is a summary of that for the 65 disclosures I have documented for my campaign to improve disclosure quality.  You can scan that list and see the sort of information the PDF contains.

That entire document can be hard to digest; so here is one fragment of that document for one specific disclosure, future minimum payments due under noncancelable leases of a lessee.

Notice that I gave the disclosure a specific unique name, I described the disclosure, I provided a reference to the Accounting Standards Codification (ASC) for the disclosure, provided an example of the disclosure, the Level 3 Disclosure Text Block and Level 4 Disclosure Detail concepts used in the disclosure, referenced the disclosure to one specific company that has that disclosure, and provided a like to 110 examples of that specific disclosure within the financial reports of public companies.

Essentially what I am doing is understating the logic of the disclosure and accumulating evidence to support that logic.  (Note that this is a skill professional accountants will need in the future.)

STEP 2: Once you have gathered the business logic of a disclosure, you then have to translate those disclosure requirements into machine-readable form.  The machine readable form that I am using is basic global standard XBRL technical syntax.  Note that older prototypes shown do not use that syntax, but I have converted 100% of these machine-readable business rules into the XBRL technical syntax.

Basically, you create metadata in the for of declarative business rules that is used to TEST the information submitted within an XBRL-based financial report.  I am using XBRL definition relations to achieve that for the disclosure mechanics and reporting checklist rules. Here are the XBRL definition relations of the business rules in machine-readable form for the mechanics of the future minimum payments disclosure.

And here is the EXACT same information in human-readable form.  The human-readable representation which is essentially a controled natural language syntax is actually generated using software from the XBRL-based rules.  So, the two are 100% consistent; one format is intended to be used by machines, the other format is intended to be used by humans who are using the machines.

STEP 3: Once you have an XBRL-based structured report and the machine-readable rules; you need software that processes the structured reports and the structured rules and tells you if the report is created correctly based on the rules.  Generally the best approach to creating this software is to create a business rules engine. But, alternative approaches work also.

You create software that uses (a) an XBRL-based financial report (i.e. structured data, therefore the individual pieces of the report can be accurately identified) and (b) the machine-readable business rules (i.e. the metadata) and uses software algorithms to deterimne if the XBRL-based report is consistent with or inconsistent with the machine readable rules.  Here is the “line of reasoning” generated by one such software application that have implemented this functionallity. 

STEP 4: You organize all of this into some sort of software interface and you repeat this process for EVERY disclosure.  Here is the interface generated by one of the software applications that spews out a set of HTML documents that hooks all of this together. (Note item 54with is the future minimum payments due under Noncancelable leases for lessees.) 

Can all this be done using Microsoft Excel?  Sure, no problem.  I created my first initial prototype of this in Microsoft Excel.  If you download and look at the Excel application, which is an updated version of that initial prototype, you will notice that the application actually works on the 1,445 XBRL-based financial reports of public companies who have filed with the SEC which use the most common reporting style. And here is another working prototype that works for a different reporting style which is used by about 454 public companies.

The results are pre-loaded in the Excel spreadsheets.  If you press the one button on the “Compare” spreadsheet, the existing results will be deleted and the spreadsheet will repopulate.  (i.e. this WORKS)  For both of these two prototypes, I have DELETED all financial reports that DO NOT PASS.  I am going to resynchronize the rules in the Excel spreadsheet with the rules implemented by XBRL Cloud and the Pesseract proof of concept.

STEP 4(a): Key to understanding exactly how all of this work are the following all of which can be examined within the VBA code of the Excel prototypes:

  • Mapping rules: Because multiple concepts might be used to represent a financial report fact, you have to create metadata (i.e. mapping rules) or as I did in the Excel application hard code the mapping rules in the code.
  • Impute rules: Because not all line items are explicitly reported, you need to be able to logically derive the line items that are missing.  For example, many companies don't explicitly report the line item "Noncurrent assets" on their balance sheet.  Some do, but some don't.  Business rules help you derive these missing line items.
  • Consistency rules: Once all the facts are discovered and all the missing line items that you want or need are derived using the impute rules, you use the consistency rules to check to make sure all the information is consistent.  This checks helps make sure there are no contradictions, no conflicts, and all the information you are working with is consistent with your expectation.

All of this works using the rules of logic.  As you are probably aware, when a company creates an income statement, there are a number of different concepts that might logically be used to represent the notion of “Revenues”.  Look at the mappings.  The concept “us-gaap:Revenues” is a rational concept; or the concept "us-gaap:SalesRevenueNet" might be used or "us-gaap:HealthCareOrganizationRevenue".   All of these are logical choicesfor reporting the notion of “Revenues”.  What is NOT logical is to use the concept “us-gaap:Assets” to report revenues.   And, there is other logic at play here; but the bottom line is that what is represented MUST be logical.  It is the metadata that defines the logic.  No metadata, software simply could not figure out what facts to grab. 

Likewise as you are probably aware, public companies are NOT REQUIRED to report every line item.  Certain line items, yes they are required to report.  But other line items are NOT required.  But what IS required, again, is for the information reported to be LOGICAL. 

Look on the "Compare" spreadsheet and look for the columns that have all the GREEN cells that look like this.  Notice how everything is GREEN with the exception of a few “rounding errors” that one company has because they were lazy and did not fix the rounding errors in their report.  This explanation mechanism helps you understand that the reported information is consistent with the expectations represented by the machine-readable rules that explain the logic or the report.

STEP 5: This is where you have to use your imagination a bit because I don't have an Excel application to show you.  While the Excel spreadsheet is used to validate the “fundamental accounting concept relations continuity cross checks”, the EXACT SAME IDEAS AND TECHNIQUES are used for the disclosure mechanics rules (structure, logic, mechanical, mathematical relations of EACH DISCLOSURE) and the reporting checklist rules (required disclosures, disclosures that are required if a specific line item is reported, etc.)

This video (a DRAFT, I am trying to piece together a nice storyboard) that I created walks you through how all this works.  You can “experience” all of this yourself.  That video basically walks you through this “explanation mechanism”.  Or, you could download and install the Pesseract software applicationwhich has essentially the exact same functionality.

IMAGINE THE POSSIBILITIES: Now, imagine that you had a process for verifying 100% of a financial report using automated processes like this.  In the demo that I am showing, I am only validating about 70 disclosures of the Microsoft report.  But Microsoft has a total of about 199 disclosures.  To make this work, I would have to create business rules for 100% of the disclosures Microsoft reports.  I call this the "bottom up" approach.  Think about this the other way around, what if you thought of this "top down" and created all disclosures based on machine-readable business rules.  Read this comparison between the bottom up and top down approach for more information.

Finally, think of that "top down" approach and how the business rules are being used after-the-fact, after a report is created for validating or querying that report.  What if the business rules led you through the logic of creating the actual report?  They call such systems expert systems.  Here is a proof of concept of such an expert system which is used to test the feasibility of such an expert system.

Here are some videos that help you think about the feasibility of such a system.

* * * * * * * * * 

I hope people find this helpful.  What is unclear?  Let me know.  I will try and improve this explanation until everything is crystal clear.

Posted on Friday, January 5, 2018 at 09:34AM by Registered CommenterCharlie | CommentsPost a Comment | EmailEmail | PrintPrint

Finding More Accounting Errors in SEC Filings

I mentioned that as a result of some work that I am doing, I am noticing accounting/reporting errors that public companies are making and their auditors appear to be missing in reports that I analyze.  Here is another example.  I am analyzing future minimum payments due under non-cancelable leases of a lessee which is a relatively simple and very standard disclosure. 

The Accounting Standards Codification (ASC) clearly states (840-20-50-2): (example ASC provides, link to example in ASC)

(Click image for larger view)

Notice how the accounting rules state, "..., in the aggregate and for each of the five succeeding fiscal years."

Further, the Wiley GAAP Guide disclosure checklist, the AICPA disclosure checklist, the KPMG disclosure checklist, and the Loscalzo Associates disclosure checklist all state exactly the same thing.

I can point you to 2,995 public companies that make that disclosure precisely as described in the ASC.  Here are 110 examples of what I would consider best practice representations of what both the Level 3 Disclosure Text Block and the Level 4 Disclosure Detail should look like. Basically, they all look like what is shown below; several line items and then a total of those several the line items:

(Click to view disclosure in XBRL Cloud Viewer)

But, in my process of debugging the rules I am using to test this; I have run across 11 public companies that don't provide that total. (i.e. "the 'in the aggregate' piece in the ASC).  Here are those 11 public companies which appear to have reporting errors: (click the link to view the disclosure in the XBRL Cloud Viewer)

I have run this by several other CPAs and all of them read the ASC the same way that I do. Now, honestly, I find that ASC description somewhat lacking.  It does not seem to discuss the "thereafter" line item.  It talks about the "five succeeding fiscal years" but it does not mention the "thereafter" line item which is necessary.

I ran across another error in the US GAAP XBRL Taxonomy.  The US GAAP XBRL Taxonomy appears to be missing a Level 3 Disclosure Text Block that relates to the lessor disclosure of future minimum payments receivable.  The US GAAP XBRL Taxonomy only seems to provide the lessee disclosure.  That is a different disclosure, but I ran across 46 public companies that were using the same Level 3 Text Block (i.e. for the lessee disclosure) for the lessor disclosure. Those are two different disclosures so they really need two different text blocks.

It is looking like Marthinus Cornelius Gerber, Aurona Jacoba Gerber, and Alta van der Merwe were correct.  In their paper, An analysis of fundamental concepts in the conceptual framework using ontology technologies, they explain how an ontology can be used to check the conceptual framework of a reporting scheme.  I am using a conceptual model and lots of business rules.  But in essence, we are doing the same thing.

Also, this is one step closer to what Jun Dai and Miklos Vasarhelyi of Rutgers University call Audit 4.0 in their paper, Imagineering Audit 4.0.

Granted, what I am doing is still rudimentary, but it is definitely a start.

Welcome to the Digital Age of accounting, reporting, and auditing.

Posted on Tuesday, January 2, 2018 at 03:00PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint