Digital Financial Reporting

Altova, maker of the popular XML Spy, announced a new product RaptorXMLwhich they say is a new generation of XML and XBRL processor.  You can see the datasheet for Altova RaptorXML here.

To be very clear, RaptorXML is a technical user tool and not something that an accountant will be using.  Perhaps some accountants will, but not many.

There are two things which I find very interesting about RaptorXML. The first is XBRL's billing right next to XML in this application.  XML and XBRL seem "side-by-side".  If RaptorXML does everything that Altova says that it will do such as support for XBRL Formula, XBRL Dimensions; then this will be quite a developer tool!  While this is not directly a great thing for accountants, indirectly it is a VERY good thing for accountants.  The functionality provided by RaptorXML should provide software developers with some very powerful and fast tools.

The second thing that I find interesting is lack of the mention of RDF.  Not sure that this really matters because one can simply take what RaptorXML provides you and then pass it to an RDF database or other RDF/OWL/SPARQL capable tool.

While RaptorXML knows nothing about financial report semantics, it does seem like it will provide necessary functionality at the technical syntax level.  Other processing layers can add what digital financial reporting or a term that I like even better, semantic financial reporting.

Smart data, smart applications will be part of your future sooner than you may think. The SEC's RoboCop will perhaps use RaptorXML.  Who know.  Maybe it already does.

Over the years I have mentioned the notion of the semantic spreadsheet. Probably the best example of a semantic spreadsheet can be seen in this software application. Watch the "Introduction" video, the first in the list.

At a point in the video they talk about "meaningful labels rater than arbitrary coordinates provided by rows and columns". That is the difference between today's electronic spreadsheets and tomorrow's semantic spreadsheets.  Rather than working with meaningless cell references such as "Row 25, Column D" you work with meaningful semantic information, "Sales for fiscal year end 2012".

Why is this such a significant difference?  Well, if you have ever tried to link spreadsheets together or tried to reuse information within one spreadsheet in another spreadsheet, you already understand.  Linking or reusing based on where something is presented is brittle.  If someone adds a new row or column to the spreadsheet you are linking to, your links break.

Semantic spreadsheets will work differently. There are three key points to understand.

First, because the coordinates of the information in a semantic spreadsheet are based on meaning rather then the presentation coordinates, linking is far less brittle.  The linking of information is driven by the information's semantics (meaning). The meaning does not change.  For example, "total Sales for fiscal year 2012 for the consolidated group" is always the same and the details of that total is likewise always the same.  You may have different aspects or breakdowns of that total, but the breakdown will always add up to the total.

Second, the semantics are enforced by business rules which could be included within the spreadsheet or  seperate from the semantic spreadsheet and therefore usable across many spreadsheets or all spreadsheets throughout an organization.  This both makes the bindings between spreadsheets stronger and improves information quality because one set of business rules common to any spreadsheet can be used to make sure the information is always correct.

The third difference relates to something which is a bit harder to explain, but I will give it a shot.  If you use spreadsheets you are probably familiar with pivot tables.  Excel pivot tables only work with numbers in the cells, the coordinates which contain information.  If you look closely to the Quantrix Modeler in the video above, you can see that it also only works with numbers within the cells.  But information contains both text AND numbers.  Pivot tables and the Quantrix Modeler are incorrectly focused on just numbers. I don't want to go into a long explanation here, you can get that information from this blog post.  I will just tell you that a lot of software is incorrectly focused on or optimized for numbers and OLAP and make it very difficult or impossible to incorporate both text and numbers into their models.  That will change.

The best example of a semantic spreadsheet that I have seen is the XBRL Cloud viewer.  Now, you still need to use your imagination because the tool only allows you to view information, not create information.  Here is an SEC financial report as viewed within the XBRL Cloud viewer. Also, there are a significant number of improvements which can be made in all sorts of areas; but if you look through all the distractions you can see the notion of a semantic spreadsheet and how it might work.

Fiddle with the XBRL Cloud viewer.  In particular see how the connections between pieces of the financial report work.  For example, click here to go to "Property, plant and equipment" for 2012 on the balance sheet:

When you go to the balance sheet using the link provided, click on one of the fact values for the line item "Property, plant and equipment".  A dialog box comes up "Fact Characteristics and Properties".  You are in the properties view, click on the "Occurrences" tab.  Notice that you see the disclosure "1074 - Disclosure - Components of Property and Equipment".  Click on that.  Notice that it takes you directly to that disclosure.

Those two places in the financial statement are linked together semantically by the fact total property, plant and equipment, the legal entity "consolidated group", the reporting entity represented by the Microsoft SEC CIK number, and the period which you clicked on.  That link is automatic, the XBRL technical syntax takes care of all the details and the software implemented those technical rules.

Way back in 2004 I created some prototypes of semantic spreadsheets.  Here is a screen shot. (Click on the graphic for a larger view)

This is basically an audit schedule for information related to long-term debt.  The yellow notes point to different pieces of a financial statement where a fact would be shown.  I created some macros which basically took the information in the spreadsheet, generated the XBRL which represents this audit schedule using the XBRL GL (XBRL Global Ledger) format, and other stuff necessary to connect this audit schedule and numerous other audit schedules for accounts receivable and accounts payable to a financial report.

I did this back in 2004 to better understand how all this worked so that I could bring this information into the project to create the US GAAP Taxonomy.

Imagine a set of semantic spreadsheets all interconnected which represent a financial report and all the audit schedules and other detailed schedules which represent the information which supports the financial statement.  Imagine accounting systems and other systems generating these detailed spreadsheets, trial balances, agings, sub ledgers, etc.

Would that be useful to accountants?  I would certainly think so, that is exactly why XBRL was created. Basically you get everything that you get from spreadsheets today but more effectiveness and effeciency.  Who would not want that?

Why don't we have this sort of stuff today? Read the book The Innovators Dilemma.  That explains everything.  Most software vendors are going after what SEC filers and others mandated to use XBRL are asking for.  They are focused on meeting required mandates.  Few understand both the technology piece and the domain.  Some software vendors do get this.  You will see semantic spreadsheets which work correctly.  In fact, I believe that the semantic spreadsheet will be the killer app which enables digital financial reporting to take off.

What do you think?  If you understand what I am trying to say above, talk to software vendors about this.  The more accountants who ask for this sort of thing, the sooner some software vendor will deliver products which support this type of functionality.

Maybe semantic spreadsheets can help fix this problem of errors in Excel spreadsheets.

Panko's meta-analysis of several such studies, he claims, indicates that 84 percent of spreadsheets contain some kind of materially significant error.

Admittedly, my blog tends to be organized by stream of consciousness.  It does contain the most current information, but it can be challenging to sort through everything and build a logical summary.  Periodically, I do go through what I have, refactor it, and put things into an easier to use form.

Today, the best summaries of information that I have are:

• XBRL for Dummies.  This is a good starting point, provides the big picture into which most everything else fits.
• Digital Financial Reporting.  Synthesize most key information into one volume.  However, being a book (or PDF) which therefore being static (was made available in September 2012), it can get rather stale.
• Understanding quality.  Digital financial reporting needs to work. If accountants cannot create digital financial reports, then why would they want to make use of digital financial reporting? Software is improving.  This is the bar.  This is what accountants should expect from software, to allow them to prove to themselves that they have created a quality digital financial report.
• Smart Data/Applications. This blog post which has links to three other important resources shows why I am adopting the term "guidance-based, model-driven, semantic-oriented structured authoring" to describe what I believe digital financial reporting will look like.
• Financial Report Ontology. This wiki has the most current definitions, examples, and is the current focus of the work I am doing to help figure out how to make digital financial reporting work within software.
• Reporting templates.  This set of reporting templates are the best examples of using XBRL correctly that I have.
• Reference implementation. This is a reference implementation of an SEC XBRL financial filing which I maintain. Most comprehensive example that I have.
• DOW, Fortune 100, S&P 500 Data.  This is the end game, it should be easy and reliable to pull information from digital financial reports.
• Enhanced Domain Level Semantics.  This blog post is one of the most important updates to the information I have accumulated, an enhanced set of domain level semantics for US GAAP.
• XBRL Cloud Viewer.  This software is the best tool I have come across for understanding an SEC XBRL financial report. View any SEC XBRL financial filing here using the XBRL Cloud viewer. Here is more information helpful in using this free software tool.

I am waiting on some improved software which can be used to successfully create a quality digital financial report and help the creator of that report see that they did everything right.  It may take some time to get to this point.  When we do, I will update the Digital Financial Reporting book.

To understand digital financial reporting, one needs to understand these three definitions.  Everything builds on these three definitions: (The links are to the most current version of the definition)

• Fact: A fact is reported. A fact defines a single, observable, reportable piece of information contained within a financial report, or fact value, contextualized for unambiguous interpretation or analysis by one or more distinguishing characteristics (properties of the fact). A fact value is one property of a fact. Every fact has exactly one fact value.
• Characteristic: A characteristic describes a fact (a characteristic is a property of a fact). A characteristic or distinguishing aspect provides information necessary to describe a fact or distinguish one fact from another fact. A fact may have one or many distinguishing characteristics.
• Property: A property is a trait, quality, feature, attribute, or peculiarity which is used to define its possessor and is therefore dependent on the possessor (entity or thing which has the property). A property belongs to something. For example, the color of a ball belongs to and is therefore is dependent on (is a property of) the ball.

Hard to believe, but that is as complex as it gets.  No ugly XBRL terminology.  Software will hide the XBRL technical syntax.  To drill into this, use the set of videos on the bottom of this page.

The utility of a high-level computer-readable fundamental accounting model is becoming more clear to me. In a prior post I discussed the notion of fundamental accounting relations. In another post I showed a screen shot of an application I am using to figure out these relations. This post builds on that other information and tunes the information for what I am actually finding in SEC financial filings.

This post also points out that this model can be used to be clear of the accounting choices made by reporting entities.

You can see my updated visual model by clicking on the image below:

I have summarized the relations on this wiki page. Definitions which would add additional clarity are forthcoming.

The model is based on my understanding of financial reporting, the US GAAP Taxonomy, and 7,160 SEC XBRL financial filings (10-Ks) that I am looking at.  What I am noticing is this:

• Detecting accounting choices: The balance sheet and cash flow statement models are extremely straight forward and there is very little inconsistency. For example, there are 1,377 SEC filers who report a noncontrolling interest.  Of that total, 1,262 (92%) include noncontrolling interest within equity and provide a subtotal for "Equity attributable to parent".  Approximately 50 filers either (a) don't include noncontrolling interest in equity or (b) they don't include the total "Equity" on their financial statement.  There are less than 10 SEC filers which clearly do NOT include the noncontrolling interest within equity, for example like this filer reports it as part of liabilities. Now, my accounting skills do not allow me to make any statement about whether this is someone making a mistake or if there is a reason for this, or otherwise determine the appropriateness of this (I don't have enough experience with accounting for noncontrolling interests).  However, I can tell you this.  If I were an accountant and I had to create a financial statement and I had to report a noncontrolling interest; this would be VERY good information to help me understand where to put the noncontrolling interest on my balance sheet. As long as all the facts are the same, doing what 92% of other financial statements do is WAY safer than doing what only 10 or 1% choose. While figuring out how to report a noncontrolling interest is not that hard really, these same techniques can be applied to EVERY part of a financial statement.  That is useful to accountants and auditors.
• Operating income (loss), Nonoperating income (loss), Interest and debt expense:  There is only one part of this representation which has real variability: the three pieces of "Income (loss) from continuing operations before taxes". You can see this section of a financial statement herein the US GAAP Taxonomy. The "line" between "Operating income (loss)" is vastly clearer than the line between "Nonoperating income (loss)" and "Interest and debt expense".  In fact, financial statements tend to "co-mingle" what goes into those two categories. Also, subtotals are many times not provided for these categories.  OK fine, to deal with this in my representation I simply created a subtotal "Nonoperating income (loss) + Interest and debt expense".  Problem solved. Again, it is certainly not wrong to organize your income statement line items in this area using the three categories provided by the US GAAP Taxonomy.  However, the variability which I see in SEC financial reports leads me to believe that you are not required to differentiate these two areas (nonoperating income (loss) and interest and debt expense.  Clearly there is a bright line as to what is contained within operating income (loss) and what is not.
• Crossing boundaries of broad categories is generally never allowed:  Putting detail which is clearly identifiable as an "asset" as defined by the FASB conceptual framework(or IASB framework for that matter) into the "equity" section of a balance sheet is clearly not OK. On the other hand, there is less clarity say as to what should be classified as net cash flows from financing activities and what might be classified as net cash flows from investing activities. Understanding what goes into which of these broad categories and when crossing the boundaries of these categories might be OK due to ambiguity in the accounting rules is helpful information.  Looking at the 7,160 SEC XBRL financial filings is a wealth of information in this regard, very helpful to accountants.

Now notice that none of the issues above have anything to do with XBRL really.  These are accounting issues.  Using all that XBRL-based information turns the SEC XBRL financial filings into a treasure trove of useful information.

Now, are these high-level categories also useful for working with the XBRL-based information.  Yes, very much so.  For example, in terms of concept selection having these categories and knowing which concept relates to which category is very useful in avoiding concept selection mistakes.  For example, let me point out two clear mistakes. (Not to pick on these filers, they are just two very good examples.)

Procter & Gamble, in their 10-K filing, created a balance sheetand on that balance sheet they did not include a total for noncurrent assets. No big deal, having a total for noncurrent assets is not required on the balance sheet.  However, notice the line item "OTHER NONCURRENT LIABILITIES" within the balance sheet.  Using the XBRL Cloud viewer, if you click on the report element or fact a dialog box appears and you can see from that dialog box (go to the "Occurrences" tab) that the line item is detailed in another section of the report, "2403402 - Disclosure - SUPPLEMENTAL FINANCIAL INFORMATION (DETAILS)". Go to that section and you see a listing of the pieces which make up that total.  In that list of details you see the line item "Other Non-Current Liabilities" which has the US GAAP taxonomy concept "us-gaap:LiabilitiesNoncurrent".  Oops!  That is clearly a mistake in concept selection.  You can see for yourself that in the US GAAP Taxonomy, this means something different than how P&G is using it.

3M, in their 10-K filing, created an income statement and in that income statement they provided the line item "Total interest expense - net".  The US GAAP Taxonomy concept used to express that line item is "Nonoperating income (expense)". Now, I guess that is not so bad, but perhaps "Interest and debt expense" could be another choice. HOWEVER, look closely what is going on.  See the 3M line item "Interest expense".  That concept is the US GAAP Taxonomy concept "Interest and debt expense". What 3M did was use one high-level total concept, repurposed it, and included that high-level concept into the category "Nonoperating income (expense)".  That is a bad, bad thing in my book.  Under no circumstances should a high-level concept be used as a line item within some other high-level concept.  Further, it is a very bad idea to take a concept from one category and use that concept within another category.

As a side note, I know how this sort of error occurs.  What happens is accountants creating SEC filings are presented with a flat list of concepts in software applications when they are trying to find the correct concept to use.  The accountants fail to examine the concept relative to other concepts before they make their selection of concepts.  It is always best to take a look at a concept within its context to other concepts in the US GAAP Taxonomy prior to making your final choice.

There is one final thing worth mentioning about this set of fundamental accounting relations.  Take the term "Assets".  Pretty straight forward, I bet you know what that concept means.  And in the US GAAP Taxonomy, there is exactly one concept which could ever be used to express that fundamental accounting concept, "us-gaap:Assets". And that is the way it should be: one fundamental concept, one  representation of that fundamental concept within the US GAAP Taxonomy.  This is supported by the fact that all 7,160 SEC XBRL financial filings either DID use the concept "us-gaap:Assets" or SHOULD have used that concept (i.e. they had a modeling error, see here for detailed information).

Liabilities also works this way.  As does current assets, current liabilities, noncurrent assets, noncurrent liabilities, commitments and contingencies, and numerous other concepts which fit into this pattern.

However, this is not alwayshow the US GAAP Taxonomy works.  Look at the concept "Liabilities and equity".  You used to have "Liabilities and Stockholders' Equity" and "Liabilities and Partner Capital".  That is 2 US GAAP concepts which represents only one fundamental accounting concept.

Now, evidence of this idea (multiple US GAAP concepts represent one fundamental accounting concept) is the fact that the 2013 US GAAP Taxonomy fixed that problem! If you go to the US GAAP Taxonomy (2013 version) you see that the concept "Liabilities and Stockholders' Equity" was changed to "Liabilities and Equity" and the concept "Liabilities and Partner's Capital" was deprecated and can no longer be used.

Other areas of the US GAAP Taxonomy have not been corrected.  For example, there are multiple "Equity" concepts (stockholder, partner, LLC).  There are other areas where this occurs.

And so now think about querying SEC XBRL financial information and you want to find the concept "Equity" and you don't care whether the entity type is corporation, partnership, LLC, membership organization, proprietorship, or that ever.  You can see how such a query can be complicated by multiple different US GAAP Taxonomy representations of the same fundamental accounting relations can cause issues.

This points to another example of why the fundamental accounting concepts and the relations between those concepts can be useful.  They can make querying the information easier.

Do you see other ways this fundamental accounting concepts/relations layer can be useful?  If you do, please let me know.

Verification that a financial report is "valid" is not a mystery.  Accountants have been doing this for years.  However something very significant has changed.  In the past, this verification process was a 100% manual process.  Green eye shades, 10 key calculators, and deep accounting knowledge required by all who undertook this process.  And because the process was so manual and because humans make mistakes, no matter how hard one tried things always slip through the cracks.

But now because financial reports can be read by a computer software application because of the structured nature of the financial report, such as a digital financial report expressed using XBRL, many things change. Many parts of the verification process can be automated such as checking mathematical computations and "if...then" type checks, "IF you have this financial statement line item, THEN you must provide this policy and this disclosure."

Another thing has changed.  All those financial reports which were here-to-for verified using only human processes can now have automated processes applied to them very effeciently and effectively.  All sorts of automated processes such as what is being called the SEC "RoboCop" or accounting quality model. Likely many interesting things will be discovered which have been missed before by humans.

While there are many interesting and sophisticated processes which will likely be thrown against financial reports in the coming years because they have become digital, below are the basics of creating a quality digital financial report such as an SEC XBRL financial filing.

Thinking through the process of verification

Let us start with fundamentals. Verification is the process of research, examination, and other tasks and steps required to prove or establish validity; evidence that establishes or confirms the accuracy or truth of something. Verification is a formal assertion of validity.

Validity can be defined as being well grounded; producing the desired result; free from logical flaw; based on sound reasoning; cogent; faithful.

Validity when it comes to a financial report is, arguably, that such a financial report is a true and fair or a faithful representation of a reporting entities financial and nonfinancial information articulated by such a financial report. Looking at this backwards - an untrue or an unfair report - is certainly not desirable. (Don't confuse true and fair as used here with the term "presented fairly" as used by auditors, we are discussing something different here.)

A financial report can be said to be valid if it possesses certain traits which can be defined in general terms and for clarity are listed below to bring them into the reader's mind. (These terms are highlighted in the AICPA Statement of Position 09-1 Performing Agreed-Upon Procedures Engagements That Address the Completeness, Accuracy, or Consistency of XBRL-Tagged Data, http://bit.ly/XIoqxv ):

• 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.

Assurance on XBRL instance document: A conceptual framework of assertions (see http://bit.ly/VjHwdG) points out the need for a framework for verifying the appropriateness of a digital financial report.
While these four notions which relate to the "trueness" and "fairness" must exist for every fact reported by a financial report, they also need to exist when considering the financial report in its entirety and the relations between reported facts. Further, it would seem to be appropriate to add the term "sensible" and perhaps even "logical" to this list. Clearly digital financial reports should be both sensible and logical.

Two other notions help bring the notion of trueness and fairness of information at the fact and at the report level into focus, looking at the financial report holistically:

• Fidelity: Fidelity relates to the loyal adherence to fact or detail; exactness, faithfulness. The representation of the facts, events, transactions, and other circumstances represented within a financial report properly reflect, without distortion, reality. High fidelity is when the reproduction (the financial report) with little distortion, provides a result very similar to the original (the reality of the reporting entity and environment in which the reporting entity operates).
• Integrity: Integrity is holistic fidelity. Integrity relates to the fidelity of the report in its entirety, of all parts of a financial report, from all points of view. Integrity is holistic accuracy, accurate as a whole. Integrity is the quality or condition of being whole or undivided; completeness, entireness, unbroken state, uncorrupt. Integrity means that not only is each component of a financial report correct but all the pieces of the financial report fit together correctly, all things considered. The reported facts are logical and sensible as well as the relations between reported facts are logical and sensible.

To an accountant the notions of verification and validity and that a financial report must be complete, correct, consistent, and accurate as defined above are a statement of the obvious. Perhaps accountants have never really thought about the verification process in these terms, but accountants get this.  Accountants have performed these tasks for hundreds of years. This is not new to accountants. Further, these traits which a financial report must possess are the obligations of those creating these reports; they are not options. Accountants don't pick and choose whether a financial report is to be true and fair; those traits must be true by definition.

What is new is that now accountants must rely on software to help them fulfill this obligation.

True and fair representation in more specific terms

Looking at the verification process in more specific terms, arguably the following would hold to be true of a financial report which represents the financial information of a reporting entity:

• Comply with financial reporting standards: Clearly a financial report must comply with the rules (i.e., IFRS, US GAAP including applicable SEC rules, industry/activity practices, other common practices), and reporting entity choices where they have options.
• Full inclusion/false inclusion: Everything which should be disclosed has been disclosed as deemed appropriate by such rules and the reporting entity choices.
• Foots, cross casts, ticks and ties: A financial report foots, cross casts, and otherwise "ticks and ties". All mathematical relations must be intact. All nonnumeric relations must be sensible and logical.
• All financial report formats convey the same message: A financial report can be articulated using paper and pencil, PDF, HTML, XBRL, or some other computer readable formats. While the format may change, the message communicated, the story told, should not change. Each format should communicate the same message, regardless of the medium used to convey that message.
• Justifiable/defensible report characteristics: Facts reported and the characteristics which describe those reported facts should be both justifiable and defensible by the reporting entity.
• Consistency between periods: Financial information expressed within one reporting period should be consistent with the financial information expressed within subsequent reporting periods, where appropriate. Changes between report elements which existed in both periods should be justifiable and defensible as opposed to arbitrary and random.
• Consistency with peer group: If a reporting entity chooses one approach/report element and a peer chooses a different approach/report element; clearly some good, explainable reason should exist for such difference.
• Useful, sensible, logical renderings: Renderings of facts, characteristics which describe the facts, parenthetical explanations which further describe such facts, and other representations should make sense, be logical, and ultimately be useful in understanding the information. While there may be differences of opinion as to how to format or present such information; there is significantly less or no dispute about the logic. Disclosures are informational, they relate to information without regard to formatting or other presentational artifacts. The term "notes" or "disclosure notes" or "footnotes" relate to organizing disclosures and are presentational in nature. Someone creating a financial report has far more latitude and discretion as to how to organize disclosures into disclosure notes than they do as to what must be disclosed.
• Unambiguous business meaning: A financial report should be unambiguous to an informed reader. The business meaning of a financial report should be clear/unambiguous to the creator of the financial report and likewise clear/unambiguous to the users of that financial report. Both the creator and users should walk away with the same message or story, an identical understanding of the reported facts. Users may interpret the facts in different ways, but the facts should be the same for all parties.

Verification will always include both automated and manual processes.  Automating processes can improve quality and reduce costs.  But, not all processes can be automated.  The judgement of an accountant cannot be automated.

What are your ideas about what a quality financial report looks like?  If you have improvements to these ideas or of you have better ideas I would like to understand those ideas and why you believe they are better.