iXBRL: An opportunity, not a threat

Contrary to popular belief, the need to embrace the new iXBRL international e-filing standard represents a huge opportunity for accountants, argues Mark Davies.


Much has been written about the impending deadline for embracing the new iXBRL electronic format in company financial accounting. In the UK, HMRC has set 1 April 2011 as the date from which companies will have to file their Corporation Tax computations and supporting accounts electronically using the new international data exchange standard. However, all too often the commentary has focused on the negatives, when there are many benefits associated with standardised data exchange - not least that is has sparked a whole new round of innovation in accounting software.

Static reports lose impact
Right across the financial services field, from accountancy services to banking and IFA practices, the momentum towards dynamic reporting and client self-service has gathered such force that the trend is now irreversible. The days of clients waiting infinitely for a definitive paper-based report are coming to an end, because the average business is no longer adequately supported by static answers to pre-known questions.

In the more dynamic and brutally competitive areas of financial services, newer technology has already begun to turn this situation around. Open standards and closer integration between back-end data entry and front-end reporting tools have transformed the ability to produce more frequent, even ad-hoc reports, enabling faster decision-making. In the more advanced scenarios, on-the-fly reporting facilities have been made available as a value-added service to clients - a self-service tool, readily accessed online.

A chance to innovate
The accounting profession has now been given a chance to catch up, thanks to the availability for the first time of a vital, yet hitherto missing, link between back-end bookkeeping systems and front-end reporting solutions, and this is all thanks to the iXBRL standard.

Mark Davies is UK country manager at Twinfield.

Continued...

» Register now

The full article is available to registered AccountingWEB members only. To read the rest of this article you’ll need to login or register.

Registration is FREE and allows you to view all content, ask questions, comment and much more.

Comments
carnmores's picture

in fewer words

carnmores | | Permalink

IXRBL will mean less compliance and allow the sale of higher value added services .... i'll believe it when i see it...

mkcdavies's picture

Why less compliance?

mkcdavies | | Permalink

Controls in the software should help to improve compliance by reducing reliance on eyeballing data.

GaryMc's picture

I don't believe it...

GaryMc | | Permalink

I think Victor Meldrew is referring to compliance work rather than iXBRL causing compliance issues.

If XBRL is introduced at the correct end of the system i.e. first entry point for data and then used throughout the system then it has the ability to do everything that Mark suggests.

Trouble is that some bookkeeping systems think that XBRL is just a final accounts issue so haven't looked at it.

How to reduce compliance costs and still be fully XBRL compliant

fleur oswald | | Permalink

Due to independence issues audit firms will not usually prepare statutory accounts for the larger Corporates, preferring clients to struggle with ever changing accounting standards which in turn leads to poorly drafted statutory accounts on word and excel.  Firms can then charge for additional fees where they need to intervene to ensure statutory accounts and UK GAAP and Companies Act compliant.   Further costs will them be charged to ensure that the new XBRL requirements are met.

The introduction of XBRL will lead many larger companies to review their entire accounts production process due to the weaknesses inherent in the largely manual preparation of statutory accounts.  Companies will need to adapt their in-house accounts preparation processes and implement technology capable of producing company accounts in the XBRL format.  

Here at Bishop Fleming we believe we can help relieve both the administration and cost of the entire statutory accounts process.  Using our advanced software we can convert a trial balance into XBRL compliant statutory accounts thereby relieving the administration of both the statutory accounts process and these new requirements.  By acting as a bridge between current auditors and in-house accounting staff we believe that we could actually reduce compliance costs and free up in-house finance functions to actually run the business rather than getting bogged down in mundane compliance work.   

For further informations see my blog  http://www.bishopfleming.co.uk/Home/Blog/July-2010/Important-Changes-to-Filing-Accounts-and-Tax-Retur.aspxhttp://bit.ly/cM4Uwx

Up-front tagging - not for the majority

Andy3T | | Permalink

XBRL tagging up-front at the point of data-entry - only for the largest clients or those in the financial industry.  For the remaining 95%+ of companies it would be an expensive and counter-productive waste of time.  One of the key roles that accountants (internal or external) perform for their clients is data-correction and validation.  Garbage-in-garbage-out has always been the story with computers and tagging up-front data would just risk making data more error ridden as people assume that 'the software' will fix their errors (much like the auto-coding of VAT rates in book-keeping packages sometimes leads to more VAT errors as the data-entry clerk assumes that the computer knows what it is doing and stops thinking what treatment is appropriate for themself).

The practical difficulties of up-front tagging for most companies led HMRC to mandate end-data only tagging of the accounts and tax computation.  As such most accountants will, very correctly, only be looking at end-data tagging.  Could some organisations benefit from up-front tagging?  Of course, but in practice for most businesses it would just deliver more accurate-looking errors - the best check on financial data is always to think 'what do I expect' before looking at the figures and then to reconcile the anomalies between expectation and practice - and in that sort of test up-front iXBRL tagging would be of help only in tracking down errors.

I also note that the accounting taxonomies are geared very much towards data in financial statements - the complete lack of usefulness inherent in modern financial statements has long relegated them from a management planning/monitoring tool to a year-end piece of drudge-work required by law but almost useless to management.  iXBRL has the potential for far wider and more useful data-gathering within a large organisation, but many organisations will have to heavily extend the taxonomy they are using to fit their internal monitoring systems and needs before they see real internal value from up-front tagging.

The main thing that most accountants can do for their clients is to minimise the cost and worry that comes with the iXBRL requirements.  For some clients accountants may find that the best value to be obtained from iXBRL is in using it to encourage clients to upgrade obsolete accounting systems, or to harmonise systems and accounts templates across dividisions/gorup members.

daveforbes's picture

Upfront tagging

daveforbes | | Permalink

Identifying items early is really about documenting charts of account. If everyone used the same chart of accounts (e.g. sage) or at least annotated the one they were using in some computer readable way it would allow for the automation of tagging.

Actually putting XBRL tags in the source data would be problematic - XBRL (or at least XBRL-FR rather than the obscure XBRL-GL) is really an output language. Which taxonomy would you use ? UK-GAAP 09 or IFRS (used by HMRC for accounts) HMRC-CT taxonomy (used by HMRC for CT comps) or companies house' AE (audit exempt) extension taxononmy to UK-GAAP 08. A particular item in your chart - say "legal costs",  would need to map to different XBRL elements (in different taxonomies) depending on the (multiple) contexts in which it will eventually be used.

"XBRL enabling" a bookkeeping package is really just a case of mapping its chart of accounts onto a known one. It would be much easier if we were in France !

David Forbes, XBRL Geek, Forbes Computer Systems.

mkcdavies's picture

Standardisation, not up-front tagging

mkcdavies | | Permalink

@Dave Forbes, I agree.  If we all used the same COA structure, HMRC and Companies House probably wouldn't have bothered with XBRL at all.  As it is, we all have the freedom to adopt and modify whatever COA strucuture we want (although not all accounting software allows such flexibility).  So one of the biggest challenges facing software suppliers is to provide a way of standardising the mapping process across multiple structures.  Done well, practices will be able to realise significant labour savings in the accounts production process.

I'm not sure how the idea of "up front tagging" came into this thread, or what the benefits of it would be?