BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  It is for innovators and early adopters who are ushering in a new era of digital financial reporting.

Much of the information contained in this blog is summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the three documents on this digital financial reporting page.

Fiddling Around with Fundamental Accounting Concept Report Frames

I have been fiddling around with what I call report frames.  A report frame is a more flexible and expanded approach to making use of fundamental accounting concepts. In my initial approach, I had only one set of fundamental accounting concepts and I tried to fit every reporting entity into that one set.  Now I have 126 sets! Why so many now?  Because public companies report in different ways, using different "report frames".  This blog post explains the permutations/combinations which I have notices.

What this achieves is make the impute rules easier to understand and allows more flexibility.  Basically, there is not really one hierarchy, there are a number of different hierarchies.

You can get to the report frame index here. From there just click on the "count" to see the reporting entities which report a specific way.  Read the Description. For example, this is the most popular report frame:

CI, balance sheet CLASSIFIED, redeemable noncontrolling interest NOT REPORTED, cash flow statement NORMAL, income statement MULTI-STEP, income (loss) from equity method investments NOT REPORTED, operating income (loss) REPORTED

You don't need to understand the codes such as "COMID-BSC-RNIXX-CF1-ISM-IEMIX-OILY".  The code and the description say the same thing.

Stay tuned...more to come!

Posted on Friday, September 19, 2014 at 05:45PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Phenomenon Points to Need for Global Standard Way to Define a Class using XBRL

There is some phenomenon which I am observing.  It seems to me that this is not something unique to financial reporting but rather it is likely common to many different domains.  I first articulated this observation in this blog post.  The observation relates to why automated processes cannot make use of information reported in SEC XBRL financial filings.  I repeat the four reasons which I observed as part of my testing:

  • Missing totals/subtotals: Missing fundamental accounting concept totals/subtotals. For example, most filers do report key totals such as "Assets", "Equity", "Revenues", Net Income (Loss)" and so forth.  If filers don't report such totals/subtotals, it can cause problems with reading the information.
  • Crossing categories: Filers moving a fundamental accounting concept to be part of some other fundamental accounting concept.  A common situation is where a filer moves the concept "Interest and Debt Expense" to be included as part of "Nonoperating Income (Expenses)".
  • Extension category unknowable: No machine readable information which relates an extension concept to some existing US GAAP XBRL Taxonomy concept or concept category. For example, if a filer reports the concept "my:SomeTypeOfOperatingExpense" and they intended that to be an operating expense, while a human can figure out that the concept is an operating expense, a computer cannot.
  • Missing US GAAP XBRL Taxonomy concept: If a high-level concept is missing from the US GAAP XBRL Taxonomy, it can cause the filing to not be decipherable by automated processes.

I mentioned this observation to someone that I know who has an information technology background. He summarized his observation about this in the following statement: "...there is a boundaries problem...".  That term "boundaries" seemed to totally fit.  Mapping that term to my observations, I get the following:

  • Missing totals/subtotals = Missing boundaries
  • Crossing categories = Crossing boundaries
  • Extension category unknowable = Not explicitly indicating what category or boundary an extension goes into
  • Missing US GAAP XBRL Taxonomy concept = US GAAP XBRL Taxonomy not properly defining all concepts, articulating all boundaries, or providing an explicit means for indicating the concept or category a filer is extending

Like I mentioned above, this seems like a general or common sort of problem.  It seems to me that there should be some sort of observation about this sort of situation in something like network theory or graph theory.

It seems to me that what is missing is a global standard way to define or establish a "class" such as the way RDF can define a class.  Also missing is the ability to articulate that something is a subclass or equivalent class and so on.  Probably one of the biggest clues that this is true is that RDF has the notion of a class and RDF is pretty much doing the same sort of thing XBRL is trying to do.

Further, several months ago in this blog post I pointed out that different concepts in the US GAAP XBRL Taxonomy act differently.  This is an improved version of that categorization:

  • Concept required: it would make no sense to extend concept. For example, there are obvious examples of such concepts like dei:EntityRegistrantName and dei:DocumentFiscalYearFocus. It absolutely, 100% makes zero sense to allow extension of such concepts.
  • Optional concept: it would make no sense to extend concept. This is similar to the category above, but the concept is NOT required to be reported, such as dei:TradingSymbol, or the concept would only be reported if the filer actually had the concept, such as us-gaap:InventoryNet.
  • Allowed to add subclasses of concept, but not extend concept: For some concepts, it makes a lot of sense to allow a filer to add a subclass for that concept or as some people think about it, to add a "child".  But, it makes no sense to extend the concept. So again take the concept us-gaap:InventoryNet. It is hard to imagine the need to provide for some other concept "my:InventoryNet".
  • Allowed to create extension concept: Suppose that some SEC filer wanted to disclose carbon credit information in their financial report but the US GAAP XBRL Taxonomy contained no such concepts.  Pretty clear than an extension concept could be created.  Likewise pretty clear that if a filer needs subclasses, children, or other stuff those should be allowed for also.  Basically, if something clearly does not exist and a filer needs it, creating an extension should be allowed in such cases.

So what I am pointing out, I believe, is that there are specific classes of things in something like the US GAAP XBRL Taxonomy that act in specific and important ways.

Now, XBRL has no problem articulating this sort of information.  XBRL definition relations can be used to define this information.  What is missing though is a global standard XBRL arcrole for describing these classes and subclasses and/or the US GAAP XBRL Taxonomy making use of those global standard arcroles if they existed, or defining the arcroles themselves if the do not exist.

Bottom line: XBRL is missing the ability to define a "class" and the notion of a "subclass".  Easy enough to fix, simply add the needed arcroles in the XBRL Link Role Registry.

Posted on Friday, September 19, 2014 at 08:19AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Wonderful Things XBRL-based Structured Information Enables

Oh the wonderful things XBRL-structured information enables.  This is not earth shattering information by any means, but what is earth shattering is that it is almost becoming trivial to do queries which return information like the following:

  • Of all SEC filers, 77% report using a classified balance sheet, 23% use an unclassified balance sheet. There are 6 which report on a liquidity basis.
  • Of all SEC filers, 69% use a single-step income statement, 31% use a multi-step income statement.
  • Of all SEC filers, 6,092 do not report "Income (Loss) from Equity Method Investments".  Of those filers that do, 314 report the line item before tax, 101 report it after tax, 16 report it as part of revenues, and 151 report it as part of nonoperating income (expenses)

Below is a screen shot of some quick and dirty queries that I created to try and understand the way public companies report.  This may not make total sense or it may not be interesting for your analysis purposes, but it is useful for what I am working on. Click on the image to check it out.  Or, grab this ZIP file which has an Excel spreadsheet with the information. I even created a handy pivot table you can play with.

(Click image for larger view)

Enough said. I will let the demo speak for itself.

Posted on Monday, September 15, 2014 at 01:09PM by Registered CommenterCharlie in , | CommentsPost a Comment | EmailEmail | PrintPrint

Understanding Why SEC XBRL Filings Cannot be Deciphered and How to Fix Situation

There appears to be exactly four specific situations which make it impossible to read basic information and decipher the correct meaning from the information reported within SEC XBRL financial filings using automated processes. By basic information I mean information about the entity of focus and the current reporting period. Additional things are perhaps needed to read information which has additional characteristics associated with reported facts.

The four specific situations are:

  • Missing totals/subtotals: Missing fundamental accounting concept totals/subtotals. For example, most filers do report key totals such as "Assets", "Equity", "Revenues", Net Income (Loss)" and so forth.  If filers don't report such totals/subtotals, it can cause problems with reading the information.
  • Crossing categories: Filers moving a fundamental accounting concept to be part of some other fundamental accounting concept.  A common situation is where a filer moves the concept "Interest and Debt Expense" to be included as part of "Nonoperating Income (Expenses)".
  • Extension category unknowable: No machine readable information which relates an extension concept to some existing US GAAP XBRL Taxonomy concept or concept category. For example, if a filer reports the concept "my:SomeTypeOfOperatingExpense" and they intended that to be an operating expense, while a human can figure out that the concept is an operating expense, a computer cannot.
  • Missing US GAAP XBRL Taxonomy concept: If a high-level concept is missing from the US GAAP XBRL Taxonomy, it can cause the filing to not be decipherable by automated processes.

Many people believe that it is extensions alone that cause all the problems of making use of XBRL-based financial information.  This is not the case.  A filer could create a filing with no extension concepts and the meaning reported by the filing can still be undecipherable. Alternatively, a filer can create numerous extensions and the meaning of the reported information within the filing can be completely and correctly deciphered.  And I am not including reporting errors which can cause problems because reporting errors can be fixed by the filer.

A filer inappropriately extending a fundamental accounting concept is explicitly not included in the list. If a filer extends a high-level concept, it will generally cause serious problems automating the use of the information.  For example, extending the concept "Net Income (Loss)" will cause problems.  But this is considered a filer error.  Errors are not included, filers can fix errors.

None of the situations above can generally be fixed by SEC filers, they need to be fixed by those that manage the US GAAP XBRL Taxonomy and those writing the rules for SEC XBRL financial filings.   Now, filers do have the power to work around each of these situations, at least in part.  Filers can creates safer filings by avoiding the four items in the list above as best as they can.

Understanding the impact of these situations is easy, you simply need to attempt to read SEC XBRL financial filing information using an automated process and look at the results which are achieved.

Finally, while if all four of those situations were corrected deciphering the meaning of reported information would work; it may not be the case that correcting all four are necessary.  For example, while reporting certain subtotals would solve problems related to using filing information, certain subtotals are not required to be reported.  But, if filers where not allowed to "cross categories" and change the meaning of information and if machine readable information about what category an extension concept fits into; the subtotals would not be necessary.

Posted on Saturday, September 13, 2014 at 12:02PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Diligence, Negligence, and Gross Negligence

Some definitions:

Diligence: Diligence is steadfast application, assiduousness and industry; the virtue of hard work.

Due diligence: Due diligence is the necessary amount of diligence required in a professional activity to avoid being negligent.

Negligence: Negligence is a failure to exercise the care that a reasonably prudent person would exercise in like circumstances.

Gross negligence: Gross negligence is a legal concept which means serious carelessness. Negligence is the opposite of diligence, or being careful. The standard of ordinary negligence is what conduct one expects from the proverbial "reasonable person." By analogy, if somebody has been grossly negligent, that means they have fallen so far below the ordinary standard of care that one can expect, to warrant the label of being "gross."

Posted on Friday, September 5, 2014 at 09:03AM by Registered CommenterCharlie | CommentsPost a Comment | EmailEmail | PrintPrint
Page | 1 | 2 | 3 | 4 | 5 | Next 5 Entries