Digital Financial Reporting

Much of the work I have done over the past 14 or so years working to help create, understand, and effectively use XBRL for financial reporting is now summarized in one resource put together by Rene van Egmond and myself: Digital Financial Reporting: Using an XBRL-based Model.

This non-technical resource is for accountants, auditors, financial analysts, regulators, other business, software engineers, and others who are early adopters, thought leaders, entrepreneurs who desire to understand the moving pieces of digital financial reporting, a forthcoming paradigm which will highly likely replace many current financial reporting practices over the coming years.

Digital Financial Reporting: Using an XBRL-based Model provides a "map" which helps you navigate the many times murky waters which one generally runs across today when trying to make sense of XBRL, a primary enabler of digital financial reporting.  It provides information which helps you safely work with this new technology which is still evolving to create new cost effective, easier to use, yet robust, reliable, repeatable, predictable, scalable, secure, auditable, solutions and systems that work. This resource helps you cut through the noise and misinformation to grasp a well-grounded understanding of these new tools.

This resource helps you ask the right questions of software vendors who may, or may not, be taking an approach to implementing digital financial reporting in their products.  Following and then abandoning your approach does not have to be a hit or miss game because you did not understand all of the moving pieces of the equation.

Digital financial reporting, using global standard technical specifications such as the Extensible Business Reporting Language (XBRL), is fast becoming the new paradigm for financial reporting.  Digital financial reporting is part of a broader trend, digital business reporting in general.  While this new digital paradigm has not overtaken the current financial reporting paradigm, chances are that it will.  No one knows for sure exactly when, no one knows everything about what this change might mean.

Not understanding change has risk. To remain relevant as this new digital financial reporting paradigm unfolds, CPAs and other accountants need to adjust their thinking about how to appropriately modify financial reporting to keep up with the digital revolution. Gaining a proper understanding of this new tool is key to understand where and how to employ the tool.

Information in this document was accumulated over a period of about 14 years.  It represents, arguably, one of the best resources available today to understanding digital financial reporting.  The information and knowledge has been accumulated, synthesized, organized, and explained as best as possible given the current point in time of the evolution of XBRL, digital financial reporting, software available to business users, etc.

This is not a resource for the average business user, rather a resource for those putting together the pieces of what will become digital financial reporting. While any business user would benefit from this material, it more for those trying to employ, guide, influence, predict, or otherwise understand how digital financial reporting will unfold.

Rene and I hope you find this resource useful.  Comments, suggestions, ideas, or other feedback is welcomed.

The 9 metapatterns are distilled from the 30 business use cases. These are great examples of the pieces which work together to construct a digital financial report.

The comprehensive example takes each of the 30 business use cases, models them within one XBRL instance and XBRL taxonomy "system" to be sure the pieces of the system work together properly.

The reference implementation is similar to the comprehensive example except that the reference implementation is intended to comply with the SEC Edgar Filer Manual (EFM) and tests to be sure the inner workings of an SEC XBRL financial report are correct.  The 75 disclosure templates are similar to the business use cases.

So now my complete set of samples/examples have been updated to correct for all errors and other issues, adjust to the more precise terminology of the Financial Report Semantics and Dynamics Theory terminology, and all have been made available with XBRL Formula examples to both verify the modeling of the information and provide a base set of XBRL Formula examples.

All of these samples/examples are helpful to accountants in understanding how to make use of XBRL for financial reporting.  These samples/examples don't provide all the answers, but they certainly raise important questions as to what financial reporting use cases need to be addressed by any system endeavoring to employ XBRL.

I hope this information is helpful to others.  If you have ideas on how to make it more helpful, please send me your ideas. Or even better, help create the future of financial reporting by contributing to the Digital Financial Reporting Wiki.

I have distilled the business use cases I have encountered when modeling financial information into a set of metapatterns.  I have been maintaining these metapatterns for probably ten years. I have released an updated version of these metapatterns.  This newest version can be found here.

Each of these XBRL instances, XBRL taxonomies, and XBRL Formula files has been run through numerous XBRL processors to assure that they are of the highest quality possible. The documentation which explains the metapatterns has likewise been updated.

If you are trying to learn about XBRL, these small examples help you understand the nuances of working with XBRL.  Don't be fooled by the small sizes of these examples.  Each example is packed with information important to creating quality digital financial reports.

You can also get to these metapatterns from the Digital Financial Reporting Wiki page dedicated to these metapatterns.

Thank you to XBRL Cloud for the use of their tool for working with XBRL-based business reports used to both test the metapatterns and to provide screen shots used for the metapattern documentation.

In discussing something on the XBRL Formula Working Group list the following statement was made which I wish more people creating taxonomies and software vendors understood:

"the formulae are part of the model, not an afterthought"

Business rules expressed using the two global standard means available, XBRL calculations and XBRL Formula, are key to creating a quality XBRL taxonomy.  Business rules define/document important relations and other information.  Without this information, those using taxonomies to express financial information in an XBRL instance will have holes in their knowledge of how to properly model reported information and holes in their ability to verify that the information they expressed was correctly expressed.

Those creating XBRL instances can get around this problem by creating their own business rules, and in fact this is the only practical way to help them be sure that the information they are expressing has been correctly expressed.  But the down side is that each business user creating what amounts to their set of proprietary business rules does so in a vacuum on their own and there is no guarantee that any two business users will consistently express relations which should be consistent across all XBRL instances or classes of XBRL instances.

People will eventually figure this out.

Lack of business rules causes another problem: poor renderings.  These business rules contain information which could be leveraged to detect patterns and leverage those patterns to render the information contained within a financial report expressed using XBRL.  Software developers complain about how flat XBRL is.  Well, it is actually not the case that XBRL is flat.  The relations are just not expressed in  the XBRL Schema, they are expressed in other places.  These missing relations which would exist if the business rules were expressed using XBRL Formula would reveal how un-flat financial information is.

Don't understand what I am talking about or want more detailed information? Explore these disclosure templates.  Each has an XBRL taxonomy, XBRL instance, and business rules expressed using XBRL Formula and explained in the form of a brief narrative.  An example is below:

Well modeled XBRL taxonomies yield very good renderings.  Providing a complete set of business rules in the form of XBRL Formula forces good modeling.  The business rules expressed using XBRL Formula makes semantic information explicit, exposing it to software vendors, allowing the information to be leveraged by software.

Today, well modeled digital financial reports have these semantics.  People just are not seeing these semantics. Not business users or software developers.  But just because you cannot see the semantics does not mean that they do not exist.  These metapatterns prove that.

In my last post I discussed what I found when I analyzed the core financial integrity of the balance sheets of all 7,220 SEC XBRL filings for June, July, and August of 2012.

In this blog post I will discuss the core financial integrity of the top 100 SEC filers as determined by total assets of the filer.  This Excel spreadsheet has a summary of the data and findings.  This HTML page has the same information.

This is what I found:

• Only 3 core financial integrity semantics errors: Of these top 100 SEC filers, there are only three core financial integrity errors that I found: (1) HARTFORD FINANCIAL SERVICES GROUP INC/DE created an extension concept hig:NetIncreaseDecreaseInCash to express net cash flow; (2) HARTFORD LIFE INSURANCE CO created an extension concept hic:NetIncreaseDecreaseInCash to express net cash flow; (3) EXELON GENERATION CO LLC created an extension concept exc:LiabilitiesAndStockholdersEquityIncludingPortionAttributableToNoncontrollingInterestto express Total liabilities and shareholders' equity.  It would be hard to justify either of these three extensions given that 99% of all other filers used concepts from the US GAAP Taxonomy.
• Out of 900 data points, only 3 errors: So, out of a total 900 data points, there were only 3 errors!  That is great.  How did I get to 900? Well, there are 10 data points I was looking for: entity registrant name, document period end date, period start date, assets, liabilities and equity, liabilities, temporary equity, equity, net cash flow, net income. I did not really need one of them, entity registrant name.  So that leaves 9.  9 data points times 100 filers, that gives me 900.
• If total liabilities is not reported, causes data retrieval issues:  Not having total liabilities and I guess also total temporary equity reported causes problems extracting data because it is hard to know if you got the numbers correct.  What I mean is that it is almost certain that "assets" and "liabilities and equity" are correct because you can get the numbers and check to be sure that the numbers are the same (i.e. the balance sheet balances) and therefore you can be confident that you are working with the correct numbers.  But if (a) totals are not reported and (b) there is uncertainty as to which concepts a filer will be using on a fact; that leads to uncertainty as to whether you have actually retrieved the correct data or imputed values correctly.  What does this mean? Totals such as total liabilities, total temporary equity and total revenues should always be required to be reported because that allows those pulling out their data to be sure they are pulling out the RIGHT data.
• Balance sheets balance: The balance sheets balance for 100% of the top 100 SEC filers.
• Balance sheets exist: Balance sheets exist for 100% of the top 100 SEC filers.
• Root entities exist: Root entities exist for 100% of the top 100 SEC filers.  For example, while EXELON GENERATION CO LLC had 5 CIK numbers, there was exactly one root company into which the other entities flow. So, if you want to get the numbers, it is clear what entities to go after in the modeling of the information.
• No "audited" or "unaudited" members: None of these filers use an [Axis] to express that the information is audited or unaudited. (See the discussion about this in the prior post.)
• Document period end date always ties to balance sheet date for most current period: The document period end date always ties to the most current balance sheet date.
• Least confident in fact net income (loss): Of all these facts, I am least confident in the fact net income (loss).  There are two reasons for my lack of confidence.  First, there are so many different concepts filers could use for net income (loss).  Second, if filers use the wrong concept in the wrong order the wrong fact value will be retrieved.  This has to do with totals being provided.  I am looking for net income (loss) including the portion attributable to any noncontrolling interest and including any portion attributable to preferred stockholders.  It would be better, in my view, if one concept existed for this and if every filer used that one concept.

I am beginning to see automated use of this information rearing its head.  It is the little things that matter.  This is particularly true for smaller companies which want to extract information from the SEC XBRL public company information set.  Sure, big data aggregators can work through any data retrieval issues.  But, there will be a cost passed on to users for fixing these errors and therefore the cost of the data will be higher; perhaps much higher if there are lots of issues.  The fewer the issues, the more consistent the information provided, the easier it is to get the information, and therefore the cost of the information will be lower.

That is what I see.  How do you see it?