Digital Financial Reporting

The FEI published a survey, SEC Reporting and the Impact of XBRL: 2012 Survey, which I believe exposes an opportunity for CPAs and other accountants who truly understand how to articulate financial information using XBRL and to software vendors who have products usable by accountants and other business users involved in the process of creating SEC XBRL financial filings.

The following are the highlights of the FEI survey:

• Companies across the board expect to take greater responsibility for their XBRL filings, with the percentage of respondents not planning to outsource XBRL at all over the next year increasing and the respondents planning to use full outsourcing over the next year decreasing.
• Respondents across the board projected increasing both the size of their XBRL team as well as the level of internal XBRL competency.
• XBRL is not expected to delay reporting calendars. The vast majority of respondents expect to file in line with the time frame of previous filings or faster.
• XBRL was the most often mentioned SEC reporting bottleneck.
• The biggest concern raised regarding XBRL compliance was to question the cost - benefit proposition of the XBRL mandate.

Notice the terms "bottleneck" and "cost - benefit proposition".  Another opportunity for CPAs and other accountants with the appropriate knowledge of how to express financial information properly using XBRL is to help software vendors make their software usable by these business users.

With all the SEC XBRL financial information of public companies available over the Internet and with the quality of software for business users such as accountants to understand SEC XBRL financial filings improving, it will be very easy to differentiate between high quality and poor quality SEC XBRL financial filings.

With the knowledge of the buyers of software and services is increasing, it will only get harder and harder for those who really are not qualified to express financial information using XBRL well to hide amongst the herd.

Clearly additional pressure will be applied by the SEC who has been complaining about XBRL financial filing quality.

With digital financial reporting being not only inevitable, but imminent; taking the plunge into digital financial reporting seems wise to me.  What will you chose?

Web Filingshas released a free tool for having a look at XBRL taxonomies used for SEC XBRL filings.  You can find the tool here.

Here are two screen shots of the tool in action. I am using it to compare how different filers build their company extension taxonomies.

• Comparison of balance sheets 1: This PNG shows a comparison of the concept "Assets" on the balance sheets of six SEC XBRL filers.  Notice how each of the six companies used the same concept to organize their balance sheet.
• Comparison of balance sheets 2: This PNG shows a comparison of the [Axis] used on the balance sheet for six SEC XBRL filers. All six used the Legal Entity [Axis] on the balance sheet.

There are other things you can do with the tool such as browse the released version of the US GAAP Taxonomy and search for concepts.

Nice work Web Filings!  I look forward to other tools like this becoming available to help business users get the most out of what XBRL has to offer.  Imagine being able to compare the actual filings themselves in this manner.

If you become aware of a good tool, please make me aware of it.

The list of SEC XBRL filings which has received my 5 Star Rating has now reached 92!

You can see the list of filings receiving my 5 Star Rating below and you can go to this web page to see the detail of the analysis. (Recall that last week I posted a blog entry stating that I had found 24 SEC XBRL filings to which I could assign a 5 Star Rating.)

Criteria for Receiving a 5 Star Rating

The following is a summary of the criteria for receiving my 5 Star Rating (For more details see this blog post):

1. No XML, XBRL, or EFM syntax errors. This is indicated by having a "0" in Column 8 which is marked with "E" under "Edgar Filing Manual" on the XBRL Cloud validation report.
2. Calculation consistent.  (i.e. no calculation inconsistencies reported during XBRL validation)
3. Pass one basic business rule.  One business rule must be passed, basically checking for the existence of net cash flows and the reconciliation of the beginning and ending balance of cash.
4. [Table]s must be correctly created. The [Table] structure must follow the US GAAP Taxonomy Architecture as specified.
5. Extension concepts reasonable.  The extension concepts added must appear reasonable.  This is admittedly subjective, it would take a blatant error to be dinged for this, if everything else was satisfied.

Remember that this set of criteria is just a basic set of minimal criteria which an SEC XBRL filing should, in my view, meet at this stage of the game.  There are many other things which need to be considered in order to be considered a high quality filing.  See this blog post for more information.  This blog post relates to things accountants might need to consider.

Summary of Filings Analyzed and Analysis

The SEC XBRL filings which I analyzed were 10-K's and 10-Q's submitted between January12, 2010 and March 2, 2010.  Here is summary information about that set of filings.

• There were a total of 422 filings in this set.  Of that total, 92 received a 5 Star Rating, which is 22%.
• Of the 422 filings, 401 of them (95%) had no XML, XBRL, or EFM errors reported (criteria 1). So only 21 had these types of errors.
• Of the 422 filings, 317 of them (75%) had no calculation inconsistencies. So only 105 had calculation inconsistencies.
• Of the 422 filings, 319 of them (75%) modeled [Table]s correctly.  So only 84 had [Table] modeling issues.
• Because checking the business rules and extension concepts is labor intensive, I only checked filings which passed the other three tests for these criteria.  As such, I don't have data for the how the complete set of filings did against these two criteria.

While there were many filings doing well against one of the critera above, only 92 SEC XBRL filings did well against all 5 criteria.  Kudos to those 92 SEC XBRL filers!

Browsing These Filings

You can see the list of filings above, or you can view the filings by criteria here (these work best with a big monitor):

• Focusing on Errors
• Focusing on Calculations
• Focusing on Business Rule
• Focusing on [Table]s
• Focusing on Extension Concepts
• Filer Taxonomy
• Mashup of All Information by Filer

List of 92 SEC XBRL Filings Receiving a 5 Star Rating

This is the list of the names of companies which received my 5 Star Rating: 

• AES CORP
• Aflac Incorporated
• AKAMAI TECHNOLOGIES INC
• ALCOA INC
• ALLERGAN INC
• ALTRIA GROUP, INC.
• AMEDISYS INC
• AMEREN CORP
• AMERICAN EXPRESS CO
• AMGEN INC
• ANADARKO PETROLEUM CORP
• AVON PRODUCTS INC
• BANK OF AMERICA CORP /DE/
• BARD C R INC /NJ/
• BB&T CORP
• BOEING CO
• BOSTON PROPERTIES INC
• BOSTON PROPERTIES LTD PARTNERSHIP
• BRISTOL MYERS SQUIBB CO
• BUCYRUS INTERNATIONAL INC
• C H ROBINSON WORLDWIDE INC
• CARDINAL HEALTH INC
• CISCO SYSTEMS INC
• CITRIX SYSTEMS INC
• CLIFFS NATURAL RESOURCES INC.
• CNX GAS CORP
• COGNIZANT TECHNOLOGY SOLUTIONS CORP
• CONSOL Energy Inc
• DANAHER CORP /DE/
• DAVITA INC
• DUKE ENERGY CORP
• EBAY INC
• ELECTRONIC ARTS INC.
• EMC CORP
• ENERGEN CORP
• EQUITY RESIDENTIAL
• ERP OPERATING LTD PARTNERSHIP
• EXPEDITORS INTERNATIONAL OF WASHINGTON INC
• EXXON MOBIL CORP
• FASTENAL CO
• FLIR SYSTEMS INC
• FORTUNE BRANDS INC
• GENERAL DYNAMICS CORP
• GENWORTH FINANCIAL INC
• GILEAD SCIENCES INC
• Google Inc.
• HOLOGIC INC
• HOST HOTELS & RESORTS, INC.
• HUMANA INC
• IMPERIAL OIL LTD
• Ingersoll-Rand plc
• INTERCONTINENTALEXCHANGE INC
• INTERNATIONAL PAPER CO /NEW/
• INTUITIVE SURGICAL INC
• KELLOGG CO
• KIMBERLY CLARK CORP
• KRAFT FOODS INC
• LOCKHEED MARTIN CORP
• MARSH & MCLENNAN COMPANIES, INC.
• MATTEL INC /DE/
• MCDERMOTT INTERNATIONAL INC
• MEMC ELECTRONIC MATERIALS INC
• NETFLIX INC
• NEW YORK COMMUNITY BANCORP INC
• NUCOR CORP
• OPEN TEXT CORP
• PARKER HANNIFIN CORP
• Philip Morris International Inc.
• PLAINS EXPLORATION & PRODUCTION CO
• PPG INDUSTRIES INC
• PRAXAIR INC
• PRECISION CASTPARTS CORP
• PUBLIC SERVICE ENTERPRISE GROUP INC
• QWEST COMMUNICATIONS INTERNATIONAL INC
• REGIONS FINANCIAL CORP
• RR Donnelley & Sons Co
• SCHWAB CHARLES CORP
• SIGMA ALDRICH CORP
• Spectra Energy Corp.
• SPRINT NEXTEL CORP
• STRYKER CORP
• SUNTRUST BANKS INC
• TORCHMARK CORP
• UNITED STATES STEEL CORP
• UNITEDHEALTH GROUP INC
• Unum Group
• VARIAN MEDICAL SYSTEMS INC
• WALT DISNEY CO/
• WELLPOINT, INC
• WINDSTREAM CORP
• XTO ENERGY INC
• YAHOO INC

The following is my list of the top ten things which someone using XBRL information should keep in the forefront of their mind.  This list might be looked at as the biggest challenges one needs to overcome when using SEC XBRL information.  These are all decisions which the domain stakeholders of financial reporting needs to make in order to get XBRL to work how they want it to work.  The best way to make these decisions is to understand how XBRL works for SEC XBRL flings today, what the alternatives are, and what alternative best fits your stakeholder group needs.

My definition of user of SEC XBRL information would include analysts, investors, regulators, data aggregators, and software developers building software for these types of users.

Keep something in the back of your mind as you take a look at this list.  Financial reporting practices used today were developed in an era where paper was the medium for distributing information.  There may have been minor inconsistencies in certain financial reporting practices, but these minor inconsistencies where easily overcome by the humans reading the financial reports.  In a new era where elimination of many of the mundane tasks such as re-keying information is possible, these minor inconsistencies become insurmountable issues as we try and get computers to do these mundane tasks.  Processes must be reliable.  This new electronic medium, XBRL, is different than the paper-based medium of the past.  Certain changes can make achieving some desired characteristics significantly easier.  These historical choices should be reconsidered as to not hold back the possibilities offered by the new mediums.

To understand what you want it is best to understand your options.  The options when it comes to XBRL are the characteristics of how XBRL works.  These are business domain stakeholder decisions.  Knowledge can give you the power to make a case for what your stakeholder group needs from XBRL.

One final thing to consider.  Keep in mind how computers "think".  This thought experiment can help you understand how to look at financial information.  There is a simple goal here as I see it: to make XBRL work the best it can.  Of course "best it can" is subjective.  Are certain changes in the interest of financial reporting?  Maybe they are, maybe they are not.  That is not for me to say.  All I am doing here is providing information so that the right discussion takes place.  All financial reporting domain stakeholders should push for what they want from the strong position of knowing how XBRL actually works.

In looking at SEC XBRL filings, this is what I see:

1. Accounting inconsistencies or errors: This analysis details my point here.  I don't want to make any judgements, I am just delivering a message.  Is it an accounting error to have two different ways of computing net change in cash, as pointed out by this set of SEC XBRL filings?  The answer could be "yes" or it could be "no".  That is not the point.  The point is this.  If the vast majority do it one way, why can't everyone do it the same way?  What is so unique for those 8 compaines that they need to calculate the value differently?  Of course you can see that if there are two ways, adjustments need to be made to convert one approach to the other approach when analysis uses these numbers.  Should analysts really need to do this?  What is the reason for not only using one way?  This issue is not just about this area of the XBRL taxonomy, there are other areas.  The fact patterns are different for different areas of the US GAAP taxonomy, but what rule do you apply to determine whether alternatives in different areas are helpful or hurtful?
2. Filers adding concepts unnecessarily: When should SEC XBRL filers add new concepts in their extension taxonomies?  If you look at the SEC XBRL filings being submitted, there are many inconsistencies in where and when concepts are added.  This analysis of the statement of cash flows shows many of the inconsistencies in this area, the same sort of issues exist in other areas of filings also. Unnecessarily added concepts can may querying the information significantly more challenging. What exactly the rule which determines if a concept should be added and who enforces that rule?
3. Filers not following the US GAAP Taxonomy Information Model: By information model I mean things such as the [Table] structure, the [Roll Forward] structure, and other such structures in the US GAAP Taxonomy.  The US GAAP Taxonomy is very consistent in how it uses, for example, [Table]s and [Roll Forward].  But company extensions to the US GAAP Taxonomy are not.  See this analysis of how filers are constructing [Table]s.  The reason is that there are no validation rules which point out inconsistencies when SEC XBRL filings are submitted. Is this randomness beneficial, or should the free-for-all be constrained in order to realize better comparability across SEC XBRL filings?
4. Locating networks to make comparisons can be challenging: SEC XBRL filings each use their own set of networks to identify sections of the financial filing such as the balance sheet, income statement, or a specific disclosure.  See this analysis for more information.  Now, you may look at the filings and say, "Hey, this is no problem, I can read the network descriptions just fine."  But can a computer read the networks and then make a comparison across multiple companies, say comparing the balance sheets of each company?  How will a computer know WHICH network to grab?  A computer might be able to determine from the concepts within the network what the network is to a degree.  Another way of understanding this is to say that if filings use common structures, in this case network roles, to identify pieces of a financial filing, finding those pieces and comparing them would be more reliable and certainly easier to program. Is it best if everyone uses different network identifiers or would it be better if specific network identifiers were used for common things such as "balance sheet", "income statement", certain specific disclosures in order to enhance cross filer comparability?  Or, are networks meaningless, and it is really the [Table] which provides the comparison point?
5. Inconsistent use of concepts and relations at "higher levels": Financial reporting in the US is dynamic meaning that financial report creators can create reports which reflect their unique organizations.  Basically, creating a US GAAP financial report is not filling out a form, nor should it be.  The dynamic nature makes US financial reporting better.  But, should dynamic mean "free-for-all"? SEC XBRL filings are many times, at least in my view, changing concepts and relations at high levels where changes probably should never occur.  Case in point is the cash flow statement, this analysis provides information about how SEC XBRL flings are changing concepts such as "us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease".  Another way to look at this is that if the higher level concepts and relations were more solid with extension points more clearly specified, then US financial reporting keeps it's dynamic nature, provides areas where extensions are quite reasonable, and avoids a free-for-all which a computer will simply not be able to deal with when trying to analyze SEC XBRL filings.  For example, a balance sheet has "Assets", "Liabilities" and "Equity" (and sometimes temporary equity).  Do you really want filers changing those high levels?  Why?  Be aware that they can at this point.
6. Calculation inconsistencies and unexpressed computations: Many SEC XBRL flings have calculations which don't properly "foot and cross-cast".  See this analysis which discusses this in more detail.  There are those who believe that calculation inconsistencies cannot be made to go away.  I personally don't buy that and that has not been my experience.  Think about this though.  Would you want to use a financial report where things don't add up?  Would you trust the information?  How would you distinguish something which does not add up because of an error and something which is not supposed to add up?  Further, many times there are important computations which are not articulated by the SEC XBRL filing.  These should be explicitly articulated for two reasons in my personal view: so the information creator knows that things add up and so that the consumer of the information knows what is supposed to add up and how.  What should the rules be for computations?
7. Improper modeling of information characteristics: People have different interpretations about what XBRL Dimensions provides in the US GAAP taxonomy and therefore they are used in different ways by different users.  Even the US GAAP Taxonomy itself has different interpretations, sometimes using XBRL Dimensions and sometimes not to model information.  People will eventually realize that consistently and correctly using XBRL Dimensions makes easier. There are four major classes of things to realize when trying to interpret the US GAAP Taxonomy relative to XBRL Dimensions: (a) Confusing and inconsistent: When SEC XBRL filers create their extension taxonomies their presentation relations and definition relations can be inconsistent, usually the definition linkbase is missing things.  This impacts how the dimensions work because the definition linkbase really controls the workings of the dimensions, it is not the presentation linkbase.  This can occur because there are two ways of articulating the same information: the presentation linkbase and the definition linkbase. The solution to this issue is have only one way of articulating the information model, not two.  (b) Calculations don't work: Improperly modeled information can result in computations which don't add up correctly or you may struggle to figure out exactly how things add up.  For example, consider this calculation validation report which shows that the balance sheet does not add up (look for the red in the last column on the right).  If you look at all of these calculation reports (use the links to the calculation reports on the right hand side of the page), you can see that each of these SEC filers was able to get its balance sheet to calculate properly. (c) Drill down: A financial statement generally consists of summarized information in the primary financial statements such as the balance sheet and detailed information from many of the line items on the primary financial statements within the disclosures.  If the dimensional information is created correctly, "drilling down" from the primary financial statements to details in the disclosures is easy to do.  If they are not constructed correctly, a computer cannot correctly understand the links and therefore cannot possibly navigate between the primary financial statements and the details in the disclosures. (d) Mixing dimensional and non-dimensional information: Mixing XBRL Dimensional and non-dimensional information simply will not work correctly.  For example, XBRL Formula has two aspect models: dimensional and non-dimensional.  People will figure these things out when software improves, but just be aware if these issues.
8. Irregular shaped hypercubes: Information reported in an SEC XBRL filing has different dimensions. For example, a consolidated balance sheet summarizes information for the consolidated entity for two period of time, the current period and the prior period.  Whereas the segment breakdown of the balance sheet information has a different shape because it has different dimensions, usually one period and the breakdown is by business segment.  The two dimensional nature of paper limits how certain information, which may have three or more dimensions, can be presented.  Mismatches between the dimensions of information (i.e. the shape of the information) can make information harder to view.  This situation can be rectified simply by reorganizing the information into the proper [Table]s. Exacerbating this situation even more is the fact that not all information is broken down into [Table]s and many of the "chunks" of information in the US GAAP Taxonomy are quite large.  It might be better to have many smaller chunks of information which fit together, rather than the huge pieces which exist currently in the US GAAP Taxonomy.  How the US GAAP taxonomy is modeled is a choice which you can influence.
9. Extension concepts with poor descriptions:  Not providing quality descriptions for concepts added by an SEC XBRL filer makes it harder to understand the filing and harder to determine if the filer is creating a concept which actually already exists in the US GAAP Taxonomy.  Part of the point of XBRL is to make the meaning of things explicit, rather than have the user of the information guess.
10. Fiscal periods:  This is more of a nuisance than a significant issue, but it is something to be aware of.  As you know, not all companies report on a calendar year end.  When you manually go through paper reports and do comparisons, humans can pick the right periods to compare quite easily.  When you try and automate this process, it becomes a little more challenging.  There is no fiscal period information in SEC XBRL flings, so computer programs have to figure this out in automated processes.  Different software may do this in different ways. Analysts have been dealing with this for years so they are use to it.  But be aware, this can be automated reliably, if fiscal period information is included in the meta data.

Understanding this list of ten things will help you better understand the SEC XBRL filing information that you are working with.  It will also help you understand what you should expect and therefore request from those trying to figure out how to make XBRL work within the financial reporting supply chain.  The points are made not to be value judgments about what XBRL should be, rather they try and point out the spectrum of options which are possible.  It is up the the domain of financial reporting to make the decisions.  If you don't understand how things work and you are a stakeholder in the financial reporting supply chain, how are you going to know what to ask for from SEC XBRL filings?

The CFA Institute published a white paper, eXtensible Business Reporting Language: A Guide for Investors. They outline five guiding principles for what the CFA Institute wants to see from XBRL.  The CFA Institute's white paper articulates what their stakeholder group desires from XBRL. What does your stakeholder group want to see?  How is your stakeholder group making sure you get what you want?

The issues pointed out here, while specifically relating to the SEC XBRL filings, are actually issues which any system which uses XBRL's extensibilty features will need to address. For processes to be automated, the information must be unambiguous and the semantics must be clear and consistent.  Even when you have unambiguous information and clear and consistent semantics, you still have some choices as to how you want your system to operate.  Understanding these points helps business domain users make these choices.

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.