History of Fundamental Accounting Concepts (FAC)

Way back in like 2012 when XBRL-based reports were first starting to show up in the SEC's EDGAR system, I started trying to extract information from those reports.  Being an accountant, I realized that not every reporting entity provides information in one consistent way.  I tried to create one Excel spreadsheet for extracting information from ALL XBRL-based reports submitted to the SEC but I could not make that work because of my limited programming skills.  For example, trying to make the code work for when a multi-step income statement was used (e.g. reports gross profit) and when a single-step income statement was used could work...until I tried to cover all styles of income statements; and then I became overwhelmed.

That is when I changed to creating separate Excel spreadsheets for each style of reporting. This blog post has like 13 such Excel spreadsheets for extracting information from XBRL-based reports. That worked, but that approach is not flexible or practical.

This is when I got XBRL Cloud involved and we did something interesting.  What XBRL Cloud and I were able to do was to create a syntax similar to what I was using to extract information from Excel.  Effectively, what we did was create a set of text files (proprietary format) that fed information to XBRL Cloud software which used that information to apply the proper reporting style (originally called "report frames" or "reporting pallet") for the reporting entity.  That also entailed putting a code into a database to indicate what company reported using what style.

The database lookup of reporting style codes worked, but then I created a more flexible approach to look up reporting style codes.  I created a web service.  (This is the actual web service, the other page is a human readable version of the web service information.  The web services ran on top of a Microsoft SQL Server database which I could update.  Obviously, it would be best to autodetect reporting styles; but we have not gotten around to doing that yet.

But I was not happy with what we created for XBRL Cloud even though it did work.  What I had to do is generate a set of proprietary text files, put them in a ZIP archive, and then upload them to XBRL Cloud every time I needed to change a rule.  Besides, this was proprietary syntax.  I needed something better.

With Pesseract in about 2015, I converted the proprietary syntax to XBRL syntax using XBRL definition relations and XBRL formula.  Here is about the third iteration of what I came up with. The set of reporting styles is provided in an RSS feed which serves like a lookup table.  That is the only part that is not XBRL, that RSS lookup table.  Form there, using the web service for looking up the reporting style code; you could get to the proper rules for a report.  What this achieved was (a) the rules format was no longer proprietary and (b) rules were separated from code for processing the rules.

That worked pretty well, but there was one major problem with the derivation rules.  I made the mistake of testing to see if a fundamental concept had a value by testing for a value of 0.  If the value of a fundamental concept was 0, then I would execute derivation rules to impute the value.  The problem with this is that reporting entities sometimes reported a value of zero.  So, I would try and derive a value when the reporting entity actually "said" (by reporting it); the value of the fundamental concept was 0.

What I really wanted to do is to test if a fundamental accounting concept EXISTED in a report (i.e. was it reported).  And so, I also realized that I needed to change the type of XBRL Formula derivation rule I was using.  I was using this format which is an IF...THEN statement which was incorrect.  But I was instructed that I should be using a PRECONDITION, and so changed to this format of a derivation rule.

And so I changed from "VERSION 1" of the fundamental accounting concept relations continuity cross checks to "VERSION 2" in about 2016 or 2017.  But I did not have any software to test the new approach and I also had a lot of rules that I was reluctant to change and potentially break.  So VERSION 2 sat on the shelf for a while.

Then, Auditchain created Pacioli (this is the Pacioli Power User Tool) which was the first to support both the old VERSION 1 and the new VERSION 2 rules, I carefully converted the existing rules to the new VERSION 2 format and made sure everything worked as expected.  So Auditchain Pacioli can use VERSION 2 or VERSION 2 of the rules.

Here is a validation run of the 2021 10-K of Fortune 100 companies run by Auditchain Pacioli.

Here is the best version of human readable fundamental accounting concepts relations continuity cross check rules for both US GAAP and IFRS.  Note that these have not been tested for functionality.

The best set of VERSION 2 rules that I have checked is these rules for the COMID-BSC-CF1-ISM-IEMIB-OILY-SPEC6 reporting style which is the most common style, used by about 1400 public companies. (human readable).  This is only ONE reporting style.  But it exemplifies how FAC rules will be created going forward.

Future work includes autodetecting reporting styles and autogenerating derivation rules which, as I understand it, is possible.

Here is the last batch of fundamental accounting concept continuity crosschecks of 10-Ks submitted to the SEC that I have performed using XBRL Cloud for FY 2018 10-Ks.

Additional Information:

• Examples of Errors in XBRL-based Digital Financial Reports
• Fundamental Accounting Concepts Verification for Microsoft
• Microsoft XBRL-based report analysis
• US GAAP:
• US GAAP Reporting Styles
• US GAAP Fundamental Accounting Concepts (FAC)
• US GAAP Fundamental Accounting Concept Relations (Rules)
• US GAAP Fundamental Accounting Concept to US GAAP Reporting Concept Mappings
• FASB Concept Statements (conceptual framework)
• IFRS Conceptual Framework