Analysis of SEC XBRL Financial Filings (FY Ks)

Transcription

1 Analysis of SEC XBRL Financial Filings (FY Ks) Analysis of SEC XBRL financial filings for the purpose of better understanding how to make use of XBRL for financial reporting By Charles Hoffman, CPA DRAFT of This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 1

2 About the authors: Charles Hoffman, CPA, is credited as being the Father of XBRL. He started his public accounting career as an auditor with Price Waterhouse, served various roles in industry and public accounting for over 25 years, and has worked with XBRL since its introduction by the AICPA in In 2006, he received the AICPA Special Recognition Award for his pioneering role in developing XBRL. He has authored numerous publications including XBRL for Dummies, a number of Journal of Accountancy articles, writes a blog relating to XBRL, and contributed to a number of XBRL related technical specification and best practices documents. Currently, Charlie works as a consultant helping accounting professionals leverage XBRL for everyday tasks and software vendors build useful software. Charlie was co-editor of the first US GAAP taxonomy, creator of the first usable XBRL taxonomy creation utility application, contributor to the XBRL 2.1 specification and the XBRL Dimensions specification, editor of the Financial Reporting Taxonomy Architecture and Financial Reporting Instance Standards, co-author of the US GAAP Taxonomy Architecture, part of the project team which created the US GAAP Taxonomy, and a major contributor to the IFRS XBRL taxonomy, and a number of other XBRL taxonomies. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 2

3 Table of Contents Overview SEC XBRL financial filings analyzed Duplicating this analysis Summary of analysis Overview of analysis results Statistics of Analysis General information Usage of [Table]s Usage of [Axis] Summary of Analysis Step 1 - Get reporting entities Step 2 - Get financial report(s) for reporting entity Step 3 Verify financial report Step 4 Discovery of root reporting entity Step 5 Verify fundamental accounting concepts and relations Step 6 Extracting reported facts Step 7 Understanding characteristics expressed Step 8 Understanding report components Conclusions Reached Structure Formalism Information quality Comparability Qualitative versus quantitative disclosures Endless permutations and combinations are unnecessary Wrong debate Correct debate Formal, rigorous, comprehensive, violent testing Recommendations Explicitly define the categories of report elements used to represent financial report semantics within an XBRL taxonomy and communicate this information to software vendors This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 3

4 5.2. Explicitly define the relations, including cardinality, between defined report element categories and communicate this information to software vendors Explicitly describe and follow the member arrangement patterns which clearly exist within an XBRL taxonomy Explicitly describe and follow the accounting concept arrangement patterns which clearly exist within an XBRL taxonomy Define clear semantics for identifying report components Explicitly define a set of fundamental accounting concepts Explicitly define unchangeable relations between the set of fundamental concepts Differentiate the notion of unchangeable mathematical relations and mathematical relations financial report creators can change Explicitly and formally map each taxonomy concept to a fundamental concept (i.e. define class-subclass relations) APPENDIX: Terminology Report level representation Financial reporting domain representation Mapping between semantics and implementation APPENDIX: Explicit [Table] Usage APPENDIX: Details of Analysis This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 4

5 Overview The purpose of this document is to summarize the analysis of a set of 7,160 Form 10-K SEC XBRL financial filings. The following were the primary drivers for the analysis: 1. Understand how to build better XBRL taxonomies 2. Understand the dynamics of concept extension by SEC public company filers 3. Understand how to create quality SEC XBRL financial filings 4. Understand the dynamics of comparability of SEC XBRL financial filings In this document, statistics from the SEC XBRL financial filings are provided and the analysis is summarized. Pointers are provided to obtain additional details so that if one wishes to drill into additional detail then one can. A summary of conclusions reached and specific recommendations for those creating systems which make use of XBRL (XBRL taxonomies, XBRL instances) within that system. These recommendations could be beneficial to the US GAAP XBRL Taxonomy and SEC XBRL financial filings; but they are likewise beneficial to others contemplating using XBRL taxonomies and XBRL instances within their systems SEC XBRL financial filings analyzed The scope of this analysis was only 10-K filings for the fiscal year 2012 per the SEC RSS feed (see Only the most current submission was used so, for example, if a 10-K was filed and then subsequently the filing was amended by a 10-K/A; the initial but outdated report was not used. And so, the goal was to have the most current 10-K filing for all reporting entities for the fiscal year ended in 2012 filed between March 1, 2012 and February 28, The initial set of financial filings derived contained 7,199 SEC XBRL financial filings of public companies. However, there were issues of duplicate CIK codes due to the way reporting entities report. All duplicate CIK codes were removed which reduced the set of filings analyzed to 7,160. This URL provides an Excel spreadsheet which contains a listing of all reporting entities whose 2012 fiscal year 10-K submission was included in this analysis: Duplicating this analysis Some of this analysis is undertaken using commercial software products for which one needs a license to use the software. This software cannot be made available. However, most of this analysis was undertaken without the use of commercial software and does not even make use of an XBRL processor. The following is step-by-step instructions for how to extract information from SEC XBRL financial filings: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 5

6 1.3. Summary of analysis The ultimate goal of the analysis was to evaluate whether it was possible to automate the meaningful reuse of information from SEC XBRL financial filings. To achieve automated reuse the information provided must be a true and fair representation of the financial information of a reporting entity. There should be no contradictions. There should be no unexplained inconsistencies within the information. The information should be sensible and logical as opposed to nonsensical, illogical, inconsistent, contradictory, or absurd. The analysis is less about the technical nature of the information and more about the business meaning reflected by the SEC XBRL financial filings. Not every aspect of every financial filing was tested. Rather, fundamental and key aspects one would generally expect from such digital financial information were investigated. It is not necessarily appropriate to project the results found by this analysis to the overall digital financial report. However, the insights observed in the areas of this analysis can be helpful in investigating other areas of a digital financial report Overview of analysis results The following is a high-level overview of the results of this analysis. Of all 7,160 SEC XBRL financial filings in this analysis, as a percentage of all filings: # Test Pass Fail Comments 1 XBRL technical syntax is proven to be correct 99.9%.1% High success rate likely caused by XBRL 2.1 conformance suite. 2 Automated SEC EDGAR Filer Manual (EFM) rules 86.1% 13.9% This is per XBRL Cloud s EDGAR Dashboard. The rather high failure rate is caused by lack of a conformance suite or any way to resolve discrepancies between the different interpretations the SEC and different software vendors have for the EFM rules. However, this could be and should be 100% automated and 100% correct given proper representation rules. 3 US GAAP Taxonomy Model Structure 97.9% 2.1% High success rate likely do to reasonably good examples provided by US GAAP Taxonomy, the US GAAP Taxonomy Architecture, and a number of software vendors who have automated such tests. However, this could be and should be 100% automated and 100% correct given proper representation rules. 4 US GAAP Domain Level Rules 95.8% 4.2% High success rate likely do to a good understanding of core financial information by accountants. However, this could be and should be 100% automated and 100% correct given proper representation rules. 5 Roll up rules for balance sheet, income statement, cash flow statement 79.1% 20.9% Reasonably high success rate likely do to most accountants understanding that assets, liabilities and equity, net income, and net cash flow each foot. However, this could be and should be 100% automated and 100% correct given proper representation rules. (Note that the percentages are the lowest of the three categories) 6 Root of reporting entity discovered 99.2%.8% One of approximately 7 different things contributed to the specific inability to discover the root entity of 58 filers. However, this could be and should be 100% automated and 100% correct given proper representation rules. 7 Detect and use 51 fundamental accounting concepts and those concepts adhere to 21 unchangeable relationships. 98.0% 2.0% Builds on #4 above. However, for this test if a fact for a fundamental accounting concept is not provided by the filer, an attempt is made to impute the value. This explains the higher passing rate. It is highly probable that detection of all fundamental concepts could be automatable without changing US GAAP. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 6

7 2. Statistics of Analysis The following is information about the SEC XBRL financial filings analyzed: 2.1. General information The following is general information about the SEC XBRL financial filings analyzed. Description Value Comments Total number of filings 7,160 All were 10-Ks which related to 2012 filed between March 1, 2012 and February 28, 2013 Total number of networks 322,091 Total number of reported 5,932,830 facts Total number of facts with 988,264 17% of total reported facts extension concepts Total number of explicit [Tables] defined 156,494 Average number of Networks per report Average number of explicit [Table]s per Network Average number of facts per report Average number of facts with extension concepts Average reported facts per network , 091 networks divided by 7,160 filings ,494 explicit [Table]s divided by 322,091 Networks 827 5,932,830 reported facts divided by 7,160 filings ,264 facts with extension concepts divided by 7,160 filings 18.4 (5,932,830 reported facts divided by 322,091 networks) 2.2. Usage of [Table]s The following is a summary of the number of explicit [Table]s which were contained within a Network. For example, 165,524 networks contained 0 or no explicitly defined [Table]s. There were 155,672 which contained only one. Therefore 99% of all networks contained 1 or 0 tables (explicitly defined or an implied table). A total of 895 networks had 2 or more [Table]s. Number of explicit [Table]s Networks Comments 0 165,524 51% of total 1 155,672 48% of total Total 322, % A total number of 156,494 explicit [Table]s were used by reporting entities. Of that total number of explicit [Table]s used, the [Table] us-gaap:statementtable was used 75,785 times representing 49% of the total. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 7

8 2.3. Usage of [Axis] The following is a summary of the number of [Axis] defined by reporting entities and put on [Table]s. Note that the total characteristics count is the number of [Axis] defined plus the entity/identifier and period which always exist as they are required. Of all explicit [Table]s, 98% had 4 or less explicitly defined [Axis] plus 2 other required characteristics (i.e. entity/identifier and period). So 2% had 5 or more [Axis]. The maximum number of [Axis] defined on a [Table] was 24. Other characteristics Number of [Axis] defined on [Table] Tables Comments 2 0 6, , , , , , Total 156,494 Total number of explicit [Table]s [CSH: Perhaps add list of the most commonly used axes.] This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 8

9 3. Summary of Analysis The following is a summary of the analysis process and the results of the analysis. Links are provided to detailed information where that detailed information is available Step 1 - Get reporting entities First off, in order to use a financial report you must find the financial report. To do this, the SEC provides an RSS feed. This is the RSS feed: While additional metadata would be helpful in the RSS feed, such as the SIC code or industry classification, the SEC RSS feed is sufficient to get a list of financial reports Step 2 - Get financial report(s) for reporting entity The RSS feed is read, a list of financial report(s) or submissions is gathered. That list is put into a relational database. In the case of this analysis, a specific set of financial reports were analyzed. The scope was only 10-K filings for the fiscal year Only the most current submission was used so, for example, if a 10-K was filed and then subsequently the filing was amended by a 10-K/A; the initial but outdated report was not used. And so, the goal was to have the most current 10-K filing for all reporting entities for the fiscal year ended in 2012 filed between March 1, 2012 and February 28, The initial set of financial filings derived contained 7,199 SEC XBRL financial filings of public companies Step 3 Verify financial report The following is a breakdown of verification tests performed against the initial set of 7,199 SEC XBRL financial filings. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 9

10 XBRL Technical Syntax To summarize, XBRL technical syntax interoperability is very, very good with 99.9% of all SEC XBRL financial filings passing this test. Edgar Filer Manual (EFM) automated rules Per the XBRL Cloud EDGAR Dashboard, only 80.5% of SEC filers actually pass EFM validation rules. An obvious question would be, How is it even possible for only 80.5% of SEC filers to pass SEC EFM automated verification rules? One would think that 100% of filers would pass this rule set. The reason for the difference between the 100% and 80.5% is that XBRL Cloud, and other software vendors, have different interpretations of the SEC EFM rules. This discrepancy could easily be reduced or eliminated with the proper use, maintenance of, and communication to software vendors using a formal conformance suite. Proof of this is the fact that XBRL technical syntax rules are passed by 99.9% of all SEC filings and the XBRL Technical Specification has a robust conformance suite which has been maintained since US GAAP Taxonomy Architecture Model Structure rules US GAAP Taxonomy Architecture Model Structure Rules test the relationship between the report elements of Networks, [Table]s, [Axis], [Member]s, [Line Items], Concepts and [Abstract]s which is articulated in section 4.5 of the US GAAP Taxonomy Architecture. For example, an [Axis] may only have [Member]s as described by the existence of the type attribute of "nonnum:domainitemtype" on the report element. Or, an [Axis] makes no sense existing within a set of [Line Items]. Also, inconsistencies between the presentation, calculation, and definition relations are highlighted with this verification step. US GAAP Domain level rules A core, fundamental set of concepts always exists in financial reports. For example, financial reports have balance sheets. Balance sheets contain Assets and Liabilities and Equity. Balance sheets balance, i.e. Assets = Liabilities and equity. The US GAAP Domain level rules test for the existence of 6 such fundamental facts and relations between facts. This XBRL Formula file provides information as to these tests: GAAP-V xml There are two things which prove this core set of financial report semantics. First, 95.8% of all SEC XBRL financial filings within this test set pass these rules. Second, when one goes to observe why the 4.2% do not, you can clearly see the error in the filing. For example, assets was not found for one filer. When the financial report was examined it was found to use the extension concept adgi:assetsonliquidationbasis created by the filer. This is a rather obvious error. Another example, a filer created the concept westas:liabilitiesandmembersdeficiency to express liabilities and equity. Conceivably, some of the errors made by filers could be missing concepts from the US GAAP Taxonomy. It would be very hard to justify extension concepts at this very high level. Balance sheet, income statement, cash flow statement roll up rules This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 10

11 As pointed out above, balance sheets balance. It is also true that assets roll up. Liabilities and equity roll up. Net income (loss) on the income statement rolls up. As does net cash flow on the cash flow statement. Proof of these roll ups is that almost 80% plus of all SEC public companies provide such roll up rules in the form of XBRL calculations. Some do not provide these roll up rules for some reason Step 4 Discovery of root reporting entity (Note that the number of reporting entities analyzed was dropped from 7,199 to 7,160 to remove duplicate reports. The difference relates to 39 reporting entities which are sub-entities of some other entity and CIK numbers were duplicated. These 39 filings were simply removed from the analysis.) Once the reporting entities are identified as it Step 1, the financial reports are located as in Step 2, and the financial reports are verified to be reasonably correct in terms of the XBRL technical syntax, EFM rules, and other basic financial reporting semantics; the first thing one needs to be able to discover is the basic information reported by the reporting entity. Generally it is rather easy to locate the root reporting entity, for example for the set of 7,160 reporting entities analyzed, 99.2% had the root entity which was easy to discover. In fact, there were only 58 reporting entities which were NOT discovered. The reason for the inability to discover the root entity for these 58 reporting entities is identifiable and can be broken down into the 7 groups above. To understand this issue, consider the following filing where the root entity could NOT be identified. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 11

12 If you notice the [Member] of the Legal Entity [Axis] above you see that the legal entity was identified to be Consolidated Legg Mason Group. Upon further investigation of the model structure, you see the representation of that [Member] as a sub-part of the Entity [Domain] or the consolidated entity. The vast majority of SEC filers report the legal entity as being the consolidated entity. If the filer had represented the Consolidated Legg Mason Group [Member] as the first [Member] of the Legal Entity [Axis] (i.e. replacing Entity [Domain]) the root entity would have been properly discovered. However, the filer represented the reality of what was reported incorrectly. Note that the Entity [Domain] does not show up in the balance sheet. One additional example will help understand why representing the information correctly will result in the proper discovery of the root reporting entity. The report below (see This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 12

13 The reason the root reporting entity was not found is because the filer used the Scenario Unspecified [Domain] report element in their representation of the reported information. And the filer simply used the Successor [Member] as the root [Member] for the axis Statement, Scenario [Axis] then the root reporting entity would have been properly discovered by analysis software. Basically, in every case where the root reporting entity was not discovered, the reason why it was not discovered can be determined and therefore could have been corrected. This document contains additional details related to the inability to discover the root reporting entity: Step 5 Verify fundamental accounting concepts and relations Building on the US GAAP Domain level rules, an analysis of fundamental accounting concepts and relations between those fundamental concepts was undertaken. For example, Assets is anticipated to exist in a financial report. If the public company is a commercial industrial company, then current assets is likewise expected to exist. If assets is reported and current assets is reported, one can impute the value of noncurrent assets as being noncurrent assets = assets current assets. The 7,160 financial filings prove the existence of 51 fundamental accounting concepts and 21 relations between those concepts. A summary of these concepts and relations can be found here: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 13

14 This is a screen show of an Excel application which allows you to extract this fundamental accounting information from SEC XBRL financial filings: You can download and run this working prototype Excel application here: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 14

15 Of these 7,160 SEC XBRL financial filings, 98% of the filings were found to follow the hypothesis that these 51 concepts and 21 relations existed. There was only one area of the primary financial statements which had less than 90% adherence to this hypothesis. That area was the pieces which made up Income (loss) from continuing operations before tax. Specific reasons for not being able to discover these fundamental accounting concepts can be grouped into the following categories: Significant variability in the concept used by SEC filers to report revenues. Lack of clear totals for the sub categories which make up operating income (loss). Lack of clear totals for distinguishing between nonoperating income (loss) and interest and debt expense. Filers crossing categories of fundamental concepts (for example, including the total of one category within another category). Inappropriate extension of these high-level concepts. Additional information can be found here: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 15

16 3.6. Step 6 Extracting reported facts Digital financial reports contain reported facts. extracted and used individually or as a set. information is looked into in Step 8 below. Those reported facts can be Working with sets of reported Understanding the process of extracting reported facts can be achieved using something which is very easy to extract or something more challenging to extract. For the purposes of this analysis the common concept Revenues is being used because it is commonly reported but can be challenging to find and use. By contrasting extracting the concept revenues with the extraction of easier and more challenging facts helps one understand the process of extracting and working with reported facts. And so, suppose you want to extract information about revenues for the current year-to-date income statement. These are the general steps you must go through once you know which financial report you need to be working with (see Step 2 above), that the information is fundamentally good (see Step 3 above), and you know what the root entity to use if you have more than one income statement being reported (see Step 4 above). You have to then work through the information to make sure you have the appropriate period, appropriate legal entity, and appropriate concept (see Step 5 above). None of this particularly challenging if everything is laid out correctly. But now the fun begins! You want to grab the information for the reported fact with the concept usgaap:revenues. We will assume we have all the other contextual information work out, we will focus on the concept for our purposes here. If you were to seek that concept us-gaap:revenues you would get information from 2,588 SEC filings out of the 7,160 reporting entities queried in this analysis. Why is that? Well, not everyone reports the fact which represents revenues using the concept us-gaap:revenues. There is a partial breakdown of the concepts used to report revenues. Note that 1,524 use some other concept which is not specifically identified. Revenues Concept Count us-gaap:revenues 2,588 us-gaap:salesrevenuenet 1,628 us-gaap:interestanddividendincomeoperating 623 us-gaap:salesrevenuegoodsnet 405 us-gaap:salesrevenueservicesnet 175 us-gaap:oilandgasrevenue 92 us-gaap:healthcareorganizationrevenue 18 us-gaap:realestaterevenuenet 76 us-gaap:regulatedandunregulatedoperatingrevenue 14 us-gaap:revenuemineralsales 11 us-gaap:financialservicesrevenue 6 Some other concept was used to report revenues: 1,524 TOTAL: 7,160 Is this a big deal? Well, considering that you don t know definitively what concepts could be used to report total revenues and you have to somehow figure out what the possible concepts you need to look for might be, and considering that there is nothing in the US GAAP Taxonomy which lists the concepts which might express This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 16

17 revenues, this can be a big deal. If you consider than an extension concept could be used it makes finding revenues even more challenging. But there are other issues which make this even more challenging. The first thing to consider is that some filers report the concept us-gaap:revenues and one or more additional concepts which express revenues. Another way to say this is that you have no idea if total revenues is being expressed or which concept to look for to get total revenues. I will explain this by showing an example. Consider Du Pont s income statement (which you can see here This is a fragment of the income statement: So let s say you tried to use the concepts in the list of concepts which might contain revenues above. You try us-gaap:revenues and you would have no luck. So you try the next concept in the list, us-gaap:salesrevenuenet. You find the concept. But take a close look at the screen shot below and notice that if you thought you found total revenues, you would be mistaken. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 17

18 Notice that Du Pont created an extension concept and that extension concept was at a higher level than even highest level concept in the US GAAP Taxonomy of usgaap:revenues. Either one of two things is going on: (a) Du Pont should have used an existing concept to report total revenues or (b) there is a concept missing from the US GAAP Taxonomy which includes revenues plus other income not included in revenues. Said another way, in SEC XBRL financial filings virtually every reporting entity uses the concept us-gaap:assets and reports that concept, a total of assets, within their financial report. SEC filers are very consistent and it is rather easy go find and This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 18

19 safely use the concept which represents assets because of the total being provided and because the same taxonomy concept is used by filers. But with revenues, the following dynamics can occur: 1. A filer may report us-gaap:revenues and that reported fact might correctly be assumed to be total revenues. 2. A filer may report some other concept, such as Du Pont, such as usgaap:salesrevenuenet and that or some other revenues concept could be assumed to be total revenues. 3. A filer might provide two revenues concepts and NOT provide a total revenues concept and you have to use BOTH to represent total revenues. 4. A filer might create an extension concept, as Du Pont did, and that is deemed to be total revenues. 5. There could be other scenarios. Again, contrasting this to finding and using the reported fact for the concept usgaap:assets ; because the total is always provided and because if a filer wants to create a sub-part of assets they always put that concept within assets as opposed to a parent of assets; safely discovering assets is rather straight forward and trivial. Don t miss the point here. The example shown is not about finding only revenues. The point is that the dynamics of safely finding a reported fact can generally be somewhere between that of finding: revenues (which can be very challenging and risky) because of the dynamics surrounding such reported fact or assets (which can be rather trivial and safe) because of the dynamics surrounding that reported fact And so it is best to create the dynamics similar to assets and avoid dynamics similar to revenues as pointed out above. That is the point and that general principle can be applied to any reported fact be that fact numeric or textual in nature; in the statements or in the policies or disclosures. See the following for more information on extracting revenues from SEC XBRL financial filings: Step 7 Understanding characteristics expressed Every fact in a financial report has characteristics which describe that fact, distinguishing one fact from another fact. For example, the period characteristic distinguishes 2012 from 2011 information. Characteristics are articulated using the entity identifier which is required to contain the CIK number, the period, and any [Axis] provided by the US GAAP XBRL Taxonomy or created by the SEC filer. The following matrix summarizes the number of [Axis] used on [Table]s which are used to represent facts reported by the 7,160 SEC XBRL financial filings analyzed. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 19

20 Because the matrix counts only the [Axis], you need to add 2 characteristics to each number; one for the entity identifier and another for the period. And so the matrix above actually runs from 2 to 24. This same information is shown graphically in this chart: The following is a summary of what is shown: 98% of reported facts have 6 or fewer characteristics The maximum number of characteristics is 26 which is used by exactly one SEC filer There were 6,112 occasions where an [Axis] was created and that [Axis] should NOT have been created because there was no explicit [Table] to associate the [Axis] with. This is a clear modelling error which is easy to detect. It is inconceivable that any financial fact reported would ever need 26 characteristics to report the fact correctly and properly differentiate one reported fact with from another reported fact. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 20

21 The hand full of filers, there are less than 150, that use more than 10 [Axis] are using the [Axis] and [Member] in the form of a dart board. You can see this by looking at the SEC filings. They are impossible to read and they make no sense. It could be the case that the information represented could be broken down into smaller [Table]s, each of which would have fewer [Axis], and then the information would make more sense and the facts reported would better fit into the 98% who don t find the need to use up to 26 [Axis] to report their information Step 8 Understanding report components A financial report is comprised of a number of report components. Examples of report components are the balance sheet, income statement, cash flow statement, significant accounting policies, maturities of long-term debt, and reconciliation of effective income tax rates to statutory rates. A note to a financial report, or disclosure note, is not considered a component. Or rather, if one chooses to consider a disclosure note to be a report component, it is more a layer above what I am considering a report component. Disclosure notes are presentation based. The notion that I am after with report components is trying to get to the individual disclosure which make up a financial report. To understand the importance of being able to identify report components, consider the software application GAAP Watch which lets accountants work with report components. The following is a screen shot of the GAAP Watch application (this video is also helpful in understanding report components, One thing that the GAAP Watch application allows a user to do is work with the disclosures contained within a financial report. To do that the application has to have the ability to identify each of those disclosures. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 21

22 How does one achieve that objective? How can a software application go into a financial report and take you to a specific disclosure within that report, some specific report component, that you are looking for? Here are some options: Use the Network which identifies the report component containing the disclosure. Well, this will not work for two reasons. First, each SEC public company filer defines their own networks such as, Disclosure - Inventories (Details) ( So using the network will not work. You could use the title of the network, Disclosure - Inventories (Details). But if you search on Inventory and the user used Inventories you would not get a match. An even better example is searching on Balance sheet and the filer called their network Statement of financial position. So a text search of the network will not work. You could use the [Table] used to represent the information, for example usgaap:inventorydisclosuretable. That will not work because (a) not every concept in the US GAAP XBRL Taxonomy is expressed within a [Table], (b) SEC filers are not required to use [Table]s to express their disclosures, and (c) many tables in the US GAAP XBRL Taxonomy are so large that the same table is used multiple times to express what is contained within the financial report. Another reason is that many [Table]s are used to represent different things. For example, the us-gaap:statementtable is used to express the balance sheet, income statement, and cash flow statement. So using the [Table] will not work. You could use the network plus the explicitly defined [Table](s) contained within a network and where explicit [Table]s are not defined everything else goes into one implied table. You could look at the individual pieces which make up the disclosure such as the concepts us-gaap:inventorynet, us-gaap:inventoryvaluationreserves, us-gaap:inventoryrawmaterials. Now that will work, and it even has a name: prototype theory. Using prototype theory you use the pieces of something to identify what the something is that you are wanting to work with. However, to make this work someone has to define all those prototypes that can be used to identify the piece that you desire to work with. Some combination of all of these approaches. And so, while it can be challenging to identify the disclosures contained within a financial report, it is possible to identify those disclosures but right now it is a lot of work because the US GAAP XBRL Taxonomy does not lay those out for you so each person desiring to work with the information has to figure out those pieces for themselves or buy some process created by some software vendor. The XBRL Cloud GAAP Watch application is proof that you can identify the pieces and shows you the utility of doing so. But there clearly are report components. Being explicit and clear as to what makes up a report component can help software vendors and others sort through each of the options. The downside of that is that different software vendors will use different options. If the US GAAP XBRL Taxonomy provided a means of expressing report components then everyone could use that This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 22

23 one approach. In lieu of one approach, each user must figure something out on their own. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 23

24 4. Conclusions Reached The following is a summary of conclusions reached from this analysis. The bottom line is that additional business rules which control what SEC XBRL financial filers can and cannot do using automated processes is both possible and highly desirable. While automated testing cannot detect all possible issues, particularly issues where accounting judgment is required; automation enabled by business rules can increase information quality. Stated succinctly: The only way a meaningful exchange of information can occur is the prior existence of agreed upon semantics and syntax rules. This is the only way. These rules are a precondition for a meaningful information exchange. To the extent that a meaningful exchange is achieved the information exchanged can be effectively reused without human intervention. There is a direct correlation between the "agreed upon semantics and syntax rules" and the "meaningful exchange of information." "Agreed upon semantics" has two important aspects: structure and formalism. Both structure and formalism are aspects for classifying semantics and constitute the expressiveness of the semantics which have been agreed to Structure There are many ways to capture the semantics, or meaning, of the things and the relations between the things which make up a domain. These are referred to as organizational systems or classification systems. These are several sorts of such systems: A controlled vocabulary or dictionary can provide a good list of things but tends to be weaker at expressing the relations between the things. A controlled vocabulary is basically a set of standard terms. Also, the properties of each of the terms is generally limited. A taxonomy or classification system adds the notion of a hierarchy between the members of a controlled vocabulary. For example, the terms "horse" and "cat" and "dog" are all types of "mammals". So, you have a good list of things the general sorts of relations between those things. Something like a thesaurus provides a specific type of relationship, a similar term, a broader term, or a narrower term; between the pieces some controlled vocabulary. But again, only some sorts of relations are covered. An ontology allows you to define your controlled vocabulary, a very rich set of properties for the things within that controlled vocabulary, and your own types of relationships between the things in the vocabulary. Specific, explicit types of relationships rather than general "parent-child" type relationships Formalism Creating a structured system can be more formal, or less, formal. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 24

25 The graphic below shows the "bridging role" that something like an ontology plays between a domain and the content of that domain. Every ontology attempts to define and bound a domain. The graphic tries to highlight the trade-off between semantics v. pragmatic considerations. (from As pointed out above, the different types of organizational systems have more, or less, expressive power. The more expressive power, the more time and money it takes to achieve that expressiveness and the higher the semantic clarity of the organizational system which one might create. This is represented graphically below: (Based on work by Leo Obrst of Mitre as interpreted by Dan McCreary, we can view this as a trade-off as one of semantic clarity v. the time and money required to construct the formalism - See more at: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 25

26 4.3. Information quality And so, the quality of the information expressed can only be as good as the rules expressed which force the information to be correct, particularly via automated verification processes enforced by computer software. Now, granted, you will always need some manual processes to make sure the information is correct, for example it is impossible for a an automated process to, say, pick the correct concept a to assign to some reported fact in a financial report. A computer process can help, but it cannot do everything. Computers cannot exercise judgment. However, the more a computer can do, the more that can be automated. The more that can be automated, the higher the quality of the information created and the less time and money it takes to make sure the information is correct. This is particularly true if there are thousands and thousands of different people are creating this information, for example such as the thousands of reporting entities creating something like an SEC XBRL financial filings using XBRL. Any expression of these "things" and the "relations between the things" in an ontology or whatever the classification system must be in a form that business people understand. This must be true because only the business people who have expertise within the domain for which the organizational system is being expressed can tell you if the expression of those things and relations are correct. By correct we mean a sensible, logical, consistent, complete, accurate. Each piece of something like a digital financial report must be correct and the relations between each piece must be correct. For example, "Assets = Liabilities + Equity" is true in the domain of financial reporting and therefore must be true in any expression of "Assets" and "Liabilities and Equity" in any financial report. This is a simple example to make a point, there are much more complicated situations. Only domain experts understand these situations. If business users cannot create correct digital financial reports, for example an SEC XBRL financial filing, then those digital financial reports cannot be useful. If they are not useful, they will not be used Comparability A financial report can be correctly created but not be comparable using automated processes. For example, if a public company reports the concept us-gaap:assets and a second public company creates an extension concept my:assets which has exactly the same meaning as the first public company, the information cannot be compared using automated processes because a computer will simply not understand the two reported facts are the same. This is likewise true if one fact has the same concept, say us-gaap:assets but other characteristics of the fact are different, such as one is characterized as relating to the reporting scenario of say successor entity and the other has no such characteristic Qualitative versus quantitative disclosures Other facts and report components will never be comparable and should never be comparable. For example, many qualitative disclosures will never be comparable across reporting entities because the event, transaction, or circumstance is unique to that reporting entity. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 26

27 Achieving comparability is a balancing act what requires trade-offs and professional judgment of accountants, attorneys, and other business professionals. Comparability is a basically a choice Endless permutations and combinations are unnecessary Providing endless permutations and combinations of possible combinations of reported facts such as Organization, Consolidation, Basis of Presentation, Business Description and Accounting Policies and Organization, Consolidation and Presentation of Financial Statements Disclosure and Significant Accounting Policies is grounded in the way financial disclosures are presented within the notes to the financial statements. Accountants need to understand the difference between a disclosure and a disclosure note. Disclosure notes are how disclosures are organized within a financial report and can vary widely between reporting entities. Disclosures do not change, they are legal requirements. Reporting entities can supplement what is required by disclosing more. But that does not change the disclosure Wrong debate There is a debate about which is the appropriate way to express XBRL information: (a) Inline XBRL is pushed by some, (b) Data Point Model (DPM) is pushed by others, (c) Global Filing Manual, not sure how that is going, (d) the SEC/US GAAP XBRL Taxonomy is similar to the Global Filing Manual approach but is different. Further, there is a debate as to whether to use XBRL at all and rather to use some other technical syntax such as RDF and OWL. Others think that some other XML format is the panacea. However, this is the wrong debate. Not one of these approaches offers concrete and definitive proof that it actually works to enable a meaningful exchange of the financial and nonfinancial information contained within a financial report. And none of those arguing the case for their specific technology of choice addresses the fundamental fact that "meaningful exchange can only occur to the extent of prior existence of agreed upon semantics and syntax rules." No technology is known to offer or proven to offer a 100% solution to every need of digital financial reporting. Even if such a solution existed it would likely be too complicated for business users to actual use successfully. Syntactic rules and therefore syntactic interoperability at the XBRL technical syntax level is very good, it has been since about 2003 when XBRL International started building conformance suites. However, digital financial reporting semantic interoperability still suffers, so information quality suffers, and so information use by investors, analysts, and data aggregators suffers. The first step which is necessary to create a system which works is to define the requirements of the desired system. The requirements must be realistic. The system must be realistic. There will be tradeoffs. The system will likely evolve over the years to do more in the future than when initially created. Expectations must be properly set. The evolution path should be clear. A proper balance must be achieved between something which is so formal and technically complex that it can never be implemented and something which is so informal and simplistic that it really serves no one s needs. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 27

28 Achieving a balance is a choice. The proper balance can only be achieved if business professionals who need the system can articulate their true needs correctly and communicate those needs to the information technology professionals who can build that system Correct debate Business users need to debate the business semantics which must be used to make digital financial reports useful. Information exchanged must be fundamentally meaningful. But simply having meaningful information but every reporting entity representing information differently, and therefore allowing for the comparison of that information, is not enough. Comparability is enabled by conscious effort. What is comparable and what is not comparable is a choice. For example, if a scheme is not devised to indicate which root reporting entity is the starting point for comparability, the information will simply not be comparable because the information one wishes to compare cannot be located. And so the debate should be about establishing business reporting semantics such as: (a) Identification of an economic entity which reports information and perhaps the ultimate parent of that economic entity, (b) agreeing on the pieces of a reporting entity terminology such as in the diagram below. As can be seen, there is nothing inherently technical about the information shown in the diagram. Business users need to make these choices, represent reality, ensure their representation is correct, establish business rules which enforce these relations, and therefore enable the meaningful exchange of information Formal, rigorous, comprehensive, violent testing The only way to be sure that business users are communicating is through formal, rigorous, comprehensive, and sometimes even violent testing to be sure the systems the technical professions came up with truly meets the needs of the business professionals. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 28

29 The only way to be sure that a system will be cost effective, easy to use, robust, reliable, repeatable, predictable, scalable, secure, auditable, and can effectively exchange business information meaningfully is through formal, rigorous, comprehensive, and sometimes even violent testing. The only way to be sure that each piece of the system works and that the many individual pieces work together as desired is through formal, rigorous, comprehensive, and sometimes even violent testing. If a test is missing from the set of business use cases necessary for the system to operate, that missing aspect may not work. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 29

30 5. Recommendations The following is a set of recommendations based on information obtained from this analysis. The recommendations are intended to communicate possible approaches to improving digital financial reporting. While these could be implemented in the US GAAP XBRL Taxonomy and SEC XBRL financial filings, and perhaps might be; understanding these recommendations can help others building systems to avoid undesirable aspects or approaches to utilizing XBRL in those systems Explicitly define the categories of report elements used to represent financial report semantics within an XBRL taxonomy and communicate this information to software vendors For example, the US GAAP XBRL Taxonomy Architecture specifies these report elements: Network: A network is one approach to break a digital financial report into smaller pieces. Table: A table is used to combine facts which go together for some specific reason. Axis: An axis is a means of providing information about the characteristics of a fact reported within a financial report. Member: A member is a possible value of an [Axis]. Line Items: [Line items] are a set of concepts which can be reported by an entity, they can contain values. [Line Items] may also contain [Abstract] concepts which can never report values but rather are used to help organize the [Line Items]. Abstract: An [Abstract} is a type of concept which can never be reported, but rather is used to organize an information model. Concept: A concept refers to a financial reporting concept or a non-financial concept which can be reported as a fact within a financial report. Note that Table = Hypercube; Axis = Dimension; Line Items = Primary Items Explicitly define the relations, including cardinality, between defined report element categories and communicate this information to software vendors This will encourage software vendors to verify these relations within their software. This will eliminate the possibility of this type of error from occurring. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 30

31 5.3. Explicitly describe and follow the member arrangement patterns which clearly exist within an XBRL taxonomy The relations between the [Member]s which make up the allowed values of an [Axis] are not random, they follow patterns. Complete Flat Set: A set of members, no root member, no aggregation Simple Flat Aggregation: A set of members, with aggregation, therefore MUST have root member. Nested Member Aggregation: A set of members, with aggregation, also has nested aggregation. Region and country are represented using one characteristic. Multiple Characteristics: A set of members, with aggregation, also has nested aggregation. Region and country are represented using two characteristics. (Note that the meaning of the information did not change, only the representation method.) 5.4. Explicitly describe and follow the accounting concept arrangement patterns which clearly exist within an XBRL taxonomy The relations between the Concepts which make up a set of [Line Items] is not random, they follow patterns. For example, the US GAAP XBRL Taxonomy has an identifiable set of accounting concept arrangement patterns ([Line Items] arrangement patterns). The taxonomy should consistently adhere to these patterns by describing each and representing them consistently within the taxonomy. Software vendors should be encouraged to understand these accounting arrangement patterns and allow business users to interact with digital financial reports at this level rather than the XBRL technical syntax level. The following is a summary of these accounting arrangement patterns: Roll up: Fact A + Fact B + Fact C = Fact D (a total) Roll forward: Beginning balance + changes = Ending balance (this is sometimes called a movement analysis or BASE pattern; beginning balance + additions subtractions = ending Adjustment: An adjustment reconciles an originally stated balance to a restated balance between two report dates; Originally stated balance + adjustments = restated balance Variance: A variance is a change across a reporting scenario. Actual amount - Budgeted amount = variance Complex computation: A complex computation is a type of accounting concept arrangement where facts are related by some computation other than a roll up, roll forward, adjustment, or variance. For example, Net income / Weighted average shares = earnings per share. Hierarchy: A hierarchy is a type of accounting concept arrangement where facts are related in some way, but not mathematically. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 31

32 5.5. Define clear semantics for identifying report components There are three viable approaches for representing the components of a financial report: 1. Network defines report component (i.e. hypercube is meaningless) 2. Hypercube defines report component (i.e. network is meaningless) 3. Network plus hypercube defines report component (i.e. both network and hypercube have semantic meaning) It makes no sense for hypercubes to sometimes be polymorphic and sometimes be isomorphic; either one or other approach should be picked and used. Each of these options has pros and cons. Option #3 can work, but either option #1 or #2 is greatly superior to this option. Using two things to describe one thing is not necessary Explicitly define a set of fundamental accounting concepts The set of fundamental accounting concepts which are proven to be the same for every reporting entity should be identified, instantiated, and articulated to others. The following is an example of these fundamental accounting concepts for US GAAP: Category Fundamental Concept Label Fundamental Concept Name GeneralInformation Entity name EntityRegistrantName GeneralInformation Entity Centeral Index Key EntityCentralIndexKey GeneralInformation Entity filer category EntityFilerCategory GeneralInformation Fiscal year FiscalYear GeneralInformation Income statement period YTD (period start date) IncomeStatementPeriodYTD GeneralInformation Balance sheet date BalanceSheetDate BalanceSheet Current assets CurrentAssets BalanceSheet Noncurrent assets NoncurrentAssets BalanceSheet Assets Assets BalanceSheet Current liabilities CurrentLiabilities BalanceSheet Noncurrent liabilities NoncurrentLiabilities BalanceSheet Liabilities Liabilities BalanceSheet Commitments and contingencies CommitmentsAndContingencies BalanceSheet Temporary equity TemporaryEquity BalanceSheet Equity attributable to parent EquityAttributableToParent BalanceSheet Equity attributable to noncontrolling interest EquityAttributableToNoncontrollingInterest BalanceSheet Equity Equity BalanceSheet Liabilities and equity LiabilitiesAndEquity IncomeStatement Revenues Revenues IncomeStatement Costs of revenues CostOfRevenue IncomeStatement Gross profit GrossProfit IncomeStatement Operating expenses OperatingExpenses IncomeStatement Other operating income OtherOperatingIncome IncomeStatement Operating income (loss) OperatingIncomeLoss IncomeStatement Nonoperating income (loss) NonoperatingIncomeLoss IncomeStatement Interest and debt expense InterestAndDebtExpense IncomeStatement Income before equity method investments IncomeBeforeEquityMethodInvestments IncomeStatement Income from equity method investments IncomeFromEquityMethodInvestments IncomeStatement Income from continuing operations before tax IncomeFromContinuingOperationsBeforeTax IncomeStatement Income tax expense (benefit) IncomeTaxExpenseBenefit This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 32

33 Category Fundamental Concept Label Fundamental Concept Name IncomeStatement Income from continuing operations after tax IncomeFromContinuingOperationsAfterTax IncomeStatement Income from discontinued operations IncomeFromDiscontinuedOperations IncomeStatement Extraordinary items, gain (loss) ExtraordaryItemsGainLoss IncomeStatement Net income (loss) NetIncomeLoss IncomeStatement Net income attributable to parent NetIncomeAttributableToParent IncomeStatement Net income attributable to noncontrolling interest NetIncomeAttributableToNoncontrollingInterest IncomeStatement Net income available to common stockholders, basic NetIncomeAvailableToCommonStockholdersBasic IncomeStatement Preferred stock dividends and other adjustments PreferredStockDividendsAndOtherAdjustments StatementOfComprehensiveIncome Comprehensive income StatementOfComprehensiveIncome Comprehensive income attributable to parent StatementOfComprehensiveIncome Comprehensive income attributable to noncontrolling interest StatementOfComprehensiveIncome Other comprehensive income ComprehensiveIncome ComprehensiveIncomeAttributableToParent ComprehensiveIncomeAttributableToNoncontrollingInterest OtherComprehensiveIncome CashFlowStatement Net cash flows, operating, continuing NetCashFlowsOperatingContinuing CashFlowStatement Net cash flows, operating, discontinued NetCashFlowsOperatingDiscontinued CashFlowStatement Net cash flows, operating NetCashFlowsOperating CashFlowStatement Net cash flows, investing, continuing NetCashFlowsInvestingContinuing CashFlowStatement Net cash flows, investing, discontinued NetCashFlowsInvestingDiscontinued CashFlowStatement Net cash flows, investing NetCashFlowsInvesting CashFlowStatement Net cash flows, financing, continuing NetCashFlowsFinancingContinuing CashFlowStatement Net cash flows, financing, discontinued NetCashFlowsFinancingDiscontinued CashFlowStatement Net cash flows, financing NetCashFlowsFinancing CashFlowStatement Net cash flows, discontinued NetCashFlowsDiscontinued CashFlowStatement Exchange gains (losses) ExchangeGainsLosses CashFlowStatement Net cash flow NetCashFlow KeyRatios Sustainable growth rate (SGR) SustainableGrowthRate KeyRatios Return on assets (ROA) ReturnOnAssets KeyRatios Return on equity (ROE) ReturnOnEquity KeyRatios Return on sales (ROS) ReturnOnSales NatureOfBusiness Nature of operations NatureOfOperations GeneralInformation Trading Symbol TradingSymbol GeneralInformation Fiscal Period FiscalPeriod GeneralInformation Document Type DocumentType GeneralInformation InstanceURI InstanceURI IncomeStatement Nonoperating Income Loss Plus Interest And Debt Expense CashFlowStatement Net cash flows, continuing NetCashFlowsContinuing StatementOfComprehensiveIncome Net income (loss) NonoperatingIncomeLossPlusInterestAndDebtExpense NetIncomeLoss For more information see: Explicitly define unchangeable relations between the set of fundamental concepts The relations between the set of fundamental accounting concepts should be identified, instantiated, and articulated to others. The following is an example of these relations between fundamental accounting concepts for US GAAP: ID Fundamental Concept Name Fundamental Relation (Business Rule) 1 NoncurrentAssets NoncurrentAssets = Assets - CurrentAssets 2 Assets Assets = LiabilitiesAndEquity 3 Assets Assets = Liabilities + CommitementsAnd Contingencies + TemporaryEquity + Equity 4 Assets Assets = CurrentAssets + NoncurrentAssets 6 Equity Equity = EquityAttributableToParent + EquityAttributableToNoncontrollingInterest This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 33

34 ID Fundamental Concept Name Fundamental Relation (Business Rule) 7 CurrentAssets CurrentAssets = Assets - NoncurrentAssets 8 Liabilities Liabilities = CurrentLiabilities + NoncurrentLiabilities 9 LiabilitiesAndEquity LiabilitiesAndEquity = Liabilities + CommitmentsAndContingencies + TemporaryEquity + Equity 10 NoncurrentLiabilities NoncurrentLiabilities = Liabilities - CurrentLiabilities 11 Liabilities Liabilities = LiabilitiesAndEquity - (CommitementsAnd Contingencies + TemporaryEquity + Equity) 13 NetCashFlows NetCashFlows = NetCashFlowsOperating + NetCashFlowsInvesting + NetCashFlowsFinancing + ExchangeGainsLosses 14 NetCashFlowsOperating NetCashFlowsOperating = NetCashFlowsOperatingContinuing + NetCashFlowsOperatingDiscontinued 15 NetCashFlowsInvesting NetCashFlowsInvesting = NetCashFlowsInvestingContinuing + NetCashFlowsInvestingDiscontinued 16 NetCashFlowsFinancing NetCashFlowsFinancing = NetCashFlowsFinancingContinuing + NetCashFlowsFinancingDiscontinued 17 NetCashFlowsDiscontinued NetCashFlowsDiscontinued = NetCashFlowsOperatingDiscontinued + NetCashFlowsInvestingDiscontinued + NetCashFlowsFinancingDiscontinued 18 NetCashFlowsContinuing NetCashFlowsContinuing = NetCashFlowsOperatingContinuing + NetCashFlowsInvestingContinuing + NetCashFlowsFinancingContinuing 19 GrossProfit GrossProfit = Revenues - CostOfRevenue 20 OperatingIncomeLoss OperatingIncomeLoss = GrossProfit - OperatingExpenses + OtherOperatingIncome 21 OperatingIncomeLoss OperatingIncomeLoss = Revenues - CostsAndExpenses + OtherOperatingIncome 22 CostsAndExpenses CostsAndExpenses = CostOfRevenue - OperatingExpenses 23 IncomeBeforeEquityMethodInvestments IncomeBeforeEquityMethodInvestments - OperatingIncomeLoss + NonoperatingIncomeLoss - InterestAndDebtExpense 24 IncomeFromContinuingOperationsBeforeTax IncomeFromContinuingOperationsBeforeTax = IncomeBeforeEquityMethodInvestments + IncomeFromEquityMethodInvestments 25 IncomeFromContinuingOperationsAfterTax IncomeFromContinuingOperationsAfterTax - IncomeFromContinuingOperationsBeforeTax - IncomeTaxExpenseBenefit 26 NetIncomeLoss NetIncomeLoss = IncomeFromContinuingOperationsAfterTax + IncomeFromDiscontinuedOperations + ExtraordinaryItemsGainLoss 27 NetIncomeLoss NetIncomeLoss = NetIncomeAttributableToParent + NetIncomeAttributableToNoncontrollingInterest 28 NetIncomeAvailableToCommonStockholdersBasic NetIncomeAvailableToCommonStockholdersBasic = NetIncomeAttributableToParent - PreferredStockDividendsAndOtherAdjustments 29 ComprehensiveIncome ComprehensiveIncome = NetIncomeLoss + OtherComprehensiveIncome 30 ComprehensiveIncome ComprehensiveIncome = ComprehensiveIncomeAttributableToParent + ComprehensiveIncomeAttributableToNoncontrollingInterest 32 SustainableGrowthRate SustainableGrowthRate = (([NetIncomeLoss]/[Revenues])*(1+(([Assets]- [Equity])/[Equity])))/((1/([Revenues]/[Assets]))-((([NetIncomeLoss]/[Revenues])*(1+((([Assets]- [Equity])/[Equity])))))) 33 ReturnOnAssets ReturnOnAssets = ([NetIncomeLoss]/[Assets]) 34 ReturnOnEquity ReturnOnEquity = ([NetIncomeLoss]/[Equity]) 35 ReturnOnSales ReturnOnSales = ([NetIncomeLoss]/[Revenues]) For more information see: Differentiate the notion of unchangeable mathematical relations and mathematical relations financial report creators can change The notion that some relations between financial reporting concepts must never change should be communicated within a taxonomy. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 34

35 5.9. Explicitly and formally map each taxonomy concept to a fundamental concept (i.e. define class-subclass relations) Each concept created within a taxonomy should be associated with some fundamental accounting concept. For example, all concepts defined which are an asset should be specifically defined as such using perhaps a class-subclass type relation or the existing general-special relation defined by XBRL. This could be achieved using the XBRL definition linkbase. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 35

36 6. APPENDIX: Terminology It is important to ground any conversation with some basic terminology in order to be sure one is communicating properly. This analysis uses, or at least endeavors to use, specific, precise terminology. This terminology can be grouped into two pieces: report level representation the report itself financial reporting domain level representation what goes into the report While both levels are important, the most important level necessary for accountants to understand and create is the financial reporting domain level representation. That must simply fit into the report level representation Report level representation Most people are very familiar with the notion of a reported fact or fact in an SEC XBRL financial filing. Facts are things which get reported. While there is no good formal definition of a fact, I believe that the following definition of a fact is better than any other definition which I have seen: 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. A fact value is one property of a fact. Every fact has exactly one fact value. The set of characteristics of a fact is another property of a fact. Numeric facts also have a units property and a decimals property (sometimes thought of as rounding ). The definition of the term fact uses the term characteristic. So, one must also define the term characteristic. Again, there is not a formal definition of characteristic, but this definition is the best informal definition which I have seen: 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. There is one final thing which must be defined to have the conversation which needs to be had and that is the report component: Report Component: A report component is a set of facts which go together (tend to be cohesive and share a certain common nature) for some specific purpose within a financial report. For example, a "balance sheet" is a report component. "Maturities of long-term debt" is a report component. And so those are the terms we will be working with. I want to walk through this visually so we are clear what we are talking about. This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 36

37 Let s walk through this visually. The figure below is the number What can you tell me about this number? Not very much. This is not a fact because it has no characteristics. OK, let us go to the next step. This still does not make much sense, we see two numbers but you still cannot tell me much about the numbers other than their values. Ah, now we are starting to understand the numbers a little. This is starting to look like a fact. We can see the fact values and the characteristic Concept which differentiates and contextualizes the fact values. But a reported fact generally has more than one characteristic. The next graphic is starting to make more and more sense. We see two facts, one is characterized to be Revenues the other is characterized to be the concept Net income and both facts are characterized by the same reporting entity ABC Company, legal entity Consolidated entity, and period Jan 1, 2011 to Dec 31, There are two facts above. Both facts together make up a report component. Not a very interesting report component at this point, but hopefully you understand the three terms we are using: fact, characteristic, and report component. So let s look at a more real example but one that is not that complicated and one that avoides pretty much all accounting related terminology. This example is applicable to pretty much every reporting entity which creates an SEC XBRL financial filing. The example is not very exciting, but it can be used to make a very specific piont and explain how characteristics work. Note that for the purposes of this example we are ignoring the units and decimals properties of facts. This is done to make the example as simple as possible. Units This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 37

38 and decimals are important, but they are not important to making the points we are trying to make. Consider this example, document and entity information: The above is commonly found in SEC XBRL financial filings. What exactly does the example say? Think about that. This is a trick question, so watch out. I am not going to explain the information beyond asking a few questions. But first, here is exactly the same information layed out in the same form as the list of facts above. Above we had two facts, below we have 18 facts. Those 18 facts are rendered in a more easily understood form, but the raw information below shows the details of what you are looking at. The information in the rendering and the information below is exactly the same information. And so here are some questions you might ask: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 38

39 Why does the concept Entity Registrant Name with a value of ABC Company on line 16 have a Class of Stock characterstic? The class of stock characteristic is shown to be Class of stock [Domain] as articulated by the Class of Stock [Axis]. Same question for the Document Fiscal Period Focus on line 7, or the Trading Symbol on line 5. Consider the following screen show which is another way to represent that same set of information: Ah, something is starting to make more sense. Above you see that the same informatino is broken into two groups: Entity Information and Document information. Well, that makes sense; some of the information does relate to the reporting entity and other information does relate to the document being reported. But let us take this one step further. The information actually has three distinct pieces: information which relates to the document, information which relates to the reporting entity, and information which relates to the listings of the reporting entity: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 39

40 Document information: Entity information: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 40

41 Entity listing information: If you look at these three representations of the exact same information in the first combined example you see a couple of things happening. The first thing you might see is that the information looks more sensible and logical. You don t see anything related to the Common stock [Axis] in either the document information or entity information. Second, you see a lot of white space or blank cells disappearing. Blank cells are good indications of representations which are incorrect. Looking at the same information in the form of the fact tables for each of the report components is helpful: Document information: Entity information: Entity listing information: This work is licensed under a Creative Commons License. Attribution 3.0 Unported (CC BY 3.0) 41