Digital Financial Reporting

If you have not tried Tableau, I would encourage you to do so.  This is all you need to do:

1. Download and install Tableau Public which is free.
2. Watch this Overview of Tableau Video.
3. Here is the data they used in the overview video related to Seattle building permits.

Good stuff!

ADDED: Here are some additional data sources:

• King county
• City of Santa Monica
• State of Oregon
• State of Colorado
• New York City
• World Bank
• Kenya

In a prior blog post, I pointed out a resource that helps you see some of the types of errors that exist in XBRL-based financial reports.  In this blog post I want to help you see the difference between an error and issues caused by ambiguity.

When a public company reverses the concepts that they use to report "Equity attributable to parent" and "Equity" (the total including the parent and noncontrolling interest) it is not really that hard to see that the filer is making a mistake.  Additional evidence is provided by the 99% of public companies that do not reverse their equity concepts and everything works as expected.  That is one end of the spectrum, the end where it is clear that the filer is making a mistake.

The balance sheet inconsistency analysis that I provided in that prior blog post focuses on that end of the spectrum: clear errors.

The other end of the spectrum I will call ambiguity.  Here is an example of ambiguity as to what is right and what is wrong. This analysis of operating and nonoperating income and expense provides a good example. In that analysis of 83 companies that report using the same style where one total for "Revenues" is provided, another total for "Expenses" is provided, and then "Income (loss) before taxes" is the difference between the two.  There are FOUR WAYS these 83 public companies report this information:

• Use the existing US GAAP XBRL Taxonomy concepts for both REVENUES and EXPENSES, usually "us-gaap:Revenues" even when the line item includes other nonoperating income and "us-gaap:CostsAndExpenses" to report even though nonoperating items are included.
• Creating an extension concept to report the line item "Total operating and nonoperating revenues" but use the existing concept "us-gaap:CostsAndExpenses" to report total expenses, even if nonoperating items are included in that line item.
• Use the existing US GAAP XBRL Taxonomy concept "us-gaap:Revenues" even though nonoperating revenues or other income are included, but then create an extension concept for "Total operating and nonoperating costs and expenses".
• Create extension concepts for BOTH "Total operating and nonoperating revenues" and "Total operating and nonoperating costs and expenses".

It seems highly unlikely that allowing all four of those alternatives provides any sort of benefit to either those creating financial reports or analyzing the reported information.  Now, it can be tricky to understand if a line item is operating or nonoperating in nature.

The US GAAP XBRL Taxonomy is pretty clear on the following relationship:

(+) Revenues (us-gaap:Revenues)

(-) Costs and Expenses (us-gaap:CostsAndExpenses)

(+) Other Operating Income (us-gaap:OtherOperatingIncome)

(=) Operating Income (Loss) (us-gaap:OperatingIncomeLoss)

Further, the US GAAP XBRL Taxonomy is pretty clear that nonoperating income (expense) (the concept us-gaap:NonoperatingIncomeExpense) and interest and debt expense (the concept us-gaap:InterestAndDebtExpense) are not part of any of the above concepts as far as I can tell from the taxonomy.

So why are all these filers using the concept us-gaap:Revenues to represent what appears to be operating and nonoperating revenues?  Same question for using us-gaap:CostsAndExpenses to represent what appears to include nonoperating expenses?

And, why do some filers create extension concepts along the lines of "my:TotalOperatingAndNonoperatingRevenues" and/or "my:TotalOperatingAndNonoperatingExpenses"?  Seems pretty clear that those include both operating and nonoperating items.

It is very hard to understand exactly what is right here given these moving pieces.  My bet is that there are two concepts missing from the US GAAP XBRL Taxonomy:

• Operating and nonoperating revenues and other income
• Operating and nonoperating costs and expenses

Another situation can be seen with an analysis of the line item income (loss) from equity method investments when reported as part of the income tax provision.  The facts at work are very straight forward.  The moving part is ONLY the reporting of the line item "income (loss) from equity method investments".  Of the 45 filers in the analysis, there are exactly two ways this is done:

1. Using the existing US GAAP XBRL Taxonomy concept us-gaap:IncomeLossFromEquityMethodInvestments. (41 filers do this)
2. Using an extension concept. (4 filers do this)

Now, not once does the US GAAP XBRL Taxonomy show the concept us-gaap:IncomeLossFromEquityMethodInvestments organized in the manner that the 41 filers use the concept.  As such, if one moves a concept from the US GAAP XBRL Taxonomy from one position to another position; should the concept be extended because the meaning of the concept has changed?

So, the answer to this one is on the tricky side.  I don't thing filers are allowed to randomly move US GAAP XBRL Taxonomy concepts where ever they want. Further, when some things like property, plant and equipment and long-term debt and net cash flows have different relationships because of the items which make up the total include or exclude specific line items; the US GAAP XBRL Taxonomy provides alternative concepts to use.

I won't specuate on how this will be resolved (but I do have my opinion).  But this is certainly ambigous with no one clear cut answer obviously being the right answer.

What is very clear is that consistency is a very good thing. 

Here are a couple of handy queries for getting information from a component and then for the line items within the component.  (The best way to use these queries is to run them and look at the results or if you want to see the query, right click the link and copy/paste it into a text editor.)

This query gets all the text blocks within a network. You get all 10 of the text blocks within that network.  If you only want one of the text blocks, then you use this query.  Or you can get another text block from the set of ten with this query.

You can do the same thing for statements.

So here is a query of an income statement.  And here is a query of ONE LINE ITEM, revenues, from that income statement.  Same thing for a different line item, net income (loss).

You can do that for any digital financial report for any public company in the SECXBRL.info repository.  Complete documentation is here.  If you come up with interesting queries, please let me know.

The paper The use of Business Rules with Workflow Systems by Anthony Rowe, Susie Stephens, and Yike Guo points out that there are two classes business workflow systems, process-centric and data-centric, and that business rules should be able to express rules that operate in both worlds.

• Process-centric workflows generally use business rules at the workflow task level to manage workflow tasks.
• Data-centric workflows generally use business rules within workflows to make decisions about individual items of data.

The authors point out that this is not an "either/or" situation, but rather leveraging both workflow models in the design and execution of workflows is the way to go:

"By combining the two different workflow models, business rules can be undertaken at both the task level for automating different decisions and at the data level for implementing filters over the data. Business rules can also be used to define operational features of a workflow, such as what to do when a specific task fails."