Joe Ryba recently posed a question to the XBRL Public Discussion Group about a calculation in eBay’s filing. Specifically, eBay has senior notes maturing 2013, 15, and 20. eBay’s HTML and XBRL both report each of these three values as of June 30, 2012. eBay uses Members (aka Domain Members) to signify the different maturity dates of **each** Note. eBay also reports a fourth value — the total carrying value of **all** long term notes. This **total** value does **not** have a Member. This signifies the total value is not a part or component, but the whole (you might say, across the entire “domain”.) But these values weren’t validated! These values were:

- Senior notes due 2013:
**400** - Senior notes due 2015:
**598** - Senior notes due 2020:
**498** - Total senior notes:
**1,496**

Charlie Hoffman might call this a “compound fact.” (fact and value being synonymous.) The sum of the carrying value of the 2013, 15, and 20 notes **equals** the total carrying value of these notes. Joe was concerned because this “summing”, wasn’t expressed in eBay’s XBRL. An auditor or analyst could look at the printed report to validate that the numbers foot, but a computer couldn’t do it. Joe remarked:

“[eBay]… does not have calculations for all pieces”

I think Joe is referring to the calculation linkbase. Unfortunately this relationship **can’t** be expressed using the calculation linkbase, and the SEC only requires filers to submit the calculation linkbase. The calculation linkbase is part of the core XBRL 2.1 specification. While the calculation linkbase is mature, it’s limiting. The calculation linkbase **connects Concepts** (aka Elements) in a hierarchy. This hierarchy shows how **children** Concepts add or subtract to form a total **parent** Concept. Then a computer can validate that the calculated sum (the sum of children values) is equal to the reported sum (the parent value.) This seems perfect! Unfortunately, in eBay’s case, it’s **not** the **Concepts** that are adding or subtracting. Indeed, all of the above Senior Note values use the** same concept**, us-gaap_LongTermDebtNoncurrent. It’s the **Members that are adding. **That is:

us-gaap_LongTermDebtNoncurrent for **2013** +

us-gaap_LongTermDebtNoncurrent for **2015** +

us-gaap_LongTermDebtNoncurrent for **2020** =

us-gaap_LongTermDebtNoncurrent in **general**

Calculation linkbase can’t express this relationship. But XBRL Formula can do it (and elegantly, to boot!) I’ll get technical for a second, (I’ll explain some of the pieces in a followup post). I responded to the group with a representation of the Formula Linkbase that could validate this “compound fact.”:

- Fact Variable: $UnsecuredDebtTotal
- ->Concept Name: us-gaap_LongTermDebtNoncurrent
- ->Dimension Filter:
- Dimension us-gaap_DebtInstrumentAxis
- Member us-gaap_DebtInstrumentNameDomain

- Fact Variable: $UnsecuredDebtComponents
**@BindAsSequence: True**- -> Concept Name: us-gaap_LongTermDebtNoncurrent
- -> Dimension Filter:
- Dimension us-gaap_DebtInstrumentAxis
- Member us-gaap_DebtInstrumentNameDomain
- @Axis:
**Children**

Formula experts, forgive me. I’m just learning, and this “shorthand” representation is crude and probably wrong in a few spots. But I think you’ll get my gist. The first part represents the reported total. Note the variable name (starting with a “$”) “**UnsecuredDebtTotal**” The second part represents the set or sequence of the values of the Members. Note the variable name “**UnsecuredDebtComponents**” . Notice it’s not one value, but rather a **sequence**. Then, the equation (aka “Consistency Assertion”) that compares them:

- Consistency Assertion:
- $UnsecuredDebtTotal = sum($UnsecuredDebtComponents)

The sum() is a **function. **If you’re familiar with Excel, you’ll know this function. It takes some set of values and adds them together. In summary, eBay would assert that the total reported value of its LongTermDebtNoncurrent, is equal to the sum of the reported LongTermDebtNoncurrent **for each** of the maturity dates.

This raises some important questions. I’ll hazard some answers:

**Is this summing important enough to analysts that it should be validated?**- Yes. It may be less important than Assets = Liabilities + Owner’s Equity. Then again, it may be more important. I’ll put it this way: the EFM requires in spirit (rule 6.15.3) footing expressed in the printed report (HTML) should be expressed in the interactive data (XBRL). That’s exactly the case here. That’s probably why Joe was frustrated.
**Could a validator check this summing**without**a Formula explicitly provided by eBay?**- No. Not without making some significant assumptions. That would be like an analyst inferring these values should foot, if they were reported in separate notes altogether, instead of vertically aligned in a table with an underline and labels. But those assumptions would be interesting study material. And those assumptions would probably start with XBRL Dimensions (Domains, Members), which were reliable in this case. (And a computer could understand the meaning of Dimensions, whereas it couldn’t necessarily pick up on the meaning of the vertical alignment and underlining!)
**Should the SEC require the Formula linkbase?**- I don’t know. See the next question re: Formula linkbase readiness. Consider whether this would overburden the external reporting teams who are already struggling with some of the basic requirements (like getting Dimensions correct in the first place)
**Is the Formula specification mature enough to be part of any reporting requirement?**- I think so. But I get the impression spec-writers are focusing on other things.

To learn more about the formula I described above, check out the formula overview here, with some excellent examples by Herm Fischer. Watch this video where Victor Morilla of Spain explains the Formula linkbase. He links to a great Powerpoint deck at the end of the video. Thanks to the whole formula team, I think it’s pretty cool!

I posted this on the xbrl-public discussion forum. Bartosz Ochocki (of BR-AG) enlightened me about using a Value Assertion instead of a Consistency Assertion.

He said, “Value assertions are not only checking qualities of single values but also cross fact rules.”

That means a Value Assertion could express something like $parent eq sum($child)

Bartosz pointed out that the Value Assertion can even simulate the Consistency Assertion’s idea of an “acceptance radius” (that is, a threshold of materiality… or a difference between two values that the Formula creator will allow for rounding errors or something like that).

Bartosz’ example: “abs(Assets – Liabilities – Equity) le $threshold”

Bartosz pointed out that the Consistency Assertion could work, but would be unwieldy because I’d need to “specify formula output aspects, etc”

Formula output aspects are necessary if any Formula produces new information. The aspects define the context (i.e. calendar or member information), precision (i.e. decimal accuracy), and units (i.e. currency). This is extra work.

Finally, Bartosz pointed out that the extra work may be worthwhile. Say that you want every company’s $Assets, so you can calculate Return on Assets, a common ratio. But not all company’s report total $Assets.

Assume for a minute that some companies report its components, $CurrentAssets, and $NonCurrentAssets, and others report its components $FixedAssets and $IntangibleAssets, and only some from each of these groups report the total $Assets. To be sure you can derive $Assets, you’ll make a conditional Formula.

If the company reports $CurentAssets and $NonCurrentAssets,

then $CalculatedAssets is $CurrentAssets + $NonCurrentAssets

else $CalculatedAssets is $FixedAssets + $IntangibleAssets

But before using $CalculatedAssets to derive the Return on Assets, you should make sure that if they have reported $Assets, that the values are consistent!

In this case you’d use a consistency assertion like:

$CalculatedAssets eq $Assets

(and maybe you’d give an acceptance radius for some rounding errors)

In summary, because you’d be calculating a $CalculatedAssets for those companies that don’t necessary report $Assets, you’d be doing the “extra work” of defining its aspects.

But you wouldn’t want to use that calculated value unless it were consistent with a reported $Assets, if they were to use one.

Thanks, Bartosz!

I posted this on the xbrl-public discussion forum. Paul Warren actually addressed my question: “Should filers submit formulas”

He described a kind of audit problem. A filers’ Formulas, in-and-of-itself, wouldn’t satisfy investors like Joe Ryba. He pointed out, in Corefiling Sphinx**syntax, that eBay could’ve submitted a formula called “Debt Rolls Up”, which actually calculates that values are equal to themselves.

Joe Ryba could’ve run this Formula through Arelle, or some other XBRL program, to validate the formula. A computer could validate this in no time. But the validation would not have been meaningful — it’s a truism that a value is equal to itself. So this Formula could’ve been hollow, meaningless.

His point is that filer-submitted Formulas still need to be validated by the investor to make sure the Formulas validate meaningful things. And he contends, in the time it takes to manually validate the Formula, they might as well have just read the financials and checked the sum by-hand.

It’s a very interesting point!

Charlie made a nice rebuttal: So then why is it acceptable for filers to submit their own calculation linkbases? (I suppose he means, filers could create meaningless expressions using calculation linkbases, forcing investors to double-check all calculations.)

Paul responds, because Calculation Expressions are *easier to validate* than Formula Expressions…

This is great food for thought!

**Sphinx is a syntax created by Corefiling whereas Formula is created by the community. Sphinx can validate XBRL similar to the way Formula can validate XBRL. In fact I’ve heard Sphinx is easier to write and understand. But whether Sphinx is used, or Formula is used, is irrelevant to the point about the conflict of interest in letting filers write their own formulas. (As Paul says, “This isn’t a question of proprietary vs non-proprietary.”) …unless you think that the ease of human-writing and human-validating Formulas (which are more powerful and expressive than Calculations) is the lynchpin in the decision of who-can-write-the-Formulas.

Finally, I’ll note that IFRS just published a new version of their Formula Linkbase.

Check out the press release, which includes a link to ehf romula itself, here:

http://www.ifrs.org/tools/IFRS+Taxonomy+Formula+Linkbase+2012.htm

I’m inspecting some of the formulas in Arelle.

I’m pleased to note that all of the expressions I see, are Value Assertions (so Bartosz was right!)

And among the first 7 that I read (I think they’re in arbitrary order, or file order), I see that 5 of them use the same kind of expression which would’ve helped us here:

$parent eq sum($child)

I learned that an andFilter can be used on the ValueAssertion directly, to make sure that the factVariables use the conceptDataType I would’ve expected, (or in my case, the concept [us-gaap_LongTermDebt] I would’ve expected!) I think this is referred to as a “Group Filter”

This is an improvement on my Formula guess, in the original post, of using a concept filter on

eachfact variable.There is a conceptRelation which has a an Expression that Arelle is expressing in Python repr() syntax:

I’ll have to dig deeper to understand what it’s doing.