Wednesday, March 7, 2012

Xbrl 2.1 proposed changes

There are proposed changes that affect xbrl calculations involving facts that are precision/ decimals equal to zero http://www.xbrl.org/proposed-edited-recommendations

Saturday, January 29, 2011

Negated Labels

In this posting we will discuss Negated Labels, and Facts:

The following report contains debits with report formatting with parenthesis:

http://www.sec.gov/Archives/edgar/data/80424/000119312511017328/d10q.htm

Treasury stock (64,383)


Here is the XBRL filing; the value is reported as a positive value

http://www.sec.gov/Archives/edgar/data/80424/000119312511017328/pg-20101231.xml

64383000000



http://accountinginfo.com/study/fs/equity-01.htm

Treasury Stock
Treasury stock represents the company's common or preferred stock currently owned by the company it self, as a result of stock repurchase in the past.

The amount of treasury stock is subtracted from stockholders' equity.
Treasury stock (the amount of treasury stock is determined by either cost method or par value method.)


http://hitachidatainteractive.com/2009/12/22/xbrl-filings-for-the-sec-not-for-the-faint-of-heart-part-3/

Negated Facts
Another issue to contend 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 recognize 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 incorrect.

Saturday, May 15, 2010

Edgar Filers

Reading the preparers guide you may be mistaken on the entry points used for your filing.

You may well use the entry points presented by the XBRL.us US GAAP taxonomy, however you really only need to refer to the necessary non GAAP DEI schema, as well as the base US GAAP elements, roles, types schemas.

This was not covered in any detail that I saw in the guides.

Thursday, September 17, 2009

Edgar Filing Guide - XBRL

The following is the public test suite for the Edgar Filing Guide...

http://sec.gov/spotlight/xbrl/interactive_data_test_suite.shtml

How to add human readable names to XBRL Extended Links

Extended Links have a title attribute, by adding a human readable name to this attribute most applicatinos can display this attribute.

Why do this, the Extended Link URIs are not useful in User Interfaces, therefore having a human readable name is useful, hence using titles.

One draw back is that you can only have one label, and cannot have a language attribute.

An alternative way to do this is to add an ID on an extended link and have resources that refer to that id. This is not an XBRL standard, but is feasible. Not that any XBRL application support this.

Friday, September 11, 2009

XBRL Filings

XBRL is flexable enough to allow users to report data, verify its consistency. The extensibility however is a challenge to support when creating a storage solution.

Finding a balance between infinite flexability and creating storage in a RDMS is a challenge.

How do you deal with facts reported more than once?

How do you deal with facts reported but in different documents?

Do different filers have the same presentation?

Thoughts?

Friday, May 1, 2009