« Maybe David is Right and the Market for XBRL is "Billions and Billions" | Main | Understanding the Moving Pieces of Dimensional Aggregation »

Reversing My Position: Calculation Inconsistencies Can Be Unavoidable

I have long held that 100% of calculation inconsistencies can be avoided. I am changing that position, somewhat reluctantly, given strong evidence that this is a sound theoretical position, yet it is not a sound practical position.

While it is the case that you can make such calculation inconsistencies go away, it is not the case that you can do so and make the set of financial reporting disclosures which one would desire to make from an accounting perspective.

The reason I am reluctant to take this position is because I see many XBRL instances which now sloppily hide behind the fact that calculation inconsistencies CAN exist, now have calculation errors which should NOT exist intermingled with true calculation inconsistencies and those calculationerrors go undetected. This is unfortunate, but I cry uncle and admit that it is unavoidable in many cases.

My new position is that XBRL calculations or XBRL Formulas should exist which prove that everything which should foot or cross cast, does in fact foot and cross cast.  You prove that, then you can safely ignore the calculation validation results which do report calculation inconsistencies.

Regretfully from the perspective of an XBRL instance consumer, this makes things tougher.  My answer is that a good analysis application will show you things which do add up and will somehow mask the confusing calculation inconsistencies which really mean nothing.

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

I chatted with Eric Cohen, who (unless I misunderstood), suggests that if weight could be changed without breaking a rule (credit>debit , -1 | credit>credit, 1, etc.), we would be in a better place.

Do you think that rule is necessary?

I like the rule, but I think it results in caclculation inconsistencies that can't be avoided; namely when we have the "no element to represent the OTHER side of the accounting entry" dilemma.

So is it the applications that need to figure out the difference between a legitimate calculation inconsistency, and a false positive?
Can XBRL itself adapt to these issues?
Can regulation be relaxed, all else equal? Or is all this a perfect opportunity for the formula linkbase to prove its worth?

Thanks, Charlie
March 24, 2011 | Unregistered CommenterNate

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.