Having recently returned from a short visit to the 19th XBRL International Conference in Paris, I can’t help but think that many organizations are simply missing the point – and that perhaps the SEC mandate is partly to blame for this. One would think (well, I thought, anyway) that in the year following the issuance of XBRL reporting requirements by the world’s largest economy, that this conference would be overflowing with company representatives eager to learn more about how, and best of all, why they should mark up their financial data in XBRL. But alas, this was not the case. I can only guess that the meager attendee numbers – especially from the United States – have to do with the fact that organizations are still viewing XBRL as singularly a compliance issue and are continuing to outsource the “tagging” of their financial statements to financial printers or other EDGAR filing entities. So, is XBRL a compliance issue? Well, of course it is, but it is much more than that. I can tell you this for certain because I work for Altova and we simply do not focus on compliance software. We build tools that help businesses to maximize the efficiency of their internal processes with an eye toward reducing the overall time and cost of the data management workflow. And this is well within the realm of possibility for any company using XBRL – but it means taking a proactive look at the way you manage your data. “Tagging” implies that financial statements are drawn up in the traditional manner in a spreadsheet or accounting program and then retroactively and meticulously marked up with XBRL tags to make them compliant. Ugh… no wonder compliance has such an ugly ring to it! Haven’t we all got enough work to do? And wait, isn’t this just adding one manual task on top of another – doubling the chances of human error? I’m not sure exactly when this word “tagging” became so popular for describing XBRL implementation, but all it has done is succeeded in oversimplifying something that was not very complicated in the first place (admittedly, it was probably coined by someone in the marketing tribe – of which I’m a member). Anyway, let’s put this idea of tagging aside and see if we can come up with something a little more dangerous. Let’s say that all of your company financial data resides in some sort of backend repository, a database, accounting/ERP system, XML, or even some combination of these. What if you could simply map your data to XBRL in-house instead of having external consultants comb through reports and tag each line item? What if you could even reuse this mapping the next time you had to produce a similar financial report? And what if you could even have your IT department automate your XBRL filing processes?

XBRL Mapping Altova MapForce is an enterprise-level data integration tool that lets you do just this. It is used at a high level by developers and application architects, but its easy-to-use graphical interface makes MapForce accessible to anyone with an understanding of the data that needs to be mapped. Let’s look at a partial example to illustrate how easy this can be: The first step is to load insert the source data component – in this case a database – into the MapForce design pane. Note that the mapping component is a representation of the tables and columns in the database, the underlying data can, therefore, change at any time and the mapping itself will not be affected. The same is true for any mapping structure that you use in MapForce – XML, databases, flat files, EDI, Excel, XBRL, or Web services. Next, we’ll add our target mapping component, in this case a basic XBRL extension taxonomy built on top of US GAAP – Commercial and Industrial. Now, we can simply begin the mapping by connecting lines to associate line items. There will be some cases when we need to apply data processing rules to slightly modify the format, filter data, or even add constants for XBRL reporting requirements that do not exist in the database. All of this is very easily done by dragging and dropping intermediary functions from the MapForce library in the sidebar. Let’s say, for example, that your database automatically requires a datetime format to record any accounting period. Since XBRL reporting only requires a date, we need to strip the time out in our mapping. So, simply drag a date-from-datetime function from the library and connect the lines between your database and XBRL component. Of course, you’ll probably also need to add a variety of other math, logical, or other types of functions to your data, and you will find a long list of these already available in the function library.

You can also easily add custom functions, if needed, using a graphical function builder. In the end, your mapping will look something like this: Now just hit the Output tab to see what the XBRL looks like. And there you go… a reusable, extensible data mapping that you can run any time you need to submit XBRL data. You can even integrate the mapping interface into another application, or ask IT to generate code that will automate the XBRL file generation each time a report is due. For a more detailed overview of how XBRL mapping works in MapForce, check our Altova’s XBRL tutorial.

So, here we have a very quick example of generating XBRL directly from an accounting system – no need for re-keying information, no need to create a set of traditional financial statements, and certainly no need for “tagging”. And best of all, all of this can easily be done in-house and at a fraction of the cost. Now don’t get me wrong, outsourcing could very well have a place in your company’s XBRL implementation. Building an XBRL extension taxonomy, for example, could very well be something that you feel more comfortable leaving to those who have years of experience working with XBRL syntax and other complexities. But putting your organization’s financial data into XBRL… shouldn’t that be left to those who know the data best? For more information on the Altova MissionKit tools for XBRL – which includes support for XBRL mapping and automation, XBRL validation and taxonomy creation, and XBRL rendering – please visit https://www.altova.com/solutions/xbrl-tools.html …or download the Altova MissionKit today!