Digital Financial Reporting

One of the issues which the financial reporting community will need to address can be demonstrated by looking at the disclosure of significant accounting policies in SEC XBRL financial filings.  The issue is a general issue, it relates to many areas of a financial report. There really is no "right" or "wrong" answer, there are just different approaches and each of those approaches has "functionality" which it delivers. You may, or may not, see this as a "change to financial reporting" or a "change in US GAAP".  That is not the point of making this information available.  The point is to help accountants to understand the issue.

The issue relates to the difference between unstructured information and structured information. With legacy approaches to creating a financial report the information disclosed is basically unstructured an therefore there is no "box" that information must fit into.  You can understand "the box" by realizing that when you move from unstructured to structured information, you basically take the unstructured information, structure it in some way (thus creating the box), and you put the information into a box.

The "box" is not good or bad, it is just a box.  It is not that unstructured is good and structured is bad; or that structured is good and unstructured is bad.  They are just different.

So here is what I mean.  If you understand financial reports, then you know that within a financial report, such as within an SEC financial filing, you have to disclose significant accounting policies.  If you look at SEC XBRL financial filings (which I have, more info later) you will see that 100% of the 10-K filings disclose significant accounting policies.  Reporting rules require this.

But, filers structure this disclosure using XBRL in different ways.  Here are the primary ways I see this done (this is looking at only the [Text Block] or (Table) which every SEC filer provides in their SEC XBRL financial filing:

• Significant Accounting Policies (us-gaap:SignificantAccountingPoliciesTextBlock) is used most.
• Basis of Presentation and Significant Accounting Policies (us-gaap:BasisOfPresentationAndSignificantAccountingPoliciesTextBlock) is a distant second
• Business Description and Significant Accounting Policies us-gaap:BusinessDescriptionAndAccountingPoliciesTextBlock) is next
• Basis of Accounting (us-gaap:BasisOfAccounting)
• Organization, Consolidation, Basis of Presentation, Business Description and Accounting Policies (us-gaap:OrganizationConsolidationBasisOfPresentationBusinessDescriptionAndAccountingPoliciesTextBlock)
• Organization, Consolidation and Presentation of Financial Statements Disclosure and Significant Accounting Policies (us-gaap:OrganizationConsolidationAndPresentationOfFinancialStatementsDisclosureAndSignificantAccountingPoliciesTextBlock)

Now, some filers (very few) decide that none of those concepts work for them and decide to create extension concepts. Those are obviously errors and one of the existing concepts should have been used.

But, other filers combine different things together and do feel obliged to create an extension concept and it creating such a concept can be justified.  For example, one filers created the concept Summary Of Significant Accounting Policies And Recent Accounting Pronouncements [Text Block].  They combined two things which both have concepts which exist in the US GAAP Taxonomy; but is this the right thing to do?

THAT is the issue.  Basically, it is possible to come up with all sorts of permutations and combinations of information.  Each permutation/combination needs to have a "box" or concept created so that the SEC filer can put the information inside that box.  This is the way they have always reported.

But, the filer creating such a concept basically makes comparing information significantly more challenging.  You can still do it, you just need to map the filer extension concept to some other concept which is defined to include significant accounting policies.

Or, alternatively, the filer could unbundled the information into the two concepts which exist; separating "Significant accounting policies" and "recent accounting pronouncements" into two separate boxes.  This reduces the permutations and combinations.

So, it seems that the spectirum of options is as such:

• Provide lots and lots of permutations and combinations, and still allow a filer to create more permulations and combinations
• Provide lots and lots of permutations and combinations, but DON'T allow the filer to create other possible permulations/combinations
• Require SEC filers to unbundled their disclosures, and also their financial statement line items, into discrete disclosures/line items (i.e. get rid of the bundles)

Like I said, there is not necessarily a right or wrong answer here; it is just a choice which the financial reporting supply chain needs to figure out.  What would be good is to understand the pros and cons of each alternative, all things considered.

And I point out again; this is not just an issue with significant accounting policies; it is a general issue for which I am pointing out with this significant accounting policies example.

Which alternative do you feel is the best choice, all things considered?

Raynier van Egmond and I have updated the Financial Report Semantics and Dynamics Theory and a new version is available. Most of the changes were correcting typos and other minor adjustments.  This is a summary of the more significant changes:

• A different document style was used.
• The notion of a "property" was added.  Components, facts, characteristics, parenthetical explanations, and relations each have properties.
• Work relating to verification of a financial report is being incorporated; the biggest addition here are the definitions of terms which constitute a "true and fair" financial report: completeness, correctness, consistency, accuracy, fidelity, and integrity.  (See section 4.1)
• A "Future Work" section was added, making it more explicit that there are additional semantics which would build on the eight tests we ran against SEC XBRL financial filings.

No one really came up with anything credible which refutes this theory. One person called the theory a slogan but gave no credible justification for that view.

Periodically I take a look at SEC XBRL financial filings in order to better understand those filings.  I have a number of resources which I use.  The filings which I am analyzing are 10-K, 10-K/A, 10-Q, and 10-Q/A filings made between November 1, 2011 and February 29, 2012 per the SEC RSS feed archive. The total number of filings which I obtained was 4416.

Here are some of these resources which you might find helpful in order to explore and better understand SEC XBRLfinancial filings:

• Excel spreadsheet with all 4416 filings. Basic Excel spreadsheet with all the filings, information relating to core financial report semantics, and other information.
• Excel-based taxonomy explorer. Excel spreadsheet with macros which allows you to load filer taxonomy into an Excel spreadsheet, view the taxonomy within a tree view control, explore various lists of filers (prototype).
• HTML flat list of filings.  Flat list of filings, links to the filing on the SEC web site and to the filer taxonomy rendered as a flat HTML web page.
• Viewer format.  A table of contents which goes down the page, you can view either the SEC interactive data view or the filer taxonomy as a flat HTML page.
• Computer readable XML file (RDF format). Computer readable XML file which can be used to read the filings, the relations infosets which contains taxonomy information.

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.

Aberdeen Group published a study, Taking XBRL and Financial Disclosure Management to the Cloud, in which it states (emphasis is mine):

While external drivers such as the compliance mandate drove much of XBRL adoption in the early part of 2011(as cited by 55% of the respondents in the Enabling Compliance and Business Improvements through XBRL, report in April 2011), internal drivers such as executive orders to improve data quality (42%) and demand to improve staff productivity (30%) guided adoption of XBRL and other financial disclosure management tools in the latter part (Q3 and beyond) of 2011 (as per the August study, entitled Effective Disclosure Management: Ensuring Compliance and Improving Organizational Communication). XBRL adoption in 2012 continues to move along this trajectory with one key difference - companies are now looking beyond basic capabilities of financial reporting and towards expedited information delivery, leveraging fewer resources, and reducing operational costs.

Ask yourself the following question.  How are you going to verify that your disclosures are complete, correct, consistent, accurate, have fidelity, and have integrity? Is following the Edgar Filer Manual (EFM) sufficient? While there is some guidance in this area, that guidance leaves a lot to be desired.  Further, software is no where close to where it needs to be to help accountants who create this information, management who have to sign off on this information, and third party accountants who might need to verify this information.

You may be able to get away with submitting less than stellar information to the SEC, but do you really want that same quality standard used internally?