Digital Financial Reporting

The Journal of Accountancy published an article, The future is now: XBRL emerges as career niche, pointing out a few things such as:

• The “SERIOUS DEFICIENCY OF XBRL-KNOWLEDGEABLE PEOPLE”
• Merrill, one SEC filing agent, has on staff more CPAs than the vast majority of U.S. accounting firms (Merrill is one of the largest filing agents, but there are many other filing agents
• XBRL is a global phenomenon
• “This is a real global opportunity for students to learn some skills that will be valued around the world.”

Something the article did not mention is that the last group of about 6,000 SEC public companies is moving from having to summary level creation of their SEC XBRL financial reports (most people call this block tagging) to having to provide all the details of the disclosures in the notes (detailed tagging).  There will be a lot of work done in June/July as most filers create their 10-Qs and then another big jump in December/January as filers report 10-Ks.

But I disagree that the opportunity about "XBRL".  The opportunity is more about digital financial reporting than it is about XBRL.  XBRL is simply an enabling technology. There are many, many things that you need to understand in order to satisfy the market need. Sure, XBRL is part of digital financial reporting but the operative word is "part".

This would be my list of necessary skills and how to get those skills:

1. Financial reporting/accounting. If you don't have financial reporting and accounting skills then you really can't be of much value in expressing financial information digitally using the XBRL medium.  Accountants, particularly certified public accountants and chartered accountants, understand what it takes to be at this level and have this necessary building block.  It is way easier to teach accountants the few additional things they need to work with digital financial reports effectively than it is to take a technical person who grasps the XBRL technical syntax and teach them accounting. You can do it and certain types of technical people can provide significant value, but it will always be through working with someone with accounting and financial reporting expertise.
2. Modeling-based reporting.  XBRL is a means of modeling business information.  Accountants today can use the medium of "paper and pencil" or "Microsoft Word" or Excel or HTML to express a financial report.  With digital financial reporting using the XBRL medium, you need to convey that same message using a different medium.  Just as your paper version (or the electronic version of that paper version in HTML, PDF, Word) needs to be a true and fair representation of your financial information which is complete, correct, consistent, accurate and which "foots and cross casts" and otherwise ticks and ties; so to does your digital financial report.  The paper version and the digital version of a financial report must convey the same message. Another term for digital financial reporting is model-based reporting.
3. Understanding the big picture.  The first thing you need to understand is how to convert your thinking from paper-based also called "document-based" or "presentation-based" reporting into model-based reporting or digital financial reporting.  The document Financial Report Semantics and Dynamics Theory does just that.  Once you understand the pieces of the model you have to understand how to be sure you are building your model correctly and expressing your financial information correctly using that model.  The document Guide to Verification of an SEC XBRL Financial Report can help you with that.
4. Get the right software.  This is the tricky task today, finding the right software.  Today every software application for creating something like an SEC XBRL financial report is an XBRL technical syntax editor.  As such, you have to understand the XBRL technical syntax.  This will change.  First, you need to understand the big picture (see above) so you know what to look for in software.  Basically, you need to become an educated buyer.  Second, you need to ask good questions of software vendors.  That will push software vendors to build the right software, financial report creation software rather than XBRL technical syntax editors.  A knowledgeable accountant will know this software when they see it; basically it will let them be successful and they will understand that they are being successful.  The Guide to Verification of an SEC XBRL Financial Report has a list of what accountants need from software, see the section "Role of Software". This is a more extensive but less refined list.
5. Get involved.  Once you get properly trained, get involved. One of my favorite quotes is "The best way to predict the future is to create it."  There is a huge need for accountants, financial analysts, and others to understand how to use this new medium, XBRL.  There are other pieces to the digital financial reporting puzzle such as RDF/OWL.  Few accountants truly understand how to put all the pieces of the puzzle together.  Don't become part of the problem by attacking this change half-cocked; get properlytrained and become part of the solution.  Some accountants will need to dig into the XBRL technical syntax deeply, but most will not.  Digital financial reporting or model-based reporting or however you want to refer to it will be part of the future.

Digital financial reporting is part of a much bigger trend, digital business reporting.  Some people call this "linked data" and prefer RDF/OWL as to XBRL, for example the Government Linked Data Working Group.  The Data Coalition is pushing the US Federal Government to adopt something like XBRL or maybe linked data.  Like the Journal of Accountancy article said, this is a global phenomenon.  If you want to understand the bigger picture, take a look at XBRL for Dummies which puts these pieces together for you.

If you invest wisely, your investment will pay good dividends and position you well for our digital future!

I had a number of requests for XML Schemas which explained the XML Infoset files which I use to work with XBRL.  Well, here is a first cut.  Note that I have had two different versions of terminology which I was using, I am transitioning to a new third format which syncs a bunch of things together.

These are DRAFT versions of the XML Schemas (I hope to have the final version within one to two months along with RDF/OWL ontologies which explains these and some other things:

• Model structure: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ModelStructure.xsd   (note that this was called the relations infoset)
• Fact table: http://xbrlsite.com/DigitalFinancialReporting/Schemas/FactTable.xsd
• Report elements: http://xbrlsite.com/DigitalFinancialReporting/Schemas/ReportElements.xsd
• Business rules: (to do)

If you want to understand this stuff more, please refer to the "Digital Financial Reporting" page of my blog.

While creating the disclosure templates I am putting together I noticed something and a question occurred to me.  How does someone creating an SEC XBRL financial report know which [Table] to use and which [Axis] to use when expressing their financial information and how is this "controlled" by the SEC?

This is what I mean.  Take a look at a rather straight forward disclosure, product warranty accrual. To create the product warranty accrual disclosure template, I started by looking at what other filers did.  I built a nifty application which helps me do this.  That application generates a nice little summary which shows the disclosure template and lets you look at the model structure of other SEC filers who modeled that same disclosure.  You can see this here.

If you go to the section "Similar SEC XBRL Filer Examples" you will see links to about 42 SEC filings which provided this disclosure.

Of those 42, the vast majority of filers modeled this disclosure without using any [Table] and therefore not providing any additional [Axis] beyond the reporting entity, period, and concept which they are required to provide for all facts provided. So here is one example of that approach.

Three of the filers added an additional characteristic, the "Legal Entity [Axis]".  Personally I prefer this approach because I prefer to (a) consistently use [Table]s for everything (as compared to using them for some things but not for others and (b) because it explicitly states that the legal entity characteristic is the consolidated entity (as opposed to having to imply this information).

However, of these three filings; two different [Table]s were used to disclose the product liability accrual roll forward:

• us-gaap:ScheduleOfGuaranteeObligationsTable
• us-gaap:ProductLiabilityContingencyTable
• us-gaap:ProductLiabilityContingencyTable

These two SEC XBRL financial filings used the Range [Axis].  That seems like it could be reasonable; however these two filers did not use any of the [Table]s above, rather they created their own [Table] and used that:

• flir:ScheduleOfAccruedLiabilitiesTable
• twi:ScheduleOfWarrantyTable

This filer used the Business Acquisition [Axis] and created their own [Table]:

• hlit:ScheduleOfProductWarrantyLiabilityTable

This filer used three different [Axis], two of which used the [Domain]:

• us-gaap:ProductLiabilityContingencyTable

This filer created its own [Table] and its own [Axis], whr:ProductWarrantyAndRecallAxis, and this does seem to make sense because they choose to break down the information into product recalls and normal product warranties; plus the do provide the total of these two categories which is comparable to all the other disclosures of this information:

• whr:ProductWarrantyAndRecallRollforwardTable:   

This SEC filer provides no explicit [Table] and packs the product warranty accrual together with a bunch of other disclosures as compared to focusing on that specific disclosure in this specific network.  (Approximately 50 percent of the total focus on one thing and the other 50 percent pack multiple pieces together):

• No table

Clearly this product warranty liability accrual roll forward is a rather basic and straight forward disclosure.  Consider these examples and consider the fact that there are I would guess perhaps approximately between say 1300 and maybe 3000 specific disclosure.

How do SEC XBRL financial report filers know

1. When two things should go into one network or be separated into two different networks,
2. What goes into a [Table] within a network or when separate [Table]s should be used,
3. Whether to use an existing [Table] or create their own explicit [Table],
4. And what [Axis] to put onto a [Table].

Here is another good example, document information.

Clearly it is highly unlikely that 8000 or so different SEC filers are going to figure this out themselves and consistently do the right thing without some sort of guidance.  SEC XBRL financial reports filed with the SEC bear this out.

The point here is that some sort of general guidance would be nice from the FASB, the SEC, and/or XBRL US.

The count of disclosure templates has now reached 50.  Also, I have provided a prototype software application which I build using Microsoft Excel which can be used both to explore the disclosure templates and to see how these templates can be integrated directly into a software application such as a business report creation application.

Screenshot of disclosure template explorer (prototype)

Pretty soon you won't need to use your imagination to see the utility of these disclosure templates in the process of creating a digital financial report such as an SEC XBRL financial report.

Again, thing of all those templates provided within Visio or PowerPoint.  For more information, see this blog post.