Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

checking reliability #4

Open
lukerosiak opened this issue May 24, 2013 · 2 comments
Open

checking reliability #4

lukerosiak opened this issue May 24, 2013 · 2 comments

Comments

@lukerosiak
Copy link
Owner

anyone notice any reliability issues? can we feel comfortable using this tool without saying anything patently wrong about a company as a result?

@jsfenfen
Copy link
Contributor

jsfenfen commented Jun 4, 2013

See Figure 8 (p. 32) in "An Evaluation of the Current State and Future of XBRL and Interactive Data for Investors and Analysts" (available here). Data errors were really common as of 2010, though that was, I believe, during a 'safe harbor' period. Better to source any assertion to the company's financial filings. Report sez:

"... there are several issues in the application and implementation of XBRL that bring into question its long-term future as a basis for providing interactive data for investors and analysts, in particular:

a. The reliability of the data is poor and this is a potentially fatal shortcoming of the execution of the SEC’s mandate, if not addressed quickly and meaningfully. The data quality issues and excessive use of extensions have been mentioned in various public articles or venues. As we see in Figures 8 and 9, in the early stages of application of the SEC mandate the proportion of errors and extensions was very high, making use of XBRL implausible without significant additional effort."

@lukerosiak
Copy link
Owner Author

My sense is that people got a bad taste in their mouth several years ago
and wrote it off, and now those problems have been resolved but they
haven't come back to check. Safe harbor was a big deal because it removed
all legal pressure, now they'd be more scared to file correctly.
Extensions, to the extent they are still present, are a huge pain in the
ass in general, but that's why the xbrl_fundamentals focuses on variables
that no one would dare extend.

Really, I'm from far, far outside the world of finance, so I have no idea,
this is just what I've come to think. But the other thing that I've come to
believe is that the people in charge of IT/disclosure in the financial
world aren't really as up-to-date and knowledgable as you might think,
either, so when they say it's useless, it could say as much about them as
it does about the disclosures.

On Tue, Jun 4, 2013 at 12:51 AM, Jacob Fenton [email protected]:

See Figure 8 (p. 32) in "An Evaluation of the Current State and Future of
XBRL and Interactive Data for Investors and Analysts" (available herehttp://www4.gsb.columbia.edu/filemgr?&file_id=7313156).
Data errors were really common as of 2010, though that was, I believe,
during a 'safe harbor' period. Better to source any assertion to the
company's financial filings. Report sez:

"... there are several issues in the application and implementation of
XBRL that bring into question its long-term future as a basis for providing
interactive data for investors and analysts, in particular:

a. The reliability of the data is poor and this is a potentially fatal
shortcoming of the execution of the SEC’s mandate, if not addressed quickly
and meaningfully. The data quality issues and excessive use of extensions
have been mentioned in various public articles or venues. As we see in
Figures 8 and 9, in the early stages of application of the SEC mandate the
proportion of errors and extensions was very high, making use of XBRL
implausible without significant additional effort."


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-18889054
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants