Digital Financial Reporting

Making sure that your SEC XBRL filing is correct is not a matter of technical wizardry, but rather understanding the types of things which can go wrong. If you understand the types of things which can go wrong you can be proactive and make sure those things don't go wrong and if they do be sure to detect the error.

Creating an SEC XBRL filing is a lot like figuring out a Sudoku puzzle.  If you understand Sudoku than you know that there are not multiple answers to a puzzle, there is one answer.  This is also the case for an SEC XBRL filing: there is really only one right answer given a set of financial information one is trying to disclose.  If you think about it that makes sense.  Would you really want there to be more than one right answer?  How useful would that be.

While the SEC does not require independent audits of XBRL filings submitted to them currently, you still need to have internal processes and checks on your work to be sure what you are creating is correct. A step beyond this is having your internal audit function check to be sure your processes are good ones and that they are yielding quality results.  Further, it is just a matter of time before the SEC will require XBRL filings to be audited by an independent accountant.  While the accounting/auditing profession works to figure out and formalize what these independent audits of XBRL will look like, being ignorant of what is required to output a quality product is really not a good idea.

Accountants like checklists. We use checklists when we issue a financial statement, a disclosure checklist.  Eventually these disclosure checklists will incorporate the things you need to do to be sure your XBRL filings are correct.  Here is a list of many of the types of the questions you should be asking yourself and ways to detect these types of mistakes so they can be corrected before you press that "Submit" button and your work goes to the SEC and is available for the entire world to see.

• Do I have the right taxonomy? If you find yourself adding a lot of concepts and relations you may want to spend a little more time seeking out additional taxonomy components you might have missed.
• Do I have the right industry concepts?(if you are in a specialized industry) While some specialized industries such as banking and insurance have specific entry points to the US GAAP taxonomy, other industry specific concepts are spread throughout the taxonomy and can be hard to locate.  Again, if it seems like concepts and relations probably should exist but you did not find them, they probably do exist.  You just need to spend more time looking.  Using a taxonomy viewer search capabilities (in a good tool) you can generally find concepts by searching for them.  Be aware that they may not be called exactly what you would call them so your searches of the taxonomy have to be pretty creative these days.  Eventually someone will create a nice synonym database which will make this process easier.
• Am I extending the taxonomy correctly?  Did you build your [Table]s correctly? Did you build your [Roll Forward]s correctly?  The US GAAP Taxonomy is not random or arbitrary.  It was built in a particular way.  You need to understand how things are built so that you can build your extensions so that they are consistent with the way the US GAAP Taxonomy is constructed.  Eventually software will provide more help, today this is more challenging.  Some taxonomy creation tools provide validation (information model validation) which helps you detect inconsistencies so you can correct them.
• Am  I allowed to extend the taxonomy in a specific location?  An extreme example will show what is meant here.  It would make no sense to add concepts on the balance sheet which were siblings to "Assets" or "Liabilities" or "Equity".  What other broad categories are there on the balance sheet?  As you get lower and lower into the details it becomes more challenging to understand if you really should be extending a taxonomy in a specific area.
• Should I create a new taxonomy concept?  When is it appropriate to create a new taxonomy concept?  For example, a minority of filers (3 of about 500) created a concept "Net Changes in Cash and Cash Equivalents" which is the sum of all changes in cash on the statement of cash flows.  The other 497 did not.  Those numbers make it seemly hard to justify an entity creating a new concept rather than using an existing concept.  In the case of net changes in cash and cash equivalents it is rather obvious that a new concept should not have been created.  In other cases it is not quite as obvious.  Judgement is needed and knowledge of how XBRL works is necessary to help you pick the appropriate course of action.
• Are all the XBRL instance fact values associated with the correct XBRL taxonomy concepts?  Should you be using the concept "Cash" or "Cash and Short Term Investments" or "Cash and Cash Equivalents" or some other version of cash from the US GAAP Taxonomy?  Was some sort of tagging mistake made?  Many types of these errors can be detected by a computation not adding up correctly.  Other tagging mistakes will not be detected using the validation of computations.  Understanding XBRL enough to understand which approach to use to detecting tagging errors is important to know.
• Are all the XBRL instance fact values associated with the correct context?(i.e. entity, entity segment, period, and so forth)  This is similar to detecting concept tagging errors.  Again, the validation of computations will help detect this type of error in many but not all cases.
• Are all numeric XBRL instance fact values associated with the correct units? (i.e. dollars, Euros, shares, pure and so forth) This is likewise similar to detecting concept tagging errors. 
• Are all numeric XBRL instance fact values associated with the appropriate decimal value? (i.e. rounded to thousands, millions, billions, or not rounded at all) This is likewise similar to detecting concept tagging errors. 
• Are all numeric XBRL instance fact values properly associated with other XBRL instance fact values?(i.e. are the computations correct) Clearly all your numbers should add up properly where they should add up.  This can be similar to detecting tagging errors, if you have the computation expressed in your business rules.  Realize that the US GAAP Taxonomy does not express all computations.  This does not mean that your numbers don't need to add up.  Just like in your printed financial it can be embarrassing when your "Increase (Decrease) in Receivables" on your case flow statement does not tie to the actual change in receivables on your balance sheet, the same relations need to work in your XBRL filing.  One big missing set of computations are those for [Roll Forward] type relations.  XBRL US does not publish those computations.  They are easy enough to auto-generate from the XBRL taxonomy.  You need to do that to create the XBRL Formulas (the best way) or some other means of verifying the accuracy of your XBRL instance fact values.
• Is the polarity of numeric fact values correct?(i.e. did you enter a number as a positive when it should have been entered as a negative) People tend to confuse how a number is presented and how it should be put into the XBRL instance: as a positive or as a negative.  Different people have different ideas on what should be shown as a positive and what should be shown as a negative on a financial statement.  For comparability purposes, XBRL had to get creators of financial information to agree.  That is why XBRL is not about how the number is presented, it is about communicating clearly whether something should be added or subtracted.  You can present it in your HTML or paper filing however you like.  Once you realize this, it is quite easy to test the polarity of a number: via the computation validation.  If a number is not involved in any computations, being sure the polarity is correct can be more challenging, it even might be a task which needs to be checked manually.
• Does the XBRL instance match the HTML or other version of the financial statements?While a short term problem which will exist when companies have to file both HTML and XBRL, you do need to be sure that what you are saying in your HTML and XBRL is the same thing.  Many companies are starting to realize that you can generate the HTML from the XBRL information. This can make the process of reconciling the two formats substantially easier.  While you may not have to file the HTML with the SEC much longer, clearly you are going to want to look at the financial information expressed in that XBRL instance. Even a "geek" cannot look at an XBRL instance and determine if it is correct.  You will likely always use some sort of rendering to help you be sure your XBRL instance is properly created.  What you do need to understand is the process used to create the human readable format so you understand what could break and give you misleading results which would potentially result in an incorrect conclusion on your part.

Good use of things like XBRL Formula to create the business rules you need to enforce automated tests to be sure that, say, all your numbers add up and that your taxonomy is constructed appropriately can help you weave your XBRL Sudoku puzzle together correctly.  Understanding what can go wrong will help you understand the automated tests which you need to get things right.

All this seems like a great deal of work right now and it is because old processes are being used to generate a new type of output.  Besides, today an SEC filer submits both the old HTML or ASCII filings to the SEC along with the XBRL filings.  This will change.  The SEC has already stated publicly that the HTML/ASCII filings will eventually go away and the only submissions will be in XBRL.  That makes sense; why would you want to have to reconcile the HTML/ASCII filings to XBRL filings?

Eventually, when the current legacy processes are replaced with processes appropriate for creating financial statements using XBRL the process will not only be easier but the quality of the output will be improved and the effort and resources required to achieve the high level of quality will be significantly reduced.  This is because all those XBRL tags can be leveraged to allow computers to perform many, many more of the checks humans are required to perform today.  Generally accountants don't realize this yet but once this software starts showing up they will recognize the benefits.

For more information on what can go wrong in your SEC XBRL filings see this blog post.  It contains the top 10 errors which are found in SEC XBRL filings.  Also, realize that XBRL is XBRL, be it filed to the SEC or someone else.  Other XBRL is subject to the same types of errors as SEC filings.  The point is that this information is useful for XBRL submissions to any regulator, not just XBRL filings to the SEC.

The Federation of European Accountants (FEE) issued a policy statement on XBRL.  The six page policy statement titled eXtensible Business Reporting Language (XBRL) - The impact on accountants and auditors can be found here on the Web.

The policy statement goes further than anything else that I have seen coming out of the accounting community in saying that accountants are going to have to understand XBRL.  I agree with these statements.  The FEE states

There are two pillars to XBRL: an IT literacy pillar and a technical accounting and auditing pillar.  Organisations wishing to adopt XBRL will need to consider both pillars in establishing their training needs to ensure successful use of XBRL.

The FEE also points out key areas for training for accountants, identifying necessary skills required including:

• Select the appropriate taxonomy and download from the appropriate web page;
• Identify taxonomy elements required for any particular instance;
• Identify when a valid taxonomy extension is required;
• Create valid extensions; and
• Create valid instance documents in line with the appropriate specification or user guide.

If you are an accountant anywhere in the world, particularly if you practice in the area of public accounting, you definitely want to take a look at this policy statement as a clue of what is coming down the road in the world of accounting and financial reporting.