Digital Financial Reporting

The following is a summary of information related to the verification of XBRL-based financial reports. I have accumulated this information as part of trying to figure out how to verify SEC XBRL financial filings.

To start, let me define verification.  By verification I mean:

• An accountant or team of accountants can perform a specific set of steps which will allow them to be sure that the financial report which they created is a "true representation" or a "true and fair representation" of the financial information of the reporting entity for which the financial report has been created. (Note that the term "true and fair" has specific meaning and I may need to tweak these terms; auditors use the term "present fairly", but it would be hard for me to believe that "true and fair" is not a reasonable statement)
• Management of the company for which the financial report has been created can ask the team of accountants "are you sure these are correct" and the accountant or team of accountants can reasonably reply, "yes, we are sure".
• A third party accountant can state that a financial report presents fairly the financial information of the reporting entity because they have performed a specific set of steps which allow them to be sure that the financial report "presents fairly" such information.

The primary points here are that (a) verification is tangible proof that the financial report is "true and fair" and that (b) verification by the party who is not independent or verification by a third party that is independent has to do with WHO did the verification, not what work is done to verify the financial report.

What I want to stay away from here is the debate as to whether an auditor "audits" financial information expressed using XBRL.  There is a boatload of work that goes into making sure the numbers and other information are "presented fairly" and what exactly goes into the financial report.  That is definitely "audit" or "attest" type work.  I am not talking about that audit work.

There are two sources of information related to verify or "address the completeness, accuracy, or consistency of XBRL-Tagged Data" (basically, what one needs to do to achieve verification):

• AICPA SOP 09-1: Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data
• A paper, Assurance on XBRL Instance Document: A Conceptual Framework of Assertions, which analyzes AICPA SOP 09-1 and other documents which help achieve verification.

This blog post of mine has links to both of these documents. The second document has references to other resources. The second document, the paper, makes the following statement:

SOP 09-1 provides only an illustrative list of management assertions for handling the XBRL-tagging engagements under the SSAEs as agreed-upon procedures without considering a framework. Without a conceptual framework, the assurance process for XBRL instance documents would be ad hoc and inconsistent.

I agree with that statement, a conceptual framework is important.  The paper provides a conceptual framework.  I cannot tell if the authors are holding that out as "the conceptual framework".

Another important thing pointed out by the paper is that the reliability of software applications which are used to assist accountants, management or third party accountants is critical. One must understand what the software is doing, what it is not doing, and different software applications should perform the same fundamental processes in the same manner.  Today software is more like a "black box" and no one understands exactly what the software is doing and no software could possibly perform all the steps because the steps are not even defined adequately (more on that below).

I would point out that neither the AICPA SOP nor the paper provide a detailed set of steps that, if followed, would ensure that said document is correct, accurate, consistent, etc.  What I am wondering is how a conceptual framework can be specified without knowing all the detailed steps which are necessary.  Maybe you can do that, but it has been my experience that people who try and summarize things before they understand all the details tend to make mistakes and leave things out.

I would point out that there are three things I believe that both the AICPA SOP and the paper are doing which I believe should be done differently.

1. Both mix terms that relate to the XML/XBRL technical syntax and terms that relate to semantics. It is my view that there is no need to use terms that relate to technical syntax at all.
2. Both focus on "XBRL". What if other formats for expressing financial information come to exist or of someone chooses to use RDF/OWL or some other form of XML?  Further, it is because there is a focus on XBRL here that leads to mixing the XML/XBRL technical syntax and financial report semantics and terminology which is both hard to follow and difficult for a business person to understand.
3. Neither provide enough details as to the steps necessary.

Fundamentally, I believe that a set of verification assertions has no need to consider the medium or format by which the financial information is being made available; be that format traditional financial reports made available on paper; in electronic form such as Word, HTML, or PDF; or even digital form such as XBRL, RDF/OWL, other forms of XML; or other digital formats/mediums such as within some sort of software application for viewing or otherwise consuming financial information.

The Financial Report Semantics and Dynamics Theory has no regard for medium or format of financial reports. This theory breaks financial reports into pieces which are understandable to business users:

• Financial report: Report which communicates financial and nonfinancial information to users of that report.  Contains facts, characteristics which describe those facts.
• Fact: A piece of information which is reported in a financial report. Facts have values which could be textual, numeric, or prose. Numeric facts have two additional traits: units and rounding. Facts may have one or more additional parenthetical explanations.
• Characteristic: A characteristic provides information necessary to describe a fact. A fact may have any number of characteristics.
• Parenthetical explanation: A parenthetical explanation provides additional descriptive information about a fact.
• Component: A component is a set of facts which go together for some specific purpose within a financial report.
• Relation: Facts can be related to other facts.  Characteristics can be related to other characteristics.
• Property: Facts have a known and finite set of properties. Characteristics have a known and finite set of properties.  Components have a known and finite set of properties. The concept characteristic has additional properties: period type, data type, balance type. Relations have a known and finite set of properties.

This video walks you through this set of primitive or fundamental or rudimentary building blocks of a financial report. These building blocks have no regard for medium/format.  I believe they are understandable to business users.  While business users may disagree on the name of the building block, it is rather hard to dispute the notion of these rudimentary building blocks.

And so, if there are a set of building blocks and if that set of building blocks and each building block's properties are finite; it seems to me that a definable, finite set of steps can be articulated and if one does not lock themselves into one technical syntax, then you can rely on only financial report semantics to articulate these steps.

To be clear I want to list the high level objectives which I believe are important to verify a financial report and define some important terms:

• Completeness: Having all necessary or normal parts, components, elements, or steps; entire.
• Correctness: Free from error; in accordance with fact or truth; right, proper, accurate, just, true, exact, precise.
• Consistency: Compatible or in agreement with itself or with some group; coherent, uniform, steady. Holding true in a group, compatible, not contradictory.
• Accuracy: Correctness in all details. Conformity or correspondence to fact or given quality, condition. Precise, exact. Deviating only slightly or within acceptable limits from a standard.
• Fidelity: Where accuracy focuses on the details of one fact; fidelity is accuracy of all facts considered as a whole in the reproduction of something as compared to actual facts.
• Integrity: Holistic accuracy, accurate as a whole. The quality or condition of being whole or undivided; completeness, entireness, unbroken state, uncorrupt. Integrity is a concept of consistency of actions, values, methods, measures, principles, expectations, and outcomes.
• Validity: Complete, correct, consistent, accurate, has fidelity, has integrity.

I have provided a detailed set of characteristics of a quality financial report, I repeat that set of characteristics here having "tuned" them to the Financial Report Semantics and Dynamics Theory and the other ideas and notions I have come across:

• True and fair representation of financial information: The objective of a financial report is to provide a true and fair representation of the entity which issued the financial report. A financial report is a true and fair representation if it is complete, correct, consistent, accurate, has fidelity and integrity. Validity.
• All financial report formats convey the same message: A financial statement can be articulated using paper and pencil, Microsoft Word, PDF, HTML, XBRL, or other format. But while the format may change, the message communicated, the story you tell, should not change.  Each format should communicate the same message, regardless of the medium used to convey that message.
• Information fidelity and integrity: A financial statement foots, cross casts, and otherwise "ticks and ties".  As accountants we understand this and many times this fact disappears into our unconsciousness because it is so ingrained.  Of course things foot and cross cast; of course the pieces tie together. Said another way, a financial statement must be correct, complete, consistent, and accurate. Only trained accounting professionals who understand how the XBRL medium works can tell if all financial statement computations are properly articulated and verified to be correct.
• Justifiable/defensible report characteristics: Facts reported and the characteristics which describe those reported facts should be both justifiable and defensible.
• Consistency between periods: Generally financial information expressed within one period should be consistent with the financial information expressed within subsequent periods, where appropriate.  Clearly new information will be added and information which becomes irrelevant will be removed from a financial report.  Changes between report elements which existed in both periods should be justifiable/defensible as opposed to arbitrary and random.
• Consistency with peer group: If your company chooses one approach and a peer chooses another report element selection choice; clearly some good reason should probably exist.  This is not to say differences would not or should not occur.  Rather, why the differences exist should make sense.  Generally financial information between two peers should be more consistent as compared to inconsistent.
• Information renderings make logical sense: Renderings of facts and characteristics which make up the components of a financial report should make logical sense. The financial report rendering should make logical sense without regard to the format of the financial report.
• Clear business meaning: A financial report should be unambiguous.  The business meaning of a financial report should be clear to the creator of the financial report and likewise clear to the users of that financial report.  Both the creator and users should walk away with the same message or story. A financial report should be usable by regulators, financial institutions, analysts, investors, economists, researchers, and others to desire to make use of the information the report contains.

As such, I venture to summarize all these pieces into a set of risks, assertions to overcome that risk, whether the verification can be automated or must be manually performed, and the required skill level necessary to perform such step:

• Risk - Full inclusion: All relevant facts, characteristics which describe facts, and parenthetical explanations are not included in the financial report. Assertion - Completeness: All relevant business facts, characteristics of those business facts, and parenthetical explanations of those facts have been included. Manual by person with accounting skills.
• Risk - False inclusion: No facts, characteristics which describe facts, or parenthetical explanations which should not be included have been included. Assertion - Existence: No facts characteristics which describe facts, or parenthetical explanations of those facts are included within financial report which should not be included. Manual by person with accounting skills.
• Risk -Inaccuracy: Property of a fact, characteristic, component, or relation is inaccurate. Assertion - Accuracy: The properties of all facts, characteristics, components, relations are accurate, correct, and complete. Some automated, some manual by person with accounting skills.
• Risk -Infidelity: All facts, characteristics, and relations considered as a whole do not provide the necessary fidelity. Assertion - Fidelity:  Considered as a whole, the facts, characteristics, and relations properly reproduces the financial and nonfinancial facts, characteristics, and relations of the reporting entity. Some automated, some manual by person with accounting skills.
• Risk -Integrity not intact: Integrity between facts and characteristics is inappropriate. Assertion - Integrity: Considered as a whole, the facts and characteristics of those facts reflect the true and proper relations between facts and characteristics. Some automated, some manual; to the extent that a relation is expressed testing of relations can (and should) be automated rather than manual, accounting skills.
• Risk -Inconsistency: The facts, characteristics, their relations and their properties expressed are inconsistent with prior reporting periods or with peers of the reporting entity. Assertion - Consistency: The facts, characteristics, relations, and their properties are consistent between financial report periods and with peers, as is deemed appropriate. Some automated, some manual by person with accounting skills.
• Risk -Not presented fairly: The financial report is not presented fairly, in all material respects, and are not a true and fair representation in accordance with the financial reporting framework applied. Assertion - Presented fairly in all material respects: The financial report is presented fairly, in all material respects, and provide a true and fair representation in accordance with the financial reporting framework applied (US GAAP, IFRS, etc). Some automated, some manual by person with accounting skills.

So now I need to come up with the precise detailed steps for all of this and then cycle those through all this information to be sure the big picture and the details fit together.  Give that I have already been through all these detailed steps with my model/reference implementation for an SEC XBRL financial filing I do understand most of the steps (here are the steps which I have thus far, they are also detailed and explained in this document which explains the working prototype verification application which I created).  Basically, what I really need to do is organize those detailed steps within this framework.