Contact us Contact Us Twitter LinkedIn
Paul Warren

Getting the sign right: Names, labels, and extensions

November 1, 2012 14:27 by

In my previous article, I demonstrated a simple technique for getting the correct sign when tagging a number in XBRL.  You may have noticed that I was somewhat casual with the notion of concepts having a “name”.  If you’re familiar with the details of XBRL, you’ll know that concepts have an “element name” and typically have at least one label.  Which of these was I referring to?

It is common practice in XBRL to use the standard label to give a concept a human readable name.  The purpose of a name is to unambiguously identify the meaning of a concept, and part of that meaning is the sign convention.  Making a profit and making a loss are two very different things, and if the name of the concept doesn’t make it clear which of these things the concept represents, then it’s not a very good name.

Examples of good names would include:

  • Profit
  • Profit/(Loss)
  • Increase in Accounts Receivable
  • Increase/(Decrease) in Accounts Receivable

Examples of bad names would include:

  • Profit or Loss
  • Change in Accounts Receivable

(the last one is border line – you might reasonably assume that a positive “change” is an increase, but it’s not explicit, and it’s not the sign convention that you’d expect to see used when displaying the concept on a Cash Flow statement)

A more unconventional name like “(Increase)/Decrease in Accounts Receivable” would also be acceptable but note that this is a different concept to one called “Increase/(Decrease) in Accounts Receivable”.

If the idea that a concept should have a name, and that that name should make it clear what the concept means is sounding a bit obvious, then good – it is obvious!

The problem with element names

A concept also needs to have an element name.  This serves a different purpose, which is to provide a unique identifier for the concept in an XML document.  Human readability is not the primary concern, although most implementations have chosen to use meaningful names (e.g. ProfitBeforeTax), rather than arbitrarily generated identifiers (e.g. “c1234”).

XML imposes some constraints on what constitutes a legal element name, most importantly disallowing spaces and most punctuation.  This means that we can’t simply use the standard label as an element name.  Most implementations have adopted an approach of taking the standard label, stripping out punctuation and removing some connective words such as “and”.  This approach is encouraged by FRTA, although an exact rule is not spelt out.

The approach has the unfortunate side effect of turning clear concept names (i.e. standard labels) into rather more ambiguous element names.  For example:

Concept Name         Element Name
Profit/(Loss) ProfitLoss
Increase/(Decrease) in Accounts Receivable IncreaseDecreaseInAccountsReceivable

Such names undermine the notion that XBRL concepts have a clear and unalterable meaning, and that that meaning includes the sign convention.  I suspect that elements such as the above have caused at least some of the confusion about how signs work in XBRL.

There is a very simple approach that would remove this confusion, but it’s not one that has made it into any published best practice that I am aware of, and that is to drop portions of the label that indicate the negated meaning when forming an element name.  For example:

Concept Name         Element Name
Profit/(Loss) Profit
Increase/(Decrease) in Accounts Receivable IncreaseInAccountsReceivable

If you’re uneasy about this approach, remember that the element is just a unique identifier.  It is not intended to be a descriptive label, so the fact that it does not spell out the meaning of a negative value is unimportant.

Extensions and the SEC

In my view, the confusion around signs in XBRL has been fuelled by a number of details of the implementation of XBRL at the SEC.  In the SEC implementation, preparers submit not only an instance document, but also an extension taxonomy allowing preparers to customise the taxonomy to better match their financial statements.

The SEC rule (33-9002) that enabled the use of XBRL for SEC Filings, requires filers to change the labels of standard concepts in the US GAAP taxonomy to match those on the company’s financial statements.  You can argue about whether that’s a good idea or not, but doing so opens the door to confusion around sign conventions.

The text of the rule gives the example of a company relabeling “Gross Profit” as “Gross Margin” as they are “definitionally the same”.  Seems harmless enough, but what about if the line item in your financial statements is “(Increase)/Decrease in Accounts Receivable”?  Should you change the standard label of the US-GAAP concept from “Increase/(Decrease) in Accounts Receivable” to “(Increase)/Decrease in Accounts Receivable”?  In my view doing so is absolutely unacceptable: an increase in accounts receivable is not the same as a decrease in accounts receivable, so changing the name of a concept in this way is very misleading.

The SEC system does provide an appropriate way to handle this situation (negating labels) but the guidance in the Edgar Filing Manual could be clearer.  Rule 6.11.1 instructs filers to “Assign a label of an element used in an instance the same text as the corresponding line item in the original HTML/ASCII document” but nowhere in this rule does it suggest that assigning a standard label that implies the opposite sign convention is unacceptable.  6.11.6 explains how to use negating labels, but does not explain what you should do with the standard label.

Proposed new best practice

I believe that much of the confusion around XBRL sign conventions could be removed by clearly documenting two pieces of best practice:

  1. The element name must reflect the meaning of a positive value reported against the concept.  If the element name is being formed from the standard label, parenthetical indications of negative meanings should be removed.  In other words, a concept called “Profit/(Loss)” should result in an element name of “Profit” not “ProfitLoss”.
  2. When using an extension taxonomy to re-label concepts, it is never acceptable for a standard label to change the meaning of a concept, and meaning includes sign.  For example, “Increase/(Decrease) in Accounts Receivable” must not be re-labelled as “(Increase)/Decrease in Accounts Receivable”.  The correct place for such a label is as a negated label.

 

In: Interactive Data, XBRL, XBRL Tech | Both comments and pings are currently closed. | Permanent Link

7 Responses to “Getting the sign right: Names, labels, and extensions”

  1. Herm Fischer says:

    Thanks for raising these important points. Some XBRL-US BPG contributors have discussed determination of when concepts have a greater probability of being wrong when negative in the fact element, depending on the circumstance of which face statememnt or kind of note the concept appears in, the use of negating preferredLabel (in presentation linkbase for such face statement), and even the wording in the definition (such as when provided by FASB).

    When mentioning ‘sign flipping’ associated with presentation for negated role preferred labels, it’s important to realize that these are needed for the case where ordinarily positive numbers from face statement schedules need to be sign-flipped when showing in a Cash Flow statement (so the negated label pertains to where the number is rendered, but not to allowing the fact element entry to be negative).

    All this gets muddled up when discussing inline XBRL, because the use of a preferredLabel negated label roles to sign flip in one schedule but not another is a presentation linkbase contrivance (or generic preferrend label, if not using presentation linkbase), but many folks looking forward to inline submissions (such as to such a future SEC possibility) also note that central Europe has dropped the presentation linkbase (and may assume that, after inline, presentation linkbase can go away too). However central-EU uses the table linkbase when dropping presentation linkbase, and doesn’t have the sign-flipping syntax and negative semantic issues of financial face statements, and maybe I’m getting a headache worrying and explaining and …

  2. Great posts, so far. I look forward to the next posts in the series.

    The first post describes when a negative value would be appropriate; “if in your answer you need to correct the question”.

    This second post says a good name could include:
    Profit
    Profit/(Loss)

    The second post goes further to say an element ID should be unambiguously “one-sided”
    Profit

    The goal: “to drop portions of the label that indicate the negated meaning”

    Would you say the standard label (not the element ID) should convey the “negated meaning”?

    If not, how can a user know whether it is allowable?

    Is that an important distinction?:
    the elements which should never be used with a negative value (aka “one-sided”)
    and those which might because “the answer would correct the question”(aka “two-sided”)

    If it is an important distinction; in particular this “two-sided” group of elements, how should XBRL convey they are “two-sided”?

    I believe it is an important distinction insofar as “negative values are a problem”
    I think many of us rely on the element name. If your best practice [one-sided element name] is adopted — then the standard label could also distinguish.
    I’ve often hoped there could be a more explicit property to distinguish. Maybe even something as basic as the datatype; “positiveMonetaryItemType”.

    What are your thoughts?

    • Paul Warren says:

      Nate, thanks for your comments.

      The first thing I’d note is that we should not be using the element ID to establish meaning. In fact, you can make a reasonable argument that they could be entirely arbitrary (e.g. “c1489″), but most people prefer to have something that’s a bit more memorable by basing it on a human readable identifier. The risk is that as soon as you start doing that people start trying to infer meaning from it.

      I don’t have a strong view on whether the standard label should necessary convey the negative value meaning. FRTA suggests that you should: “The standard label of a numeric item should indicate the expected positive and (negative) sign of the fact values it will represent” but I’d certainly not doing something just because FRTA says so.

      On the other hand, I don’t think it’s strictly necessary. I’m not aware of any cases where the inverse meaning of a concept is ambiguous. If someone said to you, “I made a Profit of minus $3m” then you might think them a little odd, but you’d know what they meant. I think the question of whether such a value is “allowable” is academic: if the meaning of a negative value is unambiguous, and that meaning corresponds to the meaning of the figure that you need to tag, then you need to tag it like that. Certainly creating a new concept to represent that negative value would be wrong.

      The idea of using datatypes to capture concepts that can’t take a negative value has been discussed. I think there are cases where it is black and white, and the entity defining the taxonomy can categorically say that the concept must never take negative values, but more generally the concern is that although a concept as it stands might never be negative, it might be dimensionally qualified in such a way that a negative value is appropriate. In this case using validation rules to flag up unexpected negatives is a more flexible approach.

      Paul

      • Great replies.
        Yes, element ID should not establish meaning. While it may be convenient, we risk filers inferring too much about an element where they ought to check the properties.
        OK, FRTA says standard label is a good place to suggest the negative value. But, that may be overkill because there are few cases where the inverse meaning needs to be clarified. Thesaurus.com antonym search does a good job for most major categories; Profit, Asset, Increase…
        But whether an inverse meaning is allowable… Yes, that’s best addressed with validations.

        So in the end, XBRL is just fine.
        It’s not fundamentally flawed to cause this confusion.
        In fact, in reading more I’ve found this negative-value-ambiguity is inherent in HTML.
        XBRL creators/filers need to learn.
        More training will help filers “do it right”
        So, your posts will help! Keep them coming!

  3. If we get rid of the “two-meanings” in element ID’s, how could we know when we could “correct the question”?
    Shall we use the standard-label? Must the standard-label be explicit about how to interpret a positive and how to interpret a negative?

    Have we already considered some explicit flag about which elements should “allow” negative values?
    Is something like positiveMonetaryItemType too severe?
    I think a validation error due to a negative value being reported with positiveMonetaryItemType
    is on par with the exceptions where a “negative Cost” is actually a correct/true representation of financials; i.e. almost never
    Most vendors have already groomed a list identifying those elements which should “allow” both positives and negatives.
    Why not make build this into XBRL explicitly?
    Maybe positiveMonetaryItemType is not too severe, but maybe it is too black-and-white;
    The vendor lists sometimes have different levels of “allowability”; from “downright nonsense”, to “maybe this is allowable, but you should check it”, to “perfectly acceptable”.
    Great blog post otherwise.

  4. Phil Mennona says:

    Great post Paul. I’m interested to understand more about how the application of your proposed new Best Practice #1 would work.

    It states, “a concept called “Profit(Loss)” should result in an element name of “Profit” not “ProfitLoss”.

    Here’s 3 elements from the us-gaap taxonomy:

    1: us-gaap_OtherNonoperatingIncome

    2: us-gaap_OtherNonoperatingExpense

    3: us-gaap_OtherNonoperatingIncomeExpense

    These elements are used together in reports that disclose the total other nonoperating income(expense) along with each of its separately reported components of other nonoperating income and other nonoperating expense.

    We obviously would not want to change the name of element 3 to “us-gaap_OtherNonoperatingIncome” because this would create a name conflict with element 1.

    What would be your suggestion in these cases?

    • Paul Warren says:

      Phil,

      A very good question!

      For the benefit of other readers, here are links to the concepts that we’re talking about:

      My suggestion would probably be to take my lead from the definition of the last concept which states “The net amount of other income and expense amounts, the components of which are not separately disclosed on the income statement…” and rename the concept to “Other Nonoperating Income (Expense), Net”, giving a concept name of OtherNonoperatingIncomeNet.

      You raise an interesting question about the relationship between the taxonomy and the financial statements that it models. Suppose you saw the following line item on a set of financials:

      
                                        2012     2011
      ...
      Other non-operating income         $23      $37
      ...
      

      What would you understand from that? Is it the net amount, and the “(expense)” has been omitted because there are no negative values? Or is it just the income, with the expense to be reported separately? The answer is that you can’t tell without the rest of the table to put it in context. On the other hand, the meaning of XBRL facts needs to be unambiguous even when considered in isolation, so it shouldn’t be surprising that concept names need to be more explicit than the line item labels you’d use on a financial statement.

      I’ll be talking a bit more about the reliance on context in “traditional” financial statements in my next post.

      Paul