XBRL International has announced the publication of a new Public Working Draft of the Table Linkbase specification. This specification forms a key component of the Solvency II and CRD IV XBRL reporting projects. This release is the first Public Working Draft since 2011, and represents a significant step forward in the maturity and quality of the specification.
Projects that have looked to adopt the Table Linkbase specification have been held back by a lack of recent public releases of the specification, creating interoperability problems as projects have adopted customised versions of the published schemas and standards.
The latest release of the specification has been driven forward by the efforts of CoreFiling staff, and in particular, Jon Siddle. CoreFiling contributions have included the introduction of an XML serialised “infoset” for defining and testing the conformance of Table Linkbase processors, and the refactoring of the specification into three separate models (Definition, Structural and Rendering) to give a clear separation between syntax and semantics.
These improvements to the foundation of the specification will accelerate the development of the standard towards becoming an XBRL International Recommendation, and will help address the interoperability issues that have beset early adopters of the specification.
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:
One of things has continued to surprise me with the adoption of XBRL is the amount of discussion that the question of tagging figures with the correct sign can generate. Brendan Mullan recently managed to start no fewer than 12 separate threads on this topic on the xbrl-public list, some of which resulted in significant further discussion.
Marking up figures in electronic format is not a new phenomenon, and I’m not aware of any other domains that have managed to get so tangled up in sign issues. What is it about the application of XBRL to financial reports that causes such difficulty? I have some ideas, but first let’s look at how to do it right.
Let’s consider the following extract from a Profit and Loss statement:
|Cost of sales||(321)||(299)|
There’s a really simple way to get the sign right in XBRL, every time. Simply take the name of the concept that you’re using to tag the figure, and turn it into a question by prefixing it with “What was the… ”
For example, suppose our concept is called “Cost of Sales”.
Question: What was the Cost Of Sales?
Even though the figure in the accounts is shown as “(321)”, you wouldn’t answer that question by saying “minus £321,000”, would you? So we tag a positive number.
On the other hand, if in your answer you need to correct the question, then the sign should be negative:
Question: “What was the Operating Profit?”
Answer: “Actually, there was a loss of £14,000.”
Our answer is the opposite of the question that was asked, so we’d tag a negative number against a concept called “Operating Profit”.
Sometimes the concept name will be more explicit about the sign convention. For example, you might have a concept called “Increase (Decrease) in Accounts Receivable”. In this case, just ignore the bit in brackets, so your question becomes:
Question: “What was the Increase in Accounts Receivable?”
If your answer starts, “actually there was a decrease…” then you should tag a negative number. Otherwise, you should tag a positive number.
It really is that simple. Nothing to do with balance attributes, negated labels, calculation weights or any of that stuff.
There’s a number of reasons why what should have been a really straightforward issue has become confused into something much more complicated. I’ll address these in a series of follow-up articles:
Speed up the tagging process in year two and the creation of filings for companies in the same corporate group.
Seahorse makes excellent use of existing tags. It can re-use existing tagged documents as the basis for this year’s filings, even if those documents contain only a couple of similar pages and on the surface look rather different. Seahorse is intelligent enough to recognise the matching pages and automatically re-uses the existing tags in the new document. Remember that the rest of the document will then be automatically tagged, leaving you just to confirm the confidence-rated suggestions. It will certainly save you time and give you much higher quality documents.
Seahorse, the automatic choice.
Seahorse’s learning engine has accumulated an abundance of iXBRL tagging knowledge distilled from the thousands of Word and Excel accounts uploaded to our cloud-based system since the start of the HMRC mandate.
Why is this important?
It means that Seahorse’s tagging suggestions are constantly refined in line with our clients’ professional accounting expertise. You benefit from more confident suggestions to help you review and confirm the appropriate tags. It’s quick, easy and accurate.
Get the Seahorse advantage for your business!
We again return to the subject of year two tagging. We’ve talked in the past about how Seahorse can re-apply the tagging decisions already selected and confirmed in previous years’ tables and text. The issue today is speed of tagging – making the process as fast and painless as possible.
Seahorse has extended the ‘roll-forward’ process still further to make tagging even faster.
Both comments and footnotes can now be carried forward and reapplied in a similar way, simplifying the task further. Comments are transferred without the need for any user input, and footnotes can be confirmed in the same way as other tags.
Accelerating the process still further, there’s now an automatic confirmation option. So, where there are exact matches between table rows and columns in both previous and current documents, Seahorse can reapply the tags automatically without the need for manual intervention.
Just in case you were wondering, discretionary use of this facility is available, so you still retain full control over whether or not to deploy automatic confirmation of identical data. However, we think that many users are likely to opt for this extra time saving measure.
How long will it take to tag your year two accounts?
Perhaps you successfully circumvented the original HMRC iXBRL filing mandate by submitting last year’s Corporation Tax returns early to avoid the April deadline. If so, converting your accounts documents to iXBRL must now be on the agenda. What are the options? Well, if you’ve a number of accounts that you are already producing in Word or Excel, why change your process? Take a look at the advantages of Seahorse.
First of all, there’s help in choosing the appropriate iXBRL tags. Seahorse automatically tags the tables in your Word or Excel document and proposes the most appropriate tag to use. Its intelligent tagging engine harnesses the accumulated learning from all the filings put through the Seahorse system, so its suggestions continue to become more and more refined over time. There’s no need to trawl through the underlying taxonomy to find the tag you need.
If you have a number of accounts to tag within the same group company you can re-use your initial tagging decisions to swiftly create iXBRL documents for additional sets of accounts.
And if you have a formal review and sign-off process for your accounts, Seahorse lets you easily create a spreadsheet that automatically captures all the tagging decisions made and allows comments to be inserted, for example to explain why particular concepts have not been tagged.
Finally, Seahorse is provided over the internet, so you can use it straight from your browser, avoiding the expense of new infrastructure or purchasing a full-blown accounts preparation package and, because the whole process remains under your control, you don’t have to risk sending your data to third parties.
Seahorse remains one of the very few solutions to have experienced no problems passing the HMRC gateway first time. Why? Because not only does it incorporate validation against the Joint Filing Common Validation Checks imposed by HMRC and Companies House, but the underlying XBRL and iXBRL is fully verified during the Seahorse conversion process.
Seahorse takes away the pain of iXBRL conversion of Word and Excel accounts.
What could be simpler?
The momentum around iXBRL continues to accelerate. Denmark is the latest country to mandate iXBRL as the platform for financial reporting. Adopting a phased approach starting in June 2012, the official register for Danish companies, the Danish Commerce and Companies Agency (DCCA), will require all companies to file in iXBRL format.
The good news for Danish companies is that Seahorse offers full support for the new Danish GAAP taxonomies and caters for a number of requirements specific to the Danish market, including full verification of both XBRL and iXBRL against DCCA validation rules.
With the starting month for year 2 iXBRL filing rapidly approaching, Seahorse can help you dramatically reduce the time taken to tag this years’ accounts. If you’ve already been converting documents to iXBRL using Seahorse, you can now migrate the tags from your existing accounts to the next year’s accounts, without losing any of your original tagging decisions. Seahorse will still auto-tag any remaining items not contained in the earlier document. The migrated items should already be correct from the previous year’s filing, so very few changes should be required. As a result, the review process will be shorter and the whole year 2 tagging procedure will take significantly less time now that you don’t have to start again from scratch.
As an added bonus, you can also re-use your tagging decisions to speed up the tagging of accounts for several different companies within the same corporate group.