Traditional ‘internal close’ financial reporting is chart-based whereas new XBRL ‘external close’ reporting is tag-based. But there’s no need to use separate tools to do what appear to be different jobs – even if they are managed by different teams within your organization. Why not just use one application and one data and document repository to manage both?
It’s easy to forget that accounting transactions have always been a combination of data and metadata. In fact the only data in an accounting transaction is the numeric value. All the rest is metadata – the account code, the date, reference, description, currency, debit/credit sign etc. So actually we’ve all been ‘tagging’ our financial numbers with metadata for years.
The only difference is that this traditional metadata tagging of financial numbers has been based on loosely defined concepts e.g. ‘account’ that are application-driven rather than the more rigorous XBRL element ‘tag’ that is driven by an agreed, shared taxonomy. Or to put it another way, metadata has been ‘siloed’ in the application logic, rather than subject to an open and shared external ‘standard’ (e.g. the US-GAAP taxonomy).
For instance in one ERP system, the concept of an ‘account’ may mean a segmented account code with some complex internal logic that defines what each segment means. In another ERP system ‘account’ may be one of many separate ‘dimension codes’ that are used to add metadata to a transaction, which may include company and cost centre dimensions for example. Whereas an XBRL taxonomy defines what any instance of the metadata ‘account’ means – whatever number it is is attached (tagged) to.
In fact, conceptually, there’s not much difference between the way we have been informally metadata ‘tagging’ financial numbers in the past and the way formal XBRL metadata tagging is used today. The key difference is the existence of a taxonomy to drive the definition and identification of the metadata that is being used to describe a financial number.
So given that traditional metadata tagging and XBRL tagging are not much different, why would you want to use multiple applications to manage what is conceptually much the same thing? The answer – of course – is that you don’t need to. Applications like our Crossfire Controller are designed to manage both traditional chart-based reporting and XBRL tag-based reporting and leverage a single repository to manage both conventional chart-based accounting data and XBRL-tagged accounting data.
You can use the same application to produce financial statements and consolidations from traditional chart-based accounting transactions as well as to generate tag-based S.E.C. filings in XBRL. Controller not only manages converting various spreadsheets and supporting documents into an external S.E.C. filing package, it also manages internal consolidations and financial statement generation.
It’s like one of those dual cone ice creams. Pistachio and banana in one cone. Yummy that Crossfire Controller cone is so licky! But enough gelato fantasizing, back to my point…
In response to looming regulatory mandates, financial reporting managers are naturally concerned with getting their compliance sorted. So the decision path may be simply: find another ‘point’ solution to get the job done. Perfectly understandable.
But the appliance of compliance is also an opportunity to consider how to solve two problems with a single solution. Can I manage my existing ‘internal close’ chart-based reporting as well as my ‘external close’ tag-based reporting in whatever new solution I choose to get my compliance done? With Crossfire Controller, the answer is yes, you can.
