Peter Boritz is the architect and chief technical officer for Snappy Reports XBRL and can be reached via e-mail.

In Part 1 of this four-part post, I offered an overview of the problems associated with XBRL filings; in Part 2, I focused on those associated with the Interactive Financial Report Viewer. This post looks at filing issues in several areas, including taxonomy extensions, negated facts, nsistency checks, fact checking, filing path, per share information, and decimals.

Taxonomy Extensions

You should extend for new elements only if there is no existing element within the US-GAAP taxonomy that expresses the ncept you are wishing to apply. Your software should give you aess to documentation labels. These provide you with the information you need about what an element represents. You do not extend for a new element if there is an element within the US-GAAP taxonomy that expresses the same ncept. However, the standard label for an existing element may not match the terminology you use in your filing. In this case, map to the existing element, but create an extended label in your extension whose value displays the element using the terminology in your paper filing.

Negated Facts

Another issue to ntend with is the translation of data in a spreadsheet to the taxonomy and the translation of the taxonomy to the Previewer. Negated labels are part of this process. Spreadsheets typically use positive and negative numbers to represent debits and credits. For example, the equity section in the balance sheet within a spreadsheet would show equity facts as positive values minus a subtracted value for treasury stock. Treasury stock has a debit balance. When data facts are moved from a spreadsheet into the filing, the value for treasury stock arrives as a negative value. In actuality, it is a positive debit, so it must be multiplied by minus 1 to make sense out of it. The reverse holds true in the Previewer. It does not regnize offsetting debits and credits. All values in the equity section will be listed as the positive values that they are. Total equity will not properly add up, because it will include a difference of twice the value of treasury stock.

Treasury stock must therefore be negated. This is where you implement a negated label. A negated label is a label category. You set the preferred label in the presentation arc to point to a negated label. This tells the Previewer to multiply the debit value of treasury stock by minus 1 and display it as a negative.

You may be thinking, Why not keep the value for treasury stock as the minus value originally in the spreadsheet? Then you won’t need a negated label. Nice try, but your filing will be wrong. You will have a minus debit which is factually inrrect.

nsistency Checks

Filings must also pass a nsistency check. If you map in a value for a calculated element, such as total assets, a nsistency check uses the calculation linkbase to verify that the sum total of assets equals the value you mapped to it. If any provided total does not match its rresponding calculated total, an error will be generated.

Fact Checking

A requirement of any filing includes document entity information. This includes information about the mpany and the documents being filed. Information must be precise and case sensitive. Many questions are of the Yes/No type. These require a simple Yes or No (capital Y or capital N). Other questions (such as amendment flag) are true/false (small t or small f). If you get the case wrong, your filing fails. Your software must also be able to tell you what type of answer is required, and it needs to be able to validate your answers. These are text-based answers that require precision.

Some questions require selection from an enumerated list. This means the answer to a question must match an exact, case-sensitive list of words provided in the taxonomy, such as “large aelerated filer."

Filing Path

A taxonomy imports other taxonomies, which import still other taxonomies. The end result is a mplex hierarchy tree. The US-GAAP taxonomy is no different. Its import path is detailed and mplex. The US-GAAP taxonomy is rich in is its menu of elements and reports. A good software product will allow you to use all of these as a template for mpleting your filing. This means your software must path through the entire taxonomy in order to present you with all possible choices.

The SEC limits possible entry points for the US-GAAP taxonomy that can be declared within your filing. These are low level entry points that do not include reports. The process of mpleting a filing requires two pathways: 1) a mplex pathway that provides you aess to the mplete taxonomy for development purposes and 2) a clearly defined short path that the SEC will aept for filing purposes. Your software product should optimally support both.

Per Share Information

The SEC requires that per share information be defined as USD/shares. This is not defined in the US-GAAP taxonomy. Your filing must include a custom USD/shares type. A good software product will require you to provide basic information pertinent to your filing. It uses this information to nvert shares/item type to a custom USD/shares type in your instance. This process should be transparent to you. Minimizing the requirement of XBRL expertise is a key ingredient for any software product.

Decimals

The decimals attribute defines the degree of auracy for which a value can be nsidered material. Decimals are expressed as a negative number to the left of the decimal point. A value of -3 indicates thousands, -6 indicates millions. This would be declared as part of your filing information within your software product. Your software should use this information for the purpose of universally declaring the decimals attribute applicable to moary types. Per share information would have a decimals attribute of +2, meaning auracy can be relied upon two digits to the right of the decimal.