In my previous post, I looked at how a lack of clear best practice around the naming of concepts and elements has contributed to the confusion around sign conventions in XBRL. I believe that another contributing factor is that the sign conventions used in financial statements are not trivial, and actually quite subtle.
Let’s take another look at the example from my first post:
|Cost of sales||(321)||(299)|
You might also encounter a different presentation of exactly the same data:
|Cost of sales||321||299|
Different jurisdictions seem to converge on one approach or the other, but the point is that either approach is valid. The same is not true in XBRL. When it comes to signs in XBRL, there’s a right way to do it, and a wrong way to do it.
In the above examples, we changed the sign of certain numbers on the statement, but we did not change the meaning. If you change the sign of a number reported in XBRL you will always change the meaning.
When humans read financial statements, they use domain knowledge and context to correctly understand the figures. I know that companies do not usually report a negative cost of sales (domain knowledge), and a quick check of the figures above and below (context) confirms that in neither case are the suppliers paying the company!
XBRL facts are designed to be understood independently, without the need for context or domain knowledge.
To illustrate the issue, imagine the accounts above had an additional line item:
In one year the company paid tax, and in the other it received a tax credit, but which was which? In the context of the first table, I’d expect this to represent a tax credit of 100 and a tax charge of 50, but in the context of the second table, I’d assume the opposite meaning. Without the context, it’s completely ambiguous.
By contrast, the sign to be used in XBRL is completely prescribed. Ask the question, “What was the taxation?” If you answer “100”, then tag a positive number. If you answer “actually, there was a tax credit of 100” then tag a negative number.
In the last two posts we’ve seen that tagging a value with the correct sign in XBRL is easy, provided that:
If you’ve been following XBRL for a while, you might be surprised that I’ve got this far with no mention of balance attributes. We can’t avoid them forever, so in my next post I’ll be looking at whether they have anything to add, or if they merely contribute to the confusion.
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:
Examples of bad names would include:
(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!
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|
|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|
|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.
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.
I believe that much of the confusion around XBRL sign conventions could be removed by clearly documenting two pieces of best practice:
Charlie Hoffman has added an interesting post to his blog about using Magnify to verify the integrity of a financial report.
Our Magnify XBRL review tool comes built in with a range of generally applicable XBRL quality checks, as well as some jurisdiction-specific filing rules, such as the Edgar Filer Manual and HMRC’s Joint Filing Common Validation Critieria rules, but as Charlie demonstrates, the real power of Magnify comes from the ability to drop in custom rules.
Magnify’s checklist view allows users to build a custom, structured review based on checks that can be implemented in a range of technologies. The fastest way to build rules that operate on the XBRL semantics of a report is Sphinx. We do also support the XBRL International Formula standard, but as Charlie notes, “creating Sphinx rules is much, much easier”.
Charlie’s published the source to the rules that he’s using. Although readable, they look a little bland in this plain text format. Sphinx rules are most easily developed using SpiderMonkey which provides a rules development environment with syntax highlighting, concept drag-and-drop, and on-the-fly syntax validation.
There are a few neat features to note in the rulebase. The first one is these few lines:
These two “transform” statements make all of the rules in the rulebase, which are written against the 2011 US GAAP taxonomy, also work with the 2009 US GAAP taxonomy. Once it’s published, two more lines will extended them to work with the 2012 taxonomy. Obviously this depends on the relevant concepts existing in both versions of the taxonomy, but where they don’t you can add some additional, more granular, transform statements to provide the necessary mappings. What’s more, if you happen to have an XBRL Versioning Report, you can easily generate the necessary transform statements.
Another thing to note about the rules is that they contain everything needed to generate the checklist that Charlie includes in the screenshot. Our validation platform is about more than just defining and executing validation rules. It’s about building a powerful and intuitive review environment:
The benefits of XBRL as a standard electronic format for the exchange of financial information are enormous. Electronic analysis of traditional paper reports requires expensive, error-prone re-keying. PDF and HTML reports are only slightly more accessible; data extraction is ad-hoc and imperfect. In contrast, XBRL reports are structured and machine-readable. If you can process one, you can process them all.
XBRL instance documents carry the data: a set of dimensionally qualified facts. Each monetary value is tied to an ISO currency code, and every fact is rigorously defined by a concept in a supporting taxonomy. The taxonomy defines the reporting vocabulary and provides a wealth of metadata, which supports validation, guides interpretation, and facilitates comparison. The instance document tells you that Apple’s total current assets on the 26th of September 2009 stood at 31.555 billion US dollars. The taxonomy tells you which other figures contribute to that total.
The flexible nature of financial reporting is addressed in XBRL through taxonomy extensibility, which allows users to augment and customise taxonomy metadata. While this provides significant power, it means that consuming taxonomy metadata is very much a runtime consideration rather than something that can be tackled once at dev-time. Amazon’s income statement contains a custom concept for “Technology and content” expenses. Google’s balance sheet includes a custom concept for the “Total number of shares of Class A common stock subject to repurchase”. This flexibility can be frustrating for technologists, but it’s an inherent and necessary feature of financial reporting. XBRL is like a box of chocolates; you never know what you’re going to get.
Unfortunately, XBRL’s semantic power is matched by its syntactic complexity. Data and metadata is spread across multiple files, and though XBRL is XML, it is not conventionally structured, so it is not amenable to processing using traditional XML tools such as XPath, XSLT, XQuery, and Schematron.
At the XBRL instance level there is very little hierarchy. You have a flat set of facts, with dimensional information split out to xbrli:context elements, which sit at the same level as the facts.
At the XBRL taxonomy level, hierarchies are represented not as XML trees, but using XLink linkbases, which are complicated and expensive to process.
To assemble a complete and accurate picture of an XBRL report, specialist processing code is essential. Libraries such as our True North XBRL Processor can efficiently compile XBRL into a set of objects, accessible through Java or .NET. Unfortunately, this isn’t much consolation to an XSLT-savvy analyst, or the architect responsible for an XML database. XBRL is XML, but for common analysis and transformation tasks it may as well be binary.
There are two ways to address this problem:
The first is to define a set of XPath extension functions, backed by an XBRL Processor. The main obstacle here is that the extension functions must be integrated with every XML application in your processing chain. A secondary, though potentially critical consideration is that the cost of XBRL processing will be paid repeatedly, in each system that has been XBRL enabled. Finally, there is the impact on the XPath expressions themselves. The XBRL tree structures are exposed, but not as an axis, so you lose the elegant path-based navigation that makes XPath so compelling.
The second, fundamentally different approach is to transform the XBRL into a format that’s easier to manage.
Our Composite XBRL representation brings all of the XBRL data and metadata together in a single document as traditional, hierarchical XML. XPath once more comes into its own. Operations that were practically impossible to express against the source files, and cumbersome to express with extension functions, become trivial and natural. The cost of XBRL processing is paid once, up front, and downstream processing can be handled by vanilla XML tools, without the need for extension libraries. The impact of XBRL on your processing chain is minimised and localised.
We believe this approach has huge potential, and to support it we have produced TNT: the True North Transformer. Contact us for further information.