BLOG:  Digital Financial Reporting

This is a blog for information relating to digital financial reporting.  This blog is basically my "lab notebook" for experimenting and learning about XBRL-based digital financial reporting.  This is my brain storming platform.  This is where I think out loud (i.e. publicly) about digital financial reporting. This information is for innovators and early adopters who are ushering in a new era of accounting, reporting, auditing, and analysis in a digital environment.

Much of the information contained in this blog is synthasized, summarized, condensed, better organized and articulated in my book XBRL for Dummies and in the chapters of Intelligent XBRL-based Digital Financial Reporting. If you have any questions, feel free to contact me.

Entries from March 1, 2012 - March 31, 2012

SEC XBRL Financial Report Semantic Objects, Properties, and Relations

In order to better understand how to verify an SEC XBRL financial filing, or really any digital financial report for that matter, I put together a mind map using VUE which shows all of these semantic objects, the properties of these semantic objects, and the relations between these semantic objects and shows all this information visually.

You can see these semantic objects, their properties, and their relations to one another here in this PDF. (If you want the VUE file, contact me.)

That PDF may seem a little overwhelming to business users, but here is what it means and why this information is important:

  • Easier to use software.  Look closely at the terms used in that PDF.  Contrast those terms to the terms in this PDF which provides a partial overview(XBRL has WAY, WAY more goodies that I am showing) of the XBRL technical syntax. Which terms are easier to understand? Today, pretty much ever software vendor implemented their software for working with business reports along the lines of the XBRL technical syntax rather than financial reporting semantics.  That is why software is so difficult for business users to make use of. This will change when software vendors start building financial report creation tools which export XBRL, rather than XBRL technical syntax editors.
  • Easier to understand SEC XBRL financial filings.  Today it is extremely challenging for an accountant who creates an SEC XBRL financial filing to be sure they have done so correctly (expressing a true and fair representation of their entities financial information); it is even more challenging for management of that company to understand what they are signing off on; and third party verification of this information is challenging because the accountants performing this work have the same issues as the accountants who have created the information in the first place - they really don't understand XBRL or how it works.  Understanding the semantic objects, their properties, and their relation to other semantic objects will help accountants, who have to create and sign off that this information is expressed correctly, a "true and fair representation of the reporting entities financial information."
  • Higher quality SEC XBRL public company information.  Today the quality of all that SEC XBRL public company is not what it needs to be for robust, reliable, easy to use analysis software to do anything particularly useful with all that expensive information.  That will change.  As accountants, managers, and auditors understand the information (see previous bullet) the information they report will make more sense and will be more useful.
  • XBRL will become useful to accountants.  Once accountants realize how XBRL makes it easier to create financial reports (I know this is hard to see or believe given the state of things today) because computers can help them in that process; they will use totally different processes for creating their financial reports.  "Bolting on" XBRL to the end of an existing process, how does that make anything better, faster, or cheaper?
  • Verification tasks/steps for an SEC XBRL financial filing will become clearer and easier.  Few people that I talk to are happy with the guidance provided by the AICPA Statement of Position 09-1 for verifying an SEC XBRL financial filing. A paper points out issues with SOP 09-1.  The data quality of those filings shows that the SOP needs improving.  Neither the SOP nor the paper points out exactly what one needs to do to verify an SEC XBRL financial filing.  That PDF above with the semantic objects, their properties, and their relations provides a definitive, finite list of all the things which need to be verified. Those are all the important aspects of an SEC XBRL financial filing which need to be correct, complete, consistent, and accurate; something that the SOP and the paper agree are needed for proper verification. Given the right easy to use software, which enables the proper understanding by accountants and managers, which will lead to higher quality SEC XBRL financial filings because the verification tasks/steps are possible for accountants to effectively execute.

Basically, XBRL will become useful when it disapears into the background and accountants can be sure they are expressing their financial information correctly, completely, consistently, accurately, with fidelity, and with integrity.  Focusing on semantics makes this possible.

It is only a matter of time before some smart software vendor figure out how to make their software serve accountants rather than force accountants to struggle with the XBRL technical syntax.  How long before you think this kind of software will appear?

Posted on Saturday, March 24, 2012 at 07:04AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Financial Report Semantic Object Properties

This is my first draft of an articulation of all the properties of the financial report semantic objects.  (I think I am saying this correctly).  I used an approach which was used when I was working on the XBRL International Taxonomy Architecture working group; I did this using VUE (Visual Understanding Environment).  It is not UML, but it is UML-ish.  I am no expert at this but I think this is getting pretty close to where it needs to be.

Basically, what I did was leverage the business reporting logical model created and change it, expressing it in terms of the Financial Report Semantics and Dynamics Theory and my implementation of the SEC XBRL financial filing logical model.  You can get more information of both of those here on my blog.

More to come...comments welcomed.

Posted on Wednesday, March 21, 2012 at 01:29PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

End-user Computing: Business Users Building Software

I mentioned this a while back with GoAnimate and Scratch.  But this is WAY cooler!

AppBaker lets you build your own iPhone application and from what I read on their web site; building iPad software is soon to come.

I learned recently that there is actually a name for this sort of thing, end-user computing. Another term which describes this area is knowledge-based engineering.  Here is a definition of knowledge-based engineering:

KBE (knowledge-based engineering) can be defined as engineering on the basis of electronic knowledge models. Such knowledge models are the result of knowledge modeling that uses knowledge representation techniques to create the computer interpretable models.

Another way I have put this in the past is that XBRL has a "shape". Unlike native XML where you can go in any direction, XBRL provides "lines" that you have to stay within.  Now, if you look at XBRL from a technical syntax perspective this notion is still applicable but if you add a logical model layer on top of the XBRL technical syntax things get much more interesting.  Why?  Because while the XBRL technical syntax is too hard for business users to work with, the logical model significantly easy to work with.

My vision is that financial reporting would work a lot like TurboTax which is an easy to use interface for creating tax returns; except that "TurboFinancialReporting" would be different in that the user can "change the forms".  What I mean by that is that while TurboTax is easy enough to use, it can only be used for filling out US Tax Forms.  But what if you exposed the taxonomy (i.e. metadata) to the user and allowed the user to edit that metadata?  They remove the US Tax Form metadata, pop in the US GAAP Taxonomy metadata, and then you can create a financial report rather than a tax return.

Now, this may be too much of a leap for most people to make but from what I am seeing, I predect that this sort of application will exist within two years, maybe sooner.

Why would such an application, a "TurboFinancialReporting" application, be better than current approaches to creating financial reports?  Here is why:

  • With current approaches such as Microsoft Word, how much does the software application understand about financial reporting?  Zero. But TurboFinancialReporting does understand financial reporting.
  • With current approaches such as Microsoft Word, the software cannot help you be sure that the numbers add up correctly.  But TurboFinancialReporting can be sure that information adds up correctly and is otherwise complete, correct, consistent, accurate, has fidelity, and has integrity.
  • Reuse of the information is possible by analysts, regulators, or others without rekeying the information.
  • Basically many things can be better, cheaper, and faster.

And you don't even need to exchange information using the XBRL global standard format to derive value from this new approach to financial reporting which I call digital financial reporting.  But, you can and likely will.

Finally, this same approach which is being proven by the SEC's use of XBRL for financial reporting of public companies can be used for many other types of business reporting.  Just think of XBRL as a payload of numbers and text which a business user can create and maintain by themselves, without the IT department or any programmer ever getting involved.  Somewhat of a "semantic spreadsheet".

Posted on Sunday, March 18, 2012 at 06:54AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Pinterest: Interesting Interface, Great Way to Communicate Idea

This is an interesting interface: Pinterest.  Imagine a Pinterest-type interface into SEC filings.

Consider this organization of SEC filing information which lists filers by sector and then lets you look at the pieces of a filing for a filer. That is one way I chose to organize the information.  You decide what sector you want to look at, then you decide what company to look at, then you can view the pieces of the SEC filing for that company, here is one piece (Link 1). That is the first sector (Agricultural Production Crops); the first company (FRESH DEL MONTE PRODUCE INC); and the first piece of their financial report (Document information).  That is one path to that information.

Now, this is a different way to organize the information; by filing component.  If you go to that link, then go to the last item on the list, number 128 Document information (291 examples); click on that link and you get a list of companies,  go to item number 105 (or search on FRESH DEL MONTE PRODUCE INC); then click on that; you end up on this component of an SEC filing (Link 2).

Notice that those two components are the same, the first (Link 1) and second (Link 2).  They are two paths to the same information.

Why is that interesting?  Well, here is why.  Before XBRL, it would be impossible to link directly to a component of an SEC filing.  The best you could do is link to a document, such as this, the SEC Form 10-K for FRESH DEL MONTE PRODUCE INC from which that information came.  Granted, the document information is not that interesting; but I could do the same for the shareholders' equity disclosure metadata (i.e. taxonomy) or the information itself (i.e. fact table, I did not do a good job providing enough room to see the entire block of information, that was not necessarily my purpose and besides, I am not a very good programmer).  I could point to other component, any component, and I could even point to a human readable rendering of that component (but I did not provide that because generating such a rendering is beyond my programming skill, the SEC does not make the information available in this manner, and I have not found anyone else who provides information in this manner.)

What is the point of all this? I provided my two paths to the information (and there is actually a third path that I provided, a list of companies by company name that does NOT break the taxonomy down into pieces but rather shows all the pieces together); but what if you want some other path to the information?  Cool, no problem.  You can provide it.

Click on one of the links in Pintrest.  Here is one of some cute puppies.  Look at the URL, the ending is just a number.  Anyone can point to that link.  Anyone can organize whatever set of information they want, include information about cute puppies, and provide a link to that spot on the internet.

As the book Everything is Miscellaneous points out, there are many different ways you can organize information and no matter how well you plan an organization scheme; you will always want other organizations of the information.  Further, consider all this in the context of Tim Berners-Lee vision of "Linked Data".

This is the power of structured information which is organized in order to enable this type of functionality.  Poor organization gets in the way of this type of functionality.

In addition to the proper structuring of the information is the metadata, or data which explains the data.  In my three organizations, this is the metadata I am using to get you to where I want you to be: the company name, the sector of the company, and the component of the financial report which exist within the financial report. 

You have to reliably and accurately give meaning to a piece of information.  You get problems if, for example, information is grouped in unusable permutations/combinationsor if the pieces are not consistently and accurately identified at the appropriate level or if the metadata is not consistent enough.

This ability to organize digital information has huge ramifications for how things can and will be organized in the future.  If you are looking at SEC filings through the lens of the existing EDGAR system and existing means of distributing all that information and cannot grasp that these will soon be legacy; then you certainly will not be able to project what this means into the processes which impact your daily life. This understanding is critical.

Posted on Saturday, March 17, 2012 at 07:25AM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint

Analysis of 291 SEC Form 10-K XBRL Financial Filings

In my work to experiment with and further expand the Financial Report Semantics and Dynamics Theory, I analyzed a set of 291 SEC Form 10-K financial filings.  Below are the resources I used which might be helpful to other accountants trying to better understand these filings. (These were Form 10-K filings filed between December 1, 2011 and February 29, 2012.

  • Select set of 291 Form 10-K filings. This resource makes it easy to explore the taxonomy and fact tables of these 291 Form 10-K filings.
  • Components of select set of 291 Form 10-K filings.  This resource lets you look at the common components of each of the 291 Form 10-K filings.  For example, you can go to one place and look at each of the 291 balance sheets, income statements, cash flow statements, etc.  Great way to compare how different filers modeled similar components.
  • Select set of 291 Form 10-K Filers organized by Sector.  This is the same list of 291 Form 10-K filers, but here they are organized by sector. This makes it easier to compare filings for filers which are in the same sector.
  • Other resources.  Here are additional resources which have information about all 4416 Form 10-K and 10-Q filings.

What am I seeing?  Well, first off; the entire set of 4416 is consistent with other analysis work which I have done and continues to show the core financial report semantics relating to the existence of assets, liabilities and equity, equity, net income, and net cash flow; plus the balance sheet does, in fact, balance.

Now, for this analysis; what I did was take specific select filings which had all of these core semantics, which where "commercial and industrial companies" (i.e. they were not in any specific industry or had no specific activities which used industry/activity specific accounting policies such as banking, insurance, real estate, etc.), they had no other obvious errors which would make me believe that the filings were of significanly poor quality, and they had the following additional semantics:

  • Current assets and current liabilities were both reported (and found)
  • They may not have reported liabilities, but I was able to impute the value for liabilities (i.e. Liabilities and Equity - Equity = Liabilities)
  • Liabilities and equity - equity - redeemable noncontrolling interest or temporary equity - liabilities (or the value imputed for liabilities)Income (loss) from continuing operations before taxes was reported (and found)
  • Net cash flows from operating, investing, and financing activities were each reported (and found)
  • Net cash flow from operating activities + net cash flow from investing activities + Net cash flow from financing activities + exchange gains = Net cash flow
  • A concept for revenues was found
  • Income tax expense (benefit) was reported (and found)
  • I was able to properly impute income (loss) from continuing operations before taxes using the difference between net income (loss) and the income tax expense (benefit)

So basically, what I am saying is that if the filing was a 10-K (and was detailed-tagged), if I found all the core financial relationships to be true, and if I found all of these basic financial relationships above to all be true and if they worked correctly; then I used the filing for my analysis.

What was I looking at? Disclosures mainly.

What did I find?  Well first off, pretty much as expected; every filer reported "significant accounting policies".  Now, they did this in many different ways, but it was there for everyone in one form or another.

Something else I became aware of that had not occurred to me in the past is that information for all disclosures is reported twice: once in the [Text Block]s or marked "(Table)" in some filings and a second time in the "(Detail)".  Two things about the (Table) stuff which is really [Text Block]s and (Detail) stuff.  First, not all sections like this are consistently marked and the is no physical connection between the (Table) and the (Detail) for the same information.  Another way of saying this is that I personally wish these were marked consistently and that there was some "hook" which explicitly indicated that they went together.

Other sections which I found in almost 100% of the filings were things such as:

  • Earnings per share [Text Block]
  • Segment reporting [Text Block]
  • Quarterly financial information [Text Block]
  • Income tax disclosures [Text Block]
  • Debt disclosures [Text Block]
  • Commitments and contingencies [Text Block]
  • Goodwill and Intangible Assets Disclosure [Text Block]
  • Fair Value Disclosures [Text Block]
  • Pension and Other Postretirement Benefits Disclosure [Text Block]
  • Property, Plant, and Equipment Disclosures [Text Block]
  • Financial Instruments Disclosures [Text Block]
  • Stockholders' Equity Disclosures [Text Block]
  • Business Combinations Disclosures [Text Block]

There were other filings which had high number of occurrences but not 100%.  But there were, as was expected, lots of consistencies.  Now, the filers did not always use the same US GAAP Taxonomy concepts to express the same things, but just like "liabilities and stockholders' equity" and "liabilities and partner capital" and "liabilities and member equity" are all really "liabilities and equity"; there is lots and lots of nice consistency.

Further, if you found the [Text Block]s above; what do you think the probability is of the details of those items to likewise exist within the filing?  Pretty darn high.

Now, the disclosures work differently than the statements.  You pretty much always have a balance sheet, income statement, and cash flow statement.  What is on those statements can be much different; but what is rarely different are the fact that balance sheets exist and balance sheets have assets, liabilities and equity, equity, and the balance sheet balances.

While a few of the disclosures always exist, most of the disclosures exist only exist if specific line items exist in the statements of if a reporting entity has those items to disclose.  But, if the disclosure exists, it likewise has specific semantics.

What is my point? Semantics.  This stuff is not random.  There are reasons things show up or if they don't show up and if they do show up, other things must show up or not show up and the information ties together.  This is all like a financial reporting sudoku puzzle.

Posted on Friday, March 16, 2012 at 12:59PM by Registered CommenterCharlie in | CommentsPost a Comment | EmailEmail | PrintPrint