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.
For several hours this morning (UK time) the www.xbrl.org website was unavailable. You might think that this was of little consequence, until you realise that, consistent with XBRL best practice, HMRC’s guidance for company accounts requires that UK GAAP filings reference the UK GAAP taxonomy at its canonical location of http://www.xbrl.org/uk/gaap/core/2009-09-01/uk-gaap-full-2009-09-01.xsd using a <schemaRef> element. The XBRL 2.1 specification requires that XBRL processors resolve and discover the taxonomy documents referenced by such <schemaRef> elements. As such, out-of-the-box XBRL software following the rules of the specification couldn’t process UK GAAP instance documents during the outage this morning, and for anyone trying to use such software to create or review the accounts for their Corporation Tax return, this was a problem.
A similar issue existed for other UK taxonomies, such as UK-IFRS, and indeed, any of the many other taxonomies hosted on the xbrl.org website.
As noted in my earlier post, most XBRL software already has some mechanism for configuring local copies of taxonomies so that processing is not dependent on your internet connection or third party websites. Unfortunately, configuring such offline copies isn’t particularly easy. This is where taxonomy packages can help, as they contain all the information necessary to set up an offline copy of a particular taxonomy.
As XBRL becomes an important part of everyday business, ensuring that XBRL processes are implemented in a robust manner becomes essential. Taxonomy Packages can make doing that just a little bit easier.
Following on from my previous post on Taxonomy Packages, Eric Cohen got in touch with an example taxonomy package for XBRL GL.
You can download the sample here: XBRL-GL-PR-2010-04-12-package.zip
This is a sample for testing purposes only, based on the official XBRL Global Ledger Taxonomy. The taxonomy is subject to the standard XBRL International Copyright and Licence.
Many of the standards that we deal with in the XBRL world are fearsomely complicated, take years to develop, and enable new and exciting ways of working.
This post is about a proposed standard that is very simple, took only a few hours to develop and which is just intended to make working with XBRL that little bit easier.
Taxonomies are a key part of XBRL. They typically consist of many files, hosted on a website somewhere, which are then referenced by the instance documents or extension taxonomies that use them. This creates two practical problems for people working with taxonomies.
Problem 1: Finding the Entry Points
Over time taxonomies have become increasingly complicated, and modular taxonomies consisting of tens, if not hundreds of files have now become the norm. In such a modular taxonomy, only a handful of those files are typically considered to be “entry points”, that is, files from which you would start the DTS discovery process.
For example, the full 2009 UK GAAP, IFRS, Banking and Charities taxonomies ZIP file consists of 603 files, but contains just four primary entry points. These are described in Word documents included in the ZIP file, which means in order to start working with the taxonomy I need to:
Wouldn’t life be just that little bit easier if I could just point my XBRL software at the ZIP, be presented with a list of the four entry points (with sensible, human readable descriptions), and then just open what I wanted? Something more like this:
Problem 2: Offline working
XBRL taxonomies are typically published on publicly available web servers, and then referenced by instance documents using an absolute URL. An XBRL processor consuming such a document will then follow the URL and download the files that make up the taxonomy as required. This creates two potential issues. Firstly, it means that you need an internet connection in order to process the document. Secondly, taxonomies are big (the UK taxonomies are made up of over 50MB of XML files) so you need a fast internet connection.
In order to support offline work, and to improve performance, you really want to be working with offline copies of taxonomies, rather than constantly downloading them from the web. Most XBRL software already provides some mechanism for working with offline copies of taxonomies.
At its simplest, software can just cache copies of taxonomies as it uses them, although that means that you’ve got to use it once before it becomes available for offline use, and the cache may be subject to an expiry policy to limit its size. In many cases it’s desirable to control explicitly which taxonomies are going to be stored locally, but this is often cumbersome to configure as you need to provide not only a copy of the taxonomy but also a “remapping” or “redirection” that specifies what public locations should be remapped to your local copy.
Wouldn’t life be just that little bit easier if I could just give my XBRL software a ZIP of the taxonomy, and it would configure itself for offline use, so that instance documents referencing that taxonomy would then “just work”?
The solution: Taxonomy Packages
Taxonomy Packages are a simple solution to the above problems that require only a minimal change in the way that taxonomies are currently distributed. Most taxonomies are already made available as ZIP files, containing all the files that make up the taxonomy. A Taxonomy Package is simply a ZIP file with an extra XML file dropped into it.
The XML file, called .taxonomyPackage.xml, provides a list of the entry points within the taxonomy, along with names and descriptions. The .taxonomyPackage.xml file also contains generic name, description and version meta-data about the taxonomy as a whole, enabling taxonomy distributions to be self-documenting. All names and descriptions have support for multi-language alternatives.
The other component of the .taxonomyPackage.xml is a set of remappings, that allow the contents of the ZIP file to be treated as if they were hosted at an internet location. At its simplest, a remapping could take the form of remapping the prefix “http://www.xbrl.org/uk/” to a directory within the ZIP file. This tells a processor that every time it encounters a URL starting with “http://www.xbrl.org/uk/” it should try to resolve it to an equivalently named file within the taxonomy package ZIP.
The format of the .taxonomyPackage.xml file has been kept as simple as possible. We’ve published some samples, and of course, a schema for the file format:
We will be publishing a simple spec on the details of how these files are to be processed just as soon as we’ve had a chance to write them down.
Working with Taxonomy Packages
As you will see from the comment at the top of the schema, we’re making this available under a Creative Commons licence that allows free use of the format (including for commercial purposes). Our hope is that the XBRL community will agree that this is a simple solution to a simple problem, and if we adopt a common solution then XBRL will become that little bit easier to work with, and just a little bit less intimidating for end users.
We’re actively introducing support for taxonomy packages into our products. The recent Magnify and SpiderMonkey 1.27 releases have support for opening packages, and SpiderMonkey 1.27 also has support for creating them.
If you would like more information on taxonomy packages, or would like to see a taxonomy package sample for your taxonomy, please drop me an email.
As promised in early September, the new version of Seahorse has just been released, providing full conversion of Microsoft Excel accounts to iXBRL format, ready for HMRC Corporation Tax filing.
There’s no need to change the way you currently work. Just take your Excel accounts document and let Seahorse apply the appropriate iXBRL tags. The process replicates the same automatic tagging approach that has been so successful in the conversion of Word accounts. It also features the same ‘round-tripping’ functionality that allows you to make changes to your accounts outside Seahorse and then re-import the Excel document back into Seahorse without losing any pre-existing tags.
A fully validated iXBRL document emerges, ready for submission to HMRC as part of your CT filing.
So, don’t change your existing process. Let Seahorse simplify and streamline your tagging of Excel documents.
License Seahorse through our partners.
It’s official – Seahorse can now help you tag your Excel based accounts. The beta version of our fast, accurate Seahorse iXBRL conversion tool is now available for demonstration.
The final production version will be available later in September. The beta version shows how accounts documents created in Excel can be uploaded to Seahorse and tags applied in a similar manner to the auto-tagging of Word accounts. If you’re an existing user of the Word version of Seahorse you’ll find the workflow very familiar, including the same intelligent tag suggestion process designed to speed you through tag selection.
So, if you’re currently using Excel to create your accounts and have no wish to change your process in order to comply with HMRC’s mandate for the filing of Corporation Tax accounts in iXBRL, look no further. Seahorse provides the perfect solution for Excel users, so get in touch with one of our Seahorse partners today!
The move towards XBRL as the standard technology for regulatory filing continues to gather momentum, India being the latest country to issue a mandate. The Indian Ministry of Corporate Affairs (MCA) now requires all listed companies and certain unlisted companies to file their balance sheets and profit and loss accounts for the year ended 31st March 2011 in XBRL format.
The key to XBRL filing is the ability to produce XBRL instance documents as efficiently as possible. Following the success of our Seahorse accounts tagging solution in the UK market, we are updating the solution for Indian companies. Seahorse already supports the Indian taxonomy and we are currently adding a series of relevant validation rules to ensure MCA compliance.
My previous blog post talked about review sheets in Seahorse™. However, even if you’re not using Seahorse, you can still check the quality of your iXBRL documents prior to filing. Why is this important? Because even though HMRC has indicated they will not penalise filers who make best endeavours to comply with the mandate, their guidelines also state that incorrect or missing tags may in certain circumstances prompt further risk assessment and follow-up.
Enter Magnify™, our desktop document review tool. Magnify uses a checklist approach to guide you step by step through an assessment of your iXBRL document. Wherever possible it performs automated tests, verifying calculations and highlighting any discrepancies and errors. No matter whether you produce your iXBRL in-house, use the output from an accounts production package or outsource the whole process to a third party, Magnify gives you that extra peace of mind knowing that you’re submitting quality documents that will pass the HMRC gateway without issue.
My last two blog posts have generated a lot of interest and discussion on the xbrl-dev mailing list. I thought it might be interesting to go back to the article that triggered the discussion of rules languages in the first place.
Charlie Hoffman posted some interesting observations on his blog about common patterns in the formulae that he was creating, noting that he could distill most of what he was doing into 10 patterns. Charlie then took the next step which was to parameterise the patterns, and create code to generate the XBRL Formulas from a simpler XML format, which he refers to as an info set.
For example, one of the patterns is a “roll forward” where a closing balance should be equal to an opening balance, plus the sum of a set of changes for the period. Charlie uses the following example with US GAAP concepts:
CashAndCashEquivalentsAtCarryingValue (end of period) = CashAndCashEquivalentsAtCarryingValue (start of period) + CashAndCashEquivalentsPeriodIncreaseDecrease (during period)
You can view the XBRL Formula for this example. As you can see, it’s quite involved. Charlie’s solution is to create a much simpler XML format that contains only the parameters for this constraint:
<BusinessRule number='11'>
<Network href='abc-20101231.xsd#StatementOfCashFlows'>http://www.abc.com/role/StatementOfCashFlows</Network>
<TestType>RollForward</TestType>
<Paramenters>
<BalanceConcept>us-gaap:CashAndCashEquivalentsAtCarryingValue</BalanceConcept>
<ChangeConcept operator='+'>us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease</ChangeConcept>
</Paramenters>
</BusinessRule>
Charlie has code that takes the above XML and converts it to the necessary XBRL Formula, allowing users to work with a much simpler format. To quote Charlie:
Go look at the complexity of the XBRL Formula file. Then go look at the complexity of the business rules info set file. Calculate in your head how much effort it would take to teach someone to create that XBRL Formulas file. Then, think about how long it might take to explain how to create that business rules info set file.
I certainly agree with this, and Charlie’s approach certainly goes a long way to making these problems easier to solve, although it does suffer from the same problem as all other code generation approaches, specifically, that you can’t round-trip the resulting XBRL Formulas back to the simpler format. If you want to do something that isn’t covered by one of the patterns, then you’re left editing XBRL Formula, and you have to make sure that your edits don’t get overwritten if you regenerate from the input file.
The underlying problem is that XBRL Formula doesn’t make the simple things simple enough for a business user to work with. It won’t surprise you to learn that I think that Sphinx can do a better job here.
Firstly, I think the Sphinx implementation of this problem is much more accessible in the first place:
raise StatementOfCashFlowsRollForwardCheck let d = foreach set(values us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease[]::period) bop = $d::start-date eop = $d::end-date in us-gaap:CashAndCashEquivalentsAtCarryingValue[period = $eop] != us-gaap:CashAndCashEquivalentsAtCarryingValue[period = $bop] + us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease[period = $d]
See my previous post for an explanation of how this works. I think this sample is pretty readable as it is, but Charlie is quite right in observing that there’s a pattern here. If I were writing rules for a taxonomy like this, I’d be doing a lot of copying and pasting of code. Fortunately, Sphinx has the ability to define custom functions, so I can create a function for this pattern. Here’s what it would look like:
function roll-forward(balance, change) let d = foreach set(values [primary = $change]::period) bop = $d::start-date eop = $d::end-date in [primary = $balance; period = $eop] != [primary = $balance; period = $bop] + [primary = $change; period = $d]
Having done this, writing the rule itself is reduced to a single function call, providing the two parameters to the pattern – the balance concept, and the change concept:
raise StatementOfCashFlowsRollForwardCheck roll-forward(us-gaap:CashAndCashEquivalentsAtCarryingValue, us-gaap:CashAndCashEquivalentsPeriodIncreaseDecrease)
I can create functions for other patterns in Charlie’s article, allowing authors to write rules by providing little more than the names of the concepts involved. If you find the definition of the function intimidating, that’s fine. It only has to be written once, and can then be squirreled away in a separate file in your Sphinx rulebase, so that your business users need only be concerned with the rules themselves. (And just in case you were worried, it’s trivial to extend the function to cope with multiple “change” concepts, rather than just one)
Aside from the rules being syntactically more concise than even the simplified XML, this has a few advantages over the code generation approach:
In other words, Sphinx allows us to model these patterns in a similar way to the proposed infoset, making simple things even simpler, but whilst still making the more difficult problems solvable.
In response to my previous post, Maciej Pichocki from the IFRS Foundation posted a question:
I would be really curious to see “trivial” EPS check in Sphinx syntax (just to get started with more realistic examples of business rules application).
EarningsPerShare(reported in currency per per share) equals ProfitLoss (duration in currency) div (NoOfShares (instant beginning of period reported in shares) + NoOfShares (instant end of period reported in shares) ) div 2
It goes without saying that in a single instance I got various periods and various units.
Maciej picks an interesting example. To be fair, a “trivial” EPS check would look more like this:
us-gaap:EarningsPerShareBasic[] == us-gaap:NetIncomeLoss[] / us-gaap:WeightedAverageNumberOfSharesOutstandingBasic[]
This is simpler (and, if you’ve got a “weighted number of shares outstanding concept”, better) as it involves three concepts in the same period, so the normal lining up of periods does what we want.
The interesting bit is the units, as we’ve got three different units:
Sphinx’s “lining up” behaviour automatically takes into account the division operator and applies that same division to the units, so the above example really does just work: EPS in Euros/share will be calculated from Profit in Euros, and EPS in Dollars/share will be calculated from Profit in Dollars. This is a nice benefit of the way that units are defined in XBRL, as it allows a processor to understand the relationship between the different units.
Anyway, that’s not what was asked for. Maciej’s example uses the average of the opening and closing balances of the shares. Here it is in Sphinx:
let
d = foreach set(values ProfitLoss[]::period)
bop = $d::start-date
eop = $d::end-date
in
EarningsPerShare[period = $d] :=
ProfitLoss[period = $d] /
((NumberOfShares[period = $bop] + NumberOfShares[period = $eop]) / 2)
As you can see, the bit after the “in” maps very closely to how Maciej wrote the rule in English.
The first bit simply gets me a set of the periods for which “ProfitLoss” has been reported, and then assigns the dates at the beginning and end of that period to the variables $bop and $eop respectively. Those variables aren’t necessary, I just used them for clarity.
Maciej requested a rule that runs on an instance with multiple periods and multiple currencies:
The above screenshot shows the result of running the rule on some sample data in our Magnify review tool. As you can see, it includes two different currencies and two different reporting periods. The red crosses show where the rule has flagged a failure because the reported value does not match the calculated value.
Just to take this one step further, suppose I wanted to use WeightedAverageNumberOfShares if it’s reported, but fall back on the calculated unweighted average if not. I can introduce a function to give me the “best” option for the average number of shares:
function ANS(d)
if(exists(WeightedAverageNumberOfShares[period=$d])) then
WeightedAverageNumberOfShares[period=$d]
else
((NumberOfShares[period = $d::start-date] + NumberOfShares[period = $d::end-date]) / 2)
and then use that in my expression:
let d = foreach set(values ProfitLoss[]::period) in EarningsPerShare[period = $d] := ProfitLoss[period = $d] / ANS($d)