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.