Peeling away financial reporting issues one layer at a time

Is XBRL the Future of Financial Reporting? (YES!)

For many of the financial reporting questions of the day, the right way forward is self-evident and direct. “Build it and they will come,” I say.

But far too often, policy makers allow themselves to be bogged down by executive-class luddites and their minions who will say or do almost anything to preserve the advantages conveyed to them by the status quo.

The resistance to XBRL is a prime example. I will grant that a good-faith exchange of ideas can take place about how to “build” the XBRL disclosure system; but the “will they come?” question is a no-brainer that has to trump the cavils of the luddites.

Similarly, the FASB should take it as a given that XBRL will be a game changer for accounting standards. For example, the question of “net income” versus “other comprehensive income” fades to insignificance so long as an analyst can make her own pro forma reclassification that automatically flows through to ratios and valuation models – with just a few clicks on a web page.

Another policy implication is that the FASB should be ensuring that users have access to enough quantitative data to unwind a stinky accounting treatment and/or to obtain a more profound understanding of reported earnings and changes in financial position. I have mentioned on more than one occasion that detailed reconciliations (roll-forwards) of balance sheet accounts combined with XBRL data tagging would be just the ticket for shedding light on financial results — without having to resort to manual deciphering of obscurantic narrative disclosures. If the FASB does not put XBRL front and center in its disclosure framework project, then it is doomed to fail miserably.

Journalists in search of controversy where none should exist have reported on how financial professionals have found little use for XBRL, but that was before companies like Thinknum came on the scene. I get about one email each week from a start-up company that offers to write a blog post for me – about their product. For them, I have made an exception, because they seem to be among the first real players to step on the field of dreams that is XBRL.

By way of background, Thinknum founders Justin Zhen and Greg Ugwi met at Princeton but went their separate ways after graduation; Greg to Goldman Sachs and Justin to a hedge fund. After learning with some chagrin that the financial analysis tools available to them as professionals could be vastly improved, they left their jobs and used their savings to start Thinknum. Current paying customers now include traders at bulge bracket wall street firms. To give you an idea of how they use XBRL data in the cash flow and time series analysis tools, here’s a brief excerpt from an interview they did with the CFA Institute:

“We collect market data from exchanges, company filings on XBRL EDGAR, and macroeconomic data from government agencies like FRED, EUROSTAT, Ireland’s CSO, and others. These agencies are independent, often territorial, and have little incentive to ensure their data releases play well to [sic] each other. By bringing all these diverse data sources together on one platform, Thinknum enables investors to make interesting connections.”

The following text and graphics was provided to me in response to examples that readers of the Accounting Onion would appreciate:

For example, Thinknum has developed the Plotter, an application that allows users to plot data from corporate filings over time by clicking on a label in the financial statements. The plotter makes over 70 basic valuation ratios readily available, and more importantly, we allow users to create ratios on the fly by simply using mathematical expressions. For example, to view Google’s financial leverage you can type total_assets(goog)/total_equity(goog). This app has become enormously popular with our users and would not have been possible without XBRL.

A major pain point for most analysts is spending hours building and updating models in Excel. These models are used to project a company’s earnings and hence that company’s valuation. We have watched investment bankers and traders spend countless nights poring over PDF documents to update their spreadsheet models. Using XBRL, we designed software that enables analysts to build cashflow models that are updated as soon as a company’s filings are released. Our clients have applied these models across hundreds of companies, greatly adding leverage to an analyst’s work. Automating these tedious tasks affords analysts the opportunity to focus on making better judgments about the quality of the numbers reported and other economic factors that are critical to successful fundamental investing.

* * * * *

If these two smart guys have actually built the robust, user-friendly XBRL-based analysis package that they claim to have built, then the policy implications for the SEC and FASB are self-evident: build in more XBRL data; and more uses will come.



  1. Reply Johnny February 19, 2014

    Instead of using confusing terms like XBRL tagging, why not have the SEC issue a form for the 10-K, just like the IRS does, so that the SEC can figure out what in the heck the XBRL tags even mean by mapping them to a line on a form, and we can just fill out the damn form, instead of this bizarre white paper 10-k process we have now.

  2. Reply Mike Boyle February 23, 2014


    Something to keep an eye on is the pending roll-out of the revised ACRA XBRL filing requirements and the portal which will be deployed in about 10 days. See

    I can tell you first hand the prior version of this, which was FS Manager, essentially provided what you are describing; a template based set of financial statements and footnotes where users input the content. When exported it created a *.xbrl file (no extension taxonomy files) which could then be validated, printed, saved, re-uploaded and file.

    While this approach did simplify the XBRL preparation it did not necessarily un-complicate it. The template did not always cover all the necessary concepts for even the most basic set of financials. You could probably navigate through the balance sheet easy enough but the cash flows and shareholder’s equity statements were a challenge. Also, finding, let alone correcting, errors could also present some issues.

    Nonetheless, in many respects I found it to be very impressive. It walked the registrant through the document (DEI-type info, financials, notes, some styling capability, validation, printing, saving, etc.).

    Can the SEC do this in the current 10-Q, 10-K environment? Who knows, there is a lot of brush to clear before they could take on that initiative. I think it is far more likely you see something like this happen with Form 8-K or Form N-PX, both of which have been recommended by the SEC’s Investor Advisory Committee.

    While I would not consider ACRA a ‘model’ for the SEC, it does bear watching.

    Kind Regards,

  3. Reply Matt February 25, 2014

    I don’t think there is any doubt that the financial world needs to work with and embrace XBRL. There are some implementation questions but the value it brings to the investment community is insurmountable.

  4. Reply IV March 5, 2014

    Tom, I continue to love the blog.

    As a programmer, I have some intimate knowledge of XBRL, how it is internally organized in the XML, and how the whole operation is supposed to work. But XBRL was clearly designed when XML was the popular standard for human readable-data — as opposed to other human readable data formats like JSON.

    This legacy is unfortunate and it has put up huge barriers to adoption of the system.

    The people at Thinknum (just like my own software) are altering the XBRL data itself before it is stored in their database. The fact that they MUST transform it (and transform it a lot to be sure) is a big indictment of the standard in my opinion.

    But these things will not change and therefore the future winners (I hope to share this prize myself) will be the ones who take XBRL and changed it into a better format for data operations.

    And it is worth noting that the SEC could have avoided this but, for some unfathomable reason, they choose to make it unnecessarily complicated. It is so unnecessarily complicated, in my opinion, that I occasionally wonder whether I am witnessing a conspiracy against the laity.

    Anyways, there is one other problem: the creation of unique “data types” (really just super-specific income or bs accounts) by individual companies. E.g., Exxon has 29 Exxon-unique datatypes in the most recent balance sheet filed with the SEC. To compare XOM with another company, then, implies that software engineers have to create mechanisms which normalize XOM’s data such that they can compare it with, say, COP’s data. This is challenging since most software engineers are not accountants. (This is such a problem that a lot of XBRL software will tell you how much of the XBRL is GAAP and how much is company specific — the percentage of company-specific data is frequently above 20% of the all data points).

    In any case, there are some major flaws with the standard but I think we don’t have a choice. Software engineers will just have to be a bit more clever to overcome these challenges. Great blog post.

  5. Reply Warren Miller, CFA, CPA April 14, 2014

    I agree with your enthusiastic endorsement of XBRL. Unfortunately, two of the bonehead politicians (sorry to repeat myself) have put on a staggering exhibition of economic ignorance and abject stupidity, even for Congress, by introducing H.R. 4164, “Small Company Disclosure Simplification Act” (link: Like the Affordable Care Act, this legislative idiocy means exactly the opposite of what its title would have people believe; it should be called “The Job-Killing, Cost-of-Capital Increase Act.” The bill would exempt both emerging growth companies and enterprises with annual revenues < $250 million from compliance with the SEC's XBRL reporting mandates.

    To show yet again that economic ignorance runs at epidemic levels in Congress, the bill was reported out of the House Financial Services Committee on March 19. 2014, by a margin of 51-5. It now awaits a vote by the full House of Representatives. Increasing the cost of access to small-companies' SEC filings is likely to reduce coverage by analysts, significantly raise the cost of analyzing such companies' performance, increase perceptions of risk, and, as a direct result, increase the cost of capital for most small public companies. That will retard growth and reduce job creation.

    If Congress's IQ were one higher, they'd be vegetables. I hope that readers of the Accounting Onion will weigh in with their representatives on this misguided and ignorant piece of legislation.

  6. Reply Sofhia Thomas July 6, 2014

    XBRL allows interchangeability of data, reduces time and helps to analyse financial information of multiple companies. Hence, XBRL is for sure the future of Financial reporting.

Leave a Comment