The call for speakers has been issued, with June 14, 2010 being the deadline to submit a proposal for presenting at Gilbane Boston this year.
Guidelines can be found here: http://gilbane.com/speaker_guidelines.html
Feel free to ask us any issues you have that aren't covered above!
We'll be rolling out the complete program for this year's Gilbane Boston conference over the next couple of weeks, but the overall conference schedule is now available. Note that it is subject to change, although it seldom changes very much.
In case you missed yesterday's announcement, I am happy to announce that Neal Hannon has joined us as Senior Consultant, XBRL Strategies. XBRL has been coming for a while, but with mandatory XBRL reporting requirements now kicking in, companies really need to get serious both with reporting requirements and internal use of XBRL. XBRL requires more than XML expertise, and Neal's financial background and involvement in XBRL provide deep domain expertise, and are a great complement to our existing XML strengths. Neal will be working with Bill as part of the XML Practice. Neal's bio is posted at: http://gilbane.com/consultant_bios.html#nhannon
Neal's email is: neal@gilbane.com and his phone extension is 155.
Welcome Neal!
While XBRL (eXtensible Business Reporting Language), has been in use on a voluntary basis for awhile, the long slow road to making it a requirement ended this past December with the SEC's announcement officially mandating it for large public companies (requirements for smaller companies will be phased in). We have argued for years that, as important as XBRL is from a regulatory point of view, its benefit for internal corporate and inter-company financial operations is reason enough to adopt it.
Given the current mess in the financial markets, XBRL has even more potential. Mark Cuban suggests using XBRL to help track the bailout money. Sounds like a great idea, and hopefully others will think of additional uses of this already-existing tool.
Thanks for the tweet Andrew!
I have written in the past about how some of the business information aggregators are using XBRL in their financial offerings. Edgar Online today announced that it has extended one of its core product offerings, i-Metrix, allowing users to process content into XBRL format. This kind of commercial application of XBRL is more proof of user demand--and that businesses are finding value in doing the hard work of this kind of data transformation and analysis.
Vince Wicker & Mike Wayne of The XBRL Show recorded our session on XBRL - Current State of the Art at the Gilbane Boston conference, and created a very useful 20-minute-or-so podcast. Thanks Vince & Mike!
Can tags lie? Of course they can. But this is usually not a problem because incorrect or misleading tagging typically causes trouble for the very same people who are doing the tagging. This gives them an incentive to get the tags right. And, if the tags aren't right, there is an incentive to fix them.
Consider an XML-based publishing application. I want to get the tags right so that the presentation comes out right. Or, in a syndication application, I want my tags to be semantically, not just syntactically correct, because I want someone else to use and link back to my information. Even in an XML-based commercial transaction, where there might in fact be more incentive for me to have the tags tell lies -- increasing the quantity of goods shipped, for example -- the external controls already built into the transaction (counting the quantity of goods received, for example) create an incentive to ensure that the tags tell the truth, reducing overall processing costs and ensuring repeat business.
All of this changes when we use XBRL to communicate financial information to analysts and investors. The incentives to misrepresent information or, in some cases, to hide it altogether, are substantial. This makes XBRL different from many other XML applications and requires a different approach to validation. This is not just a detail. The shift from intrinsic incentives that help get the tagging right to a need for external controls changes the way XBRL is used. It also adds to the list of capabilities that must be in place to build an XBRL market.
A couple of days ago I wrote about an instance of XBRL's leaping over the market chasm to see use in a no-nonsense, pragmatic, "early majority" application. This isn't just idle marketing chatter. The question of where XBRL stands along the technology adoption curve is one that any organization or company thinking about using XBRL needs to be asking. Just how mature is this technology? How big a bet can you put on it? And if you do make a bet, what steps do you need to take to hedge it?
On Tuesday of last week XBRL-US sponsored a set of presentations in Washington, D.C. focused on "XBRL in Government and Industry." The conference was hosted by the Federal Deposit Insurance Corporation (FDIC), which was appropriate since it was the FDIC that was the source of some of the most significant XBRL activity announced at the conference.
Here is the news: By October 1 of this year, the more than 8300 banks submitting Call Report data to the FDIC, the Federal Reserve System, and the Office of the Comptroller of the Currency will be required to do so using XBRL. Because most banks submit these reports through use of software and services supplied by a handful of vendors, this requirement will not bring about changes in the internal operations of most banks. The initiative does, however, represent a significant application of XBRL, and opens the door to greater reuse of data and simplification of workflows for other regulatory reporting requirements. It is also a good example of the kinds of broad improvement in financial information communication and processing that XBRL enables.
Follow us on Twitter