Technorati Profile
The EDGAR system is now busily accepting live XBRL filings. Last week (week of May 4th) there were 11 new filings. I thought it would be beneficial for those who are new to XBRL to write something about preparing a valid filing. By valid, I mean something that will pass the EDGAR validations and make it into the system.
There’s a lot of talk out there about how difficult XBRL is and how companies should not try to prepare their own filings but instead outsource it. We at Rivet Software work hard to make products that take the complexity out of XBRL so that you can do your filings in-house. One of the ways we do that is by hiring people like me, a CPA who understands financial reporting and how to create tools that are easy for non technical professionals to use.
Another way we do that is by including a robust validation engine with both of our tagging products – Dragon Tag and CrossTag. What validation does is make you aware of any problems your filing has before submitting to EDGAR. Our validation engine incorporates the XBRL rules pertaining to SEC filings as specified in the March 2009 EDGAR Manual (Version 11) which means that we will warn you if you are doing something that is out of compliance with the latest rules (for users not filing with the SEC, don’t worry, we only apply SEC validation against SEC filings so you won’t be bothered with unnecessary errors).
When you create an instance document with Dragon Tag or CrossTag, there are many XBRL errors you’ll never encounter. So I’ll focus on a few of the errors and warnings you are most likely to see.
Please remember that I can’t possibly explain how to resolve all the errors/warnings you may encounter in this blog posting but I can point you to something better: our professional services team. If you get stuck, just give us a call and speak to an experienced professional.
When Validation is Performed — On-Demand and Just-in-Time
First, let me give you some added comfort by explaining when validation is performed. Both products give you the option to perform validation on demand. In other words, just click a button and the instance doc will be validated and a window will pop up showing the errors and warnings. But, we don’t just rely on the user clicking validation. We also perform validation before report preview is run and before a filing package can be created. So if there is a fatal error in your filing and you forget to run validation on your own, the products will automatically run validation and will not let you proceed without fixing certain errors. That should give you some peace of mind.
Validation Error Types
Let’s get into the types of errors you will see. There are three main types of errors: XBRL errors, SEC related errors, and calculation errors.
XBRL Errors
XBRL errors come about because something in the filing does not agree with the XBRL specifications. There is no need for a normal user to get into them – you’re better off leaving that geeky stuff to us – but when you see these errors, rest assured that they are easy for you to fix. For example, each fact must have a date associated with it to give it the proper context. If you don’t have a date, you’ll get a red error listing the element and the message saying “Cannot find a valid reporting period”. Another example is most elements require a unit such as USD or Share. If no unit type is specified, you’ll get a validation error saying so.
These more serious errors are shown in red and listed at the top of the validation error list. These errors pertain to a nonconformance with XBRL standards and must be fixed before a filing can be created. The less serious grey ones may or may not need to be fixed. But, to be on the safe side, it would be good practice to fix all errors and warnings that are consistent with your filing agency’s rules.
SEC Errors
SEC errors and warnings are the ones spelled out in the EDGAR manual. These errors will not prevent you from creating an instance document for filing, but you will be warned before creating a filing that there are errors in the instance document. The difference between SEC errors and warnings is that an SEC error will prevent the filing from going through the EDGAR system while a warning will not. Here’s a list of some common SEC related errors and how to resolve them (I have not included any warnings on this list).
| Error Text | Remedy |
| The following element is required: ‘dei_…..’ | Certain elements from the dei taxonomy (Document & Entity) are required for all SEC filings so they must be included in your filing package. These elements are located in reports 995200 and 995400. The Document & Entity elements consist of items that are found on your front page of your 10-Q or 10-K (i.e. Registrant Name, CIK, fiscal period, etc). |
| Extended element ‘xxxxx’ is missing in the presentation view | Select the right click option – on the taxonomy tree – to “add missing in-use elements” or add this element to the taxonomy while in the presentation view. If the element in the error message is one that you normally do not present in that statement then you can remove it from the calculation view to clear up this error message. |
| Dimension member must a have name that ends with either ‘Domain’ or ‘Member’. Element to change = ‘xxxxx’ | Delete the dimension member or domain from the taxonomy then re-add it using Member or Domain at the end of the name. |
| SEC filing does not allow the use of scenarios that are not part of the dimension structure in the taxonomy | Remove any non-dimension scenarios from the markup and replace them with scenarios from the dimension structure. |
| The name of an extended element cannot equal the name of a standard element. Element to change = ‘xxxxx’. | Delete the extended element and re-add it with a name that does not equal a base element name. |
Calculation Errors
Another common error you’ll encounter is a calculation error. Let me provide some background on XBRL to explain this. The beauty of XBRL is that it is multi-dimensional. It’s not just used to report facts but it also is used to present those facts in the way the user intends and to verify the integrity of relationships within those facts. So if you are reporting sales of 100 minus cost of goods sold of 75 and gross profit of 25, XBRL can actually validate that these numbers add up.
This can be a blessing and a curse. A blessing because it ensures the integrity of the calculation relationships but a curse because you may see many errors that may not really be an issue with your filing. The problem is the base US GAAP taxonomy. It is very complex and includes many, many calculation relationships that may not apply to your financial statement. So you will get calculation errors. To resolve them, you have to change the relationships to be the way you want them. This can easily be done using our products and I’ll explain how below.
For example, say you get a calculation error that says “Calculation error for summation item Row 5 Column 2 – Accounts Payable and Accrued Liabilities, Current 650 does not match calculated total 850″
The first thing to do is switch to Calculation View so you can see the calculation relationships. At first, you may find it awkward looking at the taxonomy this way. But there are just two things you need to understand.
- The parent is supposed to always equal the sum of its children.
- A calculation weight exists for each element telling the system whether to add or subtract that particular element in calculating the total.
The screen shot below shows the calculation view of the balance sheet. From it we can see that the element that has the error, “Accounts Payable and Accrued Liabilities, Current”, is parent to “Taxes Payable, Current”. For this filing, we have made the decision that we don’t want Taxes Payable to roll up into Accounts Payable and Accrued Liabilities. We just want it to roll up to current liabilities.
To fix this, simply drag “Taxes Payable, Current” on top of “Accounts Payable and Accrued Liabilities, Current”. You’ll then get a prompt asking if you want this element to be “after”, “before” or “a child of” the Accounts payable element. Elect to put it after the element. The below screen shot shows what the taxonomy tree looks like after making that move. It shows that “Taxes Payable, Current” is no longer a child of “Accounts Payable and Accrued Liabilities, Current” but is still a child of “Liabilities, Current”.
Once you’ve made that change, you will no longer have that calculation error. I hope this discussion on validation helps make your XBRL tagging and filing experience smoother and remember we are available for questions through our response line. Go to http://www.rivetsoftware.com/Customer_Support/Default.aspx for contact information.
Tags: Assurance, Compliance, CrossTag, Customer, Dragon Tag
