Digital Financial Reporting

Consider this scenario:

Two public companies, A and B, each have some knowledge about their financial position and financial condition. They must communicate their knowledge to an investor who is making investment decisions which will make use of the combined information so as to draw some conclusions. All three parties are using a common set of basic logical principles (induction, deduction) and common financial reporting standards (i.e. US GAAP), so they should be able to communicate this information fully, so that any inferences which, say, the investor draws from public company A's input should also be derivable by public company A using basic logical principles and common financial reporting standards, and vice versa; and similarly for the investor and public company B.

This scenario has worked for about a hundred years in the US with a bit of help from regulators setting common financial reporting rules and requiring public companies to report specific information. But the parties exchanged this information using paper or "electronic paper" (HTML, PDF).

Now, think about doing this electronically/digitally and getting public company A, public company B, and the investor on the same page. Think about machines communicating and moving information between the systems of public companies, the systems of investors, and the systems of regulators.

ISO TR 9007:1987 (“Helsinki principles”) state:

• Any meaningful exchange of utterances depends upon the prior existence of an agreed set of semantic and syntactic rules
• The recipients of the utterances must use only these rules to interpret the received utterances, if it is to mean the same as that which was meant by the utterer

In a prior blog post I explained that Z Notation is an ISO/IEC standard for describing systems precisely. A problem with Z Notation is that it is not machine-readable.

There is another ISO/IEC standard, Common Logic, which is machine-readable. (Also see the Common Logic Wikipedia page.)

Here are some resources for understanding Common Logic:

• Why is Common Logic Necessary?, motivation for Common Logic
• Introduction to Common Logic, high level overview of Common Logic
• XML Common Logic (XCL) 1.0, which is a concrete serialization syntax for Common Logic
• ISO/IEC Common Logic Download, PDF in a ZIP archive
• Details about Common Logic, shows some of the uses
• Common Logic/RuleML Wiki
• Common Logic and Conceptual Graphs

Common Logic is about being practical.  Common logic is a compromise in order to achieve reliability, predictability, and safety.  Common logic is a "sweet spot" that achieves high expressivity but consciously gives up certain specific things that make a system unsound, so that a system will be sound. 

Common logic establishes boundaries, allowing creators of systems to "stay within the lines" and if you do, you get a more reliable, dependable system.  SQL databases are consistent with Common Logic.  SQL databases enforce constraints on data.

XBRL-based information likewise enforces constraints on information contained in, say, the financial report of a public company which is submitted to the SEC.  Just because public companies creating reports, the SEC which receives the reports, or investors using the reported information don't have to machine-readable logical rules (like I do) does not mean that the rules don't apply.  It only means that public companies, the SEC, and investors are ignorant of illogical statements being made in XBRL-based financial reports.

Don't be ignorant of information quality issues.  Use machine-readable business rules.

In a thought provoking article, The End of Code, Wired writer Jason Tanz explains why you will not need to understand how to code to get computers to perform useful tasks for you.  This statement pretty much summarizes the article:

Programming won’t be the sole domain of trained coders who have learned a series of arcane languages. It’ll be accessible to anyone who has ever taught a dog to roll over.

What he does not explain precisely are the pieces that will make this work.  If you have been following my blog you know what some of those pieces are.  If you want to know the others be sure to stay tuned.

If you want to catch up, please read through Knowledge Engineering Basics for Accounting Professionals.

I have updated the document 10 page Conceptual Overview of an XBRL-based, Structured, Digital Financial Report.  It is still not exactly what I want it to be, but it does now capture the full essence of what I am trying to communicate.

Even if you have read this 10 page document before, it is worth doing so again.  If anyone has ideas to improve the document even more, please send the ideas my way.

Long standing errors in the XBRL-based financial reports of public companies are being corrected.  Here is a sample of companies where a long standing error has existed but is ultimately corrected: 

• Chubb, inappropriate use of concept to represent income from continuing operations on income statement
• Publix, inappropriate extension concept related to their ESOP
• Tesla, concept used in a disclosure which conflicted with what they were saying on the balance sheet
• Violin Memory, Inc, inappropriate use of the concept us-gaap:LiabilitiesNoncurrent
• VERTEX PHARMACEUTICALS INC, inappropriate use of the concept us-gaap:NetCashProvidedByUsedInContinuingOperations in representing cash flow
• Tesla, inappropriate use of concept in cash flow statement
• Wayfair Inc, inappropriate use of concept in cash flow statement
• Wonhe High-Tech International, Inc, inappropriate concept for line item Income (loss) from operations
• Youngevity International, Inc, temporary equity concept used to represent equity on balance sheet
• First Guaranty Bancshares, Inc, error related to provision for loan losses
• First National Corp, error related to provision for loan losses
• First South Bancorp Inc, error related to provision for loan losses
• Form Factor Inc, inappropriate use of concept on cash flow statement
• HIGHLANDS BANKSHARES INC, error related to provision for loan losses
• JAKKS PACIFIC INC, conflicting revenue concepts

Also, many filers have corrected their 10-Q filings but issues persist within the 10-K.  Typically these errors relate to conflicting information within a disclosure and within the primary financial statements.  Here are samples of filers that have issues in their 10-K, but their 10-Q is correct:

• Diversicare Healthcare Services, Inc, conflicting healthcare revenue concepts
• West Marine Inc, conflicting use of concept us-gaap:IncomeLossFromContinuingOperations
• Westlake Chemical Corp, conflicting revenues concepts on income statement and in disclosure
• Windstream Holdings, conflicting revenues concept on income statement and in disclosure
• CITIZENS FINANCIAL SERVICES INC, error related to provision for loan losses
• Civeo Corp, improper use of concept us-gaap:AssetsNoncurrent in a disclosure
• CUMBERLAND PHARMACEUTICALS INC, conflicting revenues concepts related to disclosure
• Delek US Holdings, Inc, inappropriate use of equity concept
• Enable Midstream Partners, LP, contradictory revenue facts
• FARMERS & MERCHANTS BANCORP, error in provision for loan losses

And just to round this out and to show that it is very possible to get 100% of the information within 100% of all filings correct, here are some examples of public companies that achieve this result.  I am showing income statement examples because the income statement is where most errors tend to exist.  Here are public companies that have no inconsistencies in their income statements (i.e. this is what all filings SHOULD look like):

• Volt Information Sciences (income statement)
• Tesla (income statement)
• Wayfair Inc (income statement)
• Apple (income statement)
• Cisco Systems (income statement)
• Microsoft (income statement, they do have ONE error)
• Wells Fargo (income statement, interest-based revenues)
• Anchor Bancorp (income statement, interest-based revenues)
• National Security Group (income statement, insurance-based revenues)
• PRUDENTIAL ANNUITIES LIFE ASSURANCE CORP, (income statement, insurance-based revenues)
• Elite Books (income statement)
• Stellar Biotechnologies, Inc, (income statement)

So, it is possible to get 100% of all filings 100% correct.  There is plenty of evidence of that.