Digital Financial Reporting

I have developed a technique that uses standard, off-the-shelf software or existing open-source software to make certain that the high-level fundamental accounting concept relations are (a) intact and consistent and (b) assure that a user of the report can reliably extract information from an XBRL-based financial report.

Further, if the SEC enforced its own rules that require XBRL calculations to be provided, then the entire balance sheet, income statement, cash flow statement, statement of changes in equity; and any disclosure that ties to those statements would also be verified to be correct (roll ups).  This would still leave roll forwards and dimensional roll ups not being computed however because.

But, if software vendors and filing agents helping public companies create XBRL-based reports would use XBRL Formula during the creation process to verify all mathematical relations, then 100% of all facts that are on the primary financial statements or tie to the primary financial statements would be verified to be mathematically consistent with what one would expect.

Let me say this again.  If the technique described in the first paragraph were used, then all of the fundamental accounting concept relations continuity cross checks would be passed by every software vendor and filing agent.  What that would mean is that the validation results would look like this:

Note that there are ZERO inconsistencies with the high-level fundamental accounting concept continuity cross checks.

So, how does my technique work?  It works like this: Each public company declares and/or configures their "reporting style" or their fundamental accounting concept relations when they create their report using machine-readable rules.  The SEC could build upon this by (a) requiring reporting entities to include this declaration/configuration in their report and (b) providing validation that MUST be passed for a report to be accepted as filed with the SEC.

The process works like this:

1. Define concepts: Each fundamental accounting concept is represented in machine-readable XBRL form, like this.
2. Define impute rules: Each "impute rule" that is used to derive unreported facts is created in machine-readable XBRL form, using XBRL Formula.  Here are two impute rules for deriving commonly unreported subtotals: Noncurrent Assets | Liabilities. (Ugly and hard for humans to read, yes I know; but (a) experts would create these rules that average accountants would use and (b) the users would interact with natural language representations of the rules such as "Assets = Current Assets + Noncurrent Assets" and "Liabilities = LiabilitiesAndEquity - Equity".) (Here are the 105 impute rules that I use)
3. Define consistency rules: Each "consistency rule" would be defined in machine-readable XBRL form, using XBRL Formula.  You would create sets of these rules for each statement format.  Here are two examples: Classified Balance Sheet | Order of Liquidity Balance Sheet (Unclassified) (Here are the 49 consistency rules I use)
4. Declare/Configure: Those creating reports would select (a) the consistency cross checks rules that described their reporting style and (b) any impute rules that are necessary for a machine to understand their high-level reported information. They would include the rule sets in their XBRL instance by referencing the rules.  The rules could be included during the report creation process to test the consistency of the report to the consistency rules.  The rules could be REMOVED from the XBRL instance prior to submitting to the SEC until such a time, if ever, that the SEC allows the rules declaring/configuring the fundamental organization of the report are allowed to be submitted.
5. Result: The result would be (a) machine-readable rules that explicitly explain/declare the configuration of the report and (b) machine-based processes for verifying the consistency of the report to the declared configuration using existing off-the-shelf or open source XBRL processors and/or XBRL Formula processors.

This ZIP file contains a working proof of concept.  This was run using the UBmatrix XBRL Processor and XBRL Formula Processor. This is the command line BATCH file that I used. I am going to test this same working proof of concept using Fujitsu, XBRLQuery, XBRL Cloud, and any other XBRL processor/XBRL Formula processor that I can get my hands on or get someone else to test.

This may not be the most effecient way to process this, but it does work effectively.

What I can imagine is that the Big 4 CPA firms and other interested parties will provide a lot of valuable input as to what is an allowed financial report configuration under US GAAP and IFRS.

I am going to create a version of the IFRS Fundamental Accounting Concept Relations metadata on GitHub to check out how that works. This will include the reporting styles, mapping rules, impute rules, and consistency checks.

If you are not familiar with GitHub, create an account (which is free) and work throught this tutorial. That will get you started.

Here is my initial repository: fac-ifrs (master)

I have someone helping me get started.  I am going to keep the same technical syntax in this version.  The files will simply be pulled from this GitHub location and people will be able to contribute, branch, etc. using the GitHub functionallity.

There are great videos on how to use GitHub.

Another alternative to GitHub is BitBucket. The good thing is that there are alternatives.  Now, I have to figure how which is better, GitHub or BitBucket.

The accounting model explains how double-entry bookkeeping works.  The double-entry accounting model is a mathematical model explained in Luca Pacioli's book about mathematics, Summa de arithmetica.  The mathematical model was consciously created to be redundant (i.e. double-entry) in order to better detect mistakes and to distinguish a mistake from fraud.

I am not going to go into details, if you want to know that read about the accounting equation, you can watch this video that explains the accounting model, and you can watch this video which expands on that model and explains the logic of debit and credits.  The primary point I want to make is that accounting is a model.

A financial analysis model is likewise a model.  There are many different types of financial analysis models. Again, I am not going to go into details, if you want to learn about creating a financial model, there are plenty of resources like this video. The primary point here is that financial information is analyzed using financial models.

And so why do many accountants believe that a financial report is a document?  A document is a type of knowledge media.  There are other types of knowledge media: word of mouth, book, video, etc.  What makes something a knowledge media?

1. Easy for knowledge bearer to represent information: The effort and difficulty required for the knowledge bearer to successfully formulate the knowledge in the medium must be as low as possible.
2. Clear, consistent meaning: The meaning conveyed by the knowledge bearer to the knowledge receiver must be clear and easily followed.
3. High-quality information representation: The form in which the knowledge is represented via the media to the receiver must be as good as possible.

The purpose of a general purpose financial report is to convey information about the financial position and financial condition of an economic entity.  Two types of information are conveyed: quantitative and qualitative. Again, not going into details here. Both quantitative and qualitative information are important.

It is not much of a stretch to make the claim that the information that comes out of the accounting model (i.e. the general ledger transactions) and might go into a financial model should likely best be a model and not a document.  And so certainly aspects of a financial report is a model such as the balance sheet, income statement, cash flow statement, and all the disclosures that tie to the line items of those statements.

But the qualitative information can also be represented in the form of a model.  For example, inventory is an important number; but it is likewise important to understand if that inventory is valued using LIFO or FIFO and to what extent a reserve exists to capture the difference between inventory cost and the current market value of the inventory.  The qualitative information of a financial report helps to further explain the quantitative information.

At the top level, all financial reporting schemes are the same: assets = liabilities and equity (or some modified version of that equation).  At the next "layer" both US GAAP and IFRS tend to be relatively the same in terms of high-level concepts such as "current assets" and "current liabilities", etc.  Companies can report using different patterns, which I call reporting styles.  No problem.  Ambiguities in reporting standards, misunderstandings of reporting rules, and other such things impact what goes into the model and how those things might be orgnaized; but a financial report has a model.

Accounting was first formally described in about 1494, long before databases and computers existed.  As such, accountants use whatever tools they had available to represent financial reports.  That ended up being paper-based documents.  When computers came along, accountants seemed to have forgotten about the accounting model and started representing documents in tools such as spreadsheets, not the accounting model.  Today we have different tools.  Some of those tools quite possibly could be better than paper for representing financial reports.

Experiment

I am going to do an experiment with a number of other accountants that want to learn about XBRL (contact me if you want to be considered for inclusion). 

I have represented general ledger trial balance information using XBRL.  I have represented financial statements using XBRL.  And I have represented financial models using XBRL.  What is interesting is that I can get the GL transactions, the financial report, and the financial models into one XBRL document.  That is actually really easy as they all share the XBRL global standard technical syntax.  Further, they all share the same business report multidimensional model and conceptual model.

But what ends up happening is because of the "taxonomy spaghetti" that tends to exist; the general ledger representations, the financial report representations, and the financial model representations are not well syncronized semantically.  I am going to fix that.

What I am going to do is create a syncrnozied version of the general ledger transactions, the reported financial information, and the financial model; all using the same XBRL taxonomy where they should.  I will make this robust enough so that it is a good exercise but simple enough to be understood by the average accountant and hopefully even non-accountants.  I am going to follow best practices.  I am going to use what I call my "XASB" taxonomy for this first iteration so that I am not constrained by the idosyncricies of the US GAAP or IFRS taxonomies or public company reports.

As a second step, I will repeat this exercise for a US GAAP report and an IFRS report.

This will likewise be an excellent test of software that I am using. 

Stay tuned if this sounds interesting to you! Again, if you want to participate please contact me directly.

This is a summary of what I have created in the prior versions of GL transactions, financial report, and financial model:

• General ledger transactions (summary information)
  • XBRL instance (note that XBRL formulas are connected here)
  • XBRL instance using Inline XBRL
  • XBRL instance using Inline XBRL, auto-generated
  • XBRL taxonomy
  • Rules (machine readable)
  • Human readable rendering (human readable)
  • Additional validation (human readable)
• Financial report (summary information)
  • XBRL instance (note that XBRL formulas are connected here)
  • XBRL instance Inline XBRL, auto-generated (this has an error that needs to be fixed)
  • XBRL taxonomy
  • Rules (Reporting checklist, disclosure mechanics; required because taxonomy is OPEN)
  • Human readable rendering
  • Additional validation (reporting checklist, disclosure mechanics)
• Financial model (DCFM) (summary information)
  • XBRL instance
  • XBRL instance, Inline XBRL format
  • XBRL taxonomy
  • XBRL formulas
  • Human readable rendering
  • Additional validation (none necessary, taxonomy is closed)
• Other helpful information (summary of about 700 pages collected and organized over past 20 years)
  • Computer Empathy
  • Blueprint for Creating Zero-defect XBRL-based Financial Reports
  • Digital Financial Report Creation Best Practices
  • Pesseract(tool for viewing XBRL-based reports)

There you have it.  If you feel you might need more information, please let me know what it is that you think you need.

I have updated my set of IFRS-based financial reports that have been submitted to the SEC.  I am using these filings to create IFRS metadata including the reporting styles.  Here is a list of what I have:

• Human readable list of the now 406 IFRS filings.
• Machine readable RSS feed of those same 406 IFRS filings.
• IFRS Reporting Styles Analysis.
• ZIP archive containing Excel spreadsheets that prove the reporting styles.
• List of the current reporting styles. (Details)
• IFRS Reporting Styles Summary. (Overview)
• List of manually organized and classified statements and disclosures.
• ZIP archive with XBRL taxonomy model structure and roll up relations.
• ZIP archive of XBRL instances.
• Roll up query tool. (New, work in progress)
• Roll up query tool linked to reporting style mappings. (New, work in progress)
• Analysis of errors in one reporting style

Basically, I added about 90 form 40-F filings that use IFRS of Canadian companies.  Stay tuned! More to come.

Here are some updates to the reporting styles:

1. This summary and detailed information is the most current.
2. Those reporting style rules (#1) are 100% synchronized between XBRL Cloud, Pesseract, and the Excel versions and tested to be sure they are consistent.
3. This set of Excel spreadsheets in the ZIP file have the rules for the classified balance sheet (BSC), typical cash flow statement (CF1), and the most common income statement (SPEC6).
4. I made most of the adjustments requested by others:
   1. Commitments and contingencies was REMOVED from all balance sheets.
   2. Temporary equity was REMOVED from all balance sheets.
   3. Many of the codes such as BSC, BSU, SPEC6, CF1 are now included in the XBRL taxonomy and related documentation.
   4. I removed the network and rules related to Preferred Stock Dividends and Other Adjustments, and Net Income (Loss) available to Common that are not applicable to IFRS.
   5. I removed other stuff associated with US GAAP that is not applicable to IFRS
   6. I fixed the issue related to the Revenues concepts being in the wrong order.
   7. I fixed the issue related to "ifrs-full:OperatingExpense".
   8. I added the 2018 IFRS taxonomy.
5. I had two separate creation tools for the "controlled natural language" format and the "XBRL Formula" XPath 2.0 rules format.  Now this is ONE tool. (i.e. doing things now takes half the time).
6. Here are all the rules I currently have in both XBRL Formula (XPath 2.0) format and the Controlled Natural Language (i.e. Excel-ish type) format: (note the LINKS to the actual XBRL Formulas)
   1. Consistency
   2. Impute
7. Here are all the networks.
8. Here are all the fundamental accounting concepts.
9. Here are the mappings.
10. Here are the fundamental accounting concept relations in presentation form.
11. And here is the PROOF that all this works (I will update this empirical evidence of actual filings as I add new reporting styles)

Like I said, stay tuned.  If you don't understand why I am doing all this, you may want to consider reading this document.

The Securities and Exchange Commission have published a draft strategic plan for 2018 to 2022.  The strategic plan summarizes the SEC's mission, vision, values, and goals.