Experts in iXBRL and Application Integration
 
Happy New Year dear reader, at arkk we're gearing up for a big year in 2010.  As 2009 closed I was invited by our friends at CIAEW to their "Demystifying XBRL" seminar which took place on December 17th at One Moorgate Place.  With over 100 professionals from the world of accountancy it was a splendid barometer to indicate how the market was embracing the Ghost of Christmas Future.  Most of the people I talked to were encountering the subject for the first time, and there was a lot of baffled expressions, despite the best efforts of the presenters who did their best to keep it simple (I thought the presentation by CoreFiling of their in development product was enjoyable - again from an IT perspective).  This is the challenge of introducing such a complex IT solution (iXBRL) to an audience whose knowledge lies within another domain (accountancy).  Personally it took me weeks to get used to xml grammars when I first started out as a developer (and my projects had no tupples in, unlike XBRL!) so what chance does a room encountering it for the first time have? 
The New Year will bring new premises for arkk, we're moving offices from leafy Bishop's Stortford to The City, check out our contact page for our new address, and all the best for 2010!
 
XBRL down under 11/20/2009
 
Multi-nationals are slowly realising that the introduction of a global standard will have an effect on their business even in a market that hasn't yet adopted iXBRL or even XBRL.  In our recent discussions with the Australian Treasury's SBR (Standard Business Reporting) team , it was revealed that  those Australian companies who have offices in countries that already have XBRL are already affected despite the mother office being in Australia.   Australian companies with subsidiaries in the UK will need to comply in iXBRL, whilst the Australian one adopts the Australian taxonomy.  Even in a global standard, cultural differences however will apply.  The SBR group estimate  around 50 companies will be impacted by this fast tracking.
That's not to say that the Treasury aren't ready; they are.  Like most government bodies around the globe they are keen to have early adopters and have gone to extraordinary lengths to provide software vendors with pre-built SDKs (software development kits).  They're leaving the mapping of the files to the software vendors, but they have a strong tradition in electronic filing and have a firm desire to evangelise about the merits of machine to machine automated communication.  But because the standard isn't mandatory yet (a date hasn't even been suggested), most companies are deferring the requirement on grounds of cost vs necessity, or just waiting to see how the market reacts.
We did find some visonaries who are looking beyond the first phases of the standard.  Leading Business Intelligence software vendors are discussing their role once XBRL is adopted globally.  There'll be new requirement to slice and dice data from multiple entities, a job made easier by an agreed semantic definition in xbrl when you can compare "apples with apples".

 
 
Electronic messaging has seen many initiatives in the last 40 years.  As a result, the arrival of a new messaging standard on the scene is nothing new.  After all, the UN introduced EDIFACT in the 70's for all sorts of messages, from forecast orders, to payment advices, and that standard is still going strong today.  About 3 years ago I worked on a project with HSBC who mandated that we use exactly that, a EDIFACT D96A PAYMUL standard message!  Before the EDIFACT standard was commonplace, the world was scattered with point to point solutions, and IT maintenance headaches.

The world of XML is no different.  Early supply chain initiatives agreed to use XML as the message protocol, but XML is a language which allows you to write your own grammar, but which one?  Nestle, Danone, Henkel etc grouped together to form a new standard, xCBL (sound familiar?).  This process started off by numerous consultants and representitives of the founding partners getting into a room and defining a set of messages that covered every possible scenario that one could encounter in a supply chain that each could imagine.  The result was confusion, differences emerged over one definition or another ("does Delivery Time mean the time it takes for delivery or the time it is delivered?!"), whilst others squabbled that their requirements were special and couldn't be defined in a message, that their business was "unique".

The accounting world is experiencing the same troublesome birthing process right now.   The new messaging standards are rocking established processes, and making accountants really think about what they send to HMRC now that the information will be used for purposes beyond the current PDF that they send.  With this comes standardisation of the type mentioned above, semantic definitions are more important than ever, and there will be a mind shift to greater standardization of accounts filing.

 We welcome the introduction of a standard, when, being in the system integration space as we are, it makes life a whole lot simpler.