SEC’s Latest XBRL Action Explained

Print Friendly, PDF & Email

Publisher: FEI Daily
Author: Edith Orenstein
 

The U.S. Securities and Exchange Commission recently issued a ‘Dear CFO’ Letter earlier this month, addressed to “certain public companies regarding their reports on Form 10-Q and the XBRL requirement to include calculation relationships.”

XBRL-US, an organization that has leaded the push towards digitization of financial information, assisted the SEC in translating their requirements into plain English, and provided context for those requirements.

Below is an excerpt of an interview with Campbell Pryde, President of XBRL-US: it details the issue of calculation relationship information and how it causes problems for XBRL quality in SEC filings.

Campbell Pryde: Today, if you’re looking at a financial statement, just the regular, good old, paper-based, or HTML financial statement, the way that the data’s presented in it, it presents a number of calculations. For example, in a paper presentation, let’s say you have cash, accounts receivable, inventory and you have a line under the last one, a total of all three, and you have total current assets.

Once you take this data, and then you put it into XBRL, it becomes atomized, so you’re going to have four distinct pieces of data there: total current assets, inventory, accounts receivable, and cash. But once you’ve tagged that data for purposes of XBRL, the information is lost to indicate that the first three things add up to current assets, unless you include, what is referred to in XBRL, as the ‘calculation relationship.’

In the paper filing, the calculation of the three items adding to the fourth, is implied in the paper filing by the manner of presentation, i.e. by a single line after the bottom item, or a double underline under a total.

To capture that in XBRL, e.g., to explain that cash, plus accounts receivable, plus inventory, is equal to total current assets, or that ‘this plus this plus this plus this equals that,’ is called the calculation relationship.

FEI Daily: Why do you believe the SEC may be focusing on this now? How prevalent do you think this problem of companies failing to provide calculation relationship information is in their XBRL filings?

Pryde: The problem has been, someone has reported these full facts in their HTML filing, it’s kind of clear the way it’s presented, that those three things add to this total. But when the file was filed, they just haven’t put in the fact that those three things add to the total current assets. So that’s what they’re talking about there.

FEI Daily: Is there a way to almost force the total in a sense just like you can on, say on an Excel spreadsheet, if you can force the total in, rather than thru a formula?
Campbell Pryde: Yes.  The problem is that companies just do not define what the calculation is. The existing SEC rules are here: you need to put this formula, or in more general terms, calculations relationships, in your XBRL filings.

FEI Daily: And is this one of the errors that you find using the consistency suite?

Pryde: Yes. We check for things that we would expect a calculation to exist for. For example, If you have current assets, we’d expect you to define a calculation for it. If you have net income, you should be putting a formula in for how you got to net income. Then there are going to be other elements that you are not going to have a formula for, one-off things, that you are not going to have a calculation or formula for, like your discount rate on pensions.

The other thing we see is where the calculation doesn’t work, the total is inconsistent with the formula, so they leave the calculation out. And that usually happens when companies have entered the value incorrectly.

That’s why the SEC wants people to put the calculation relationship in, because it helps to double check the filing.

For full access to the rest of the interview, please click here.

By : Securex /July 21, 2014 /Compliance, EDGAR filing conversion tips and shortcuts, EDGAR XBRL, SEC News and Public Statement, XBRL Blogs /0 Comment