Digital Financial Reporting

"Knowledge as a service" is the vision of Epistematica.  Great vision. 

This company is also the first use of the term "semantic financial reporting" that I have heard. Semantic financial reporting is far better than the term I use which is "digital financial reporting".

I believe we are both talking about the same thing: guidance-based, model-oriented, semantic structured authoring of financial reports. 

The reports are not created using tools which know nothing of financial reports or financial reporting such as Microsoft Word or Microsoft Excel.  Semantic financial reports are created using "smart applications" which do understand financial reporting.  That may seem odd, but that is precisely what the semantic web is all about.

Software understanding the semantics of some domain is not voodoo or magic. It is all about metadata. Ontologies, like the financial report ontology, which express key "things" and important relations between those things which make up a financial report literally guide a user of that software to achieving some desired goal such as creating a financial report.

Ontologies express knowledge in the form of metadata which a software application can understand and use.  To see this you need both the software that understands the metadata and the metadata itself.

I predict that we will see the metadata and software which can understand and use this metadata for financial reporting within a year. Disclosure management software is a big step in this direction. Then accountants will get what XBRL is really all about.

Knowledge is part of a spectrum or hierarchy: (I synthesized these definitions from many other definitions)

• Data is the most basic level; discrete facts or observations, but unorganized and unprocessed and therefore has no real meaning or value because it has no context; for example, "10,000" is data.
• Information adds context; information is data in context, it has meaning; for example, "Sales for ABC Company for 2012 is $10,000 is information.
• Knowledge adds how to use it; knowledge is a framework for evaluating and interpreting information which makes use of experience, values, expert insight, intuition with the goal of evaluating and incorporating new experiences and information; for example, the sales for every public company organized in useful ways is knowledge.
• Wisdom adds when to use knowledge; wisdom relates to knowing why and doing something useful; wisdom = knowledge + experience; for example, exercising judgment to sell your shares of some stock because the sales relative to the sales of other public companies and relative to other numbers on a financial statement is wisdom.

The end game is now knowledge, it is wisdom.  Data, information, and knowledge are building blocks.  But it takes experience to to know what to do with that knowledge to have wisdom.

That is what I think.  What do you think?

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.