Last week marked a momen­tous change for the UK account­ing indus­try. On April Fools Day 2011, it became manda­tory for UK com­pa­nies to report their statu­tory accounts and tax com­pu­ta­tions in a new for­mat called Inline XBRL. This change trans­formed the way in which orga­ni­za­tions report to HMRC in one fell swoop, simul­ta­ne­ously end­ing the centuries-old prac­tice of fil­ing on paper and unsanc­ti­mo­niously boot­ing PDF fil­ings out of the door (except in very par­tic­u­lar cir­cum­stances). As of now, every com­pany in the UK must file elec­tron­i­cally using a struc­tured data format.

Inline XBRL, oth­er­wise known as iXBRL, is an incred­i­bly ele­gant solu­tion to finan­cial report­ing. A deriv­a­tive of XHTML, iXBRL allows users to pro­duce human-readable doc­u­ments that can be ren­dered in web browser while also allow­ing them to embed addi­tional struc­tured data. When processed by a com­pli­ant proces­sor, an iXBRL doc­u­ment is trans­formed into an XBRL instance document—a for­mat used by gov­ern­ments, reg­u­la­tors and ana­lysts world­wide. For those of you that don’t work in the world of finan­cial report­ing, iXBRL really is a very neat option: the very same data that is read by human eyes can be trans­formed into an XML–based machine-readable for­mat by any iXBRL com­pli­ant proces­sor, allow­ing a sin­gle source doc­u­ment to be used by ana­lysts and BI tools alike.

For the aver­age user, iXBRL means that the doc­u­ments seen on-screen are com­pa­ra­ble to the Word doc­u­ments, Excel doc­u­ments or even PDF doc­u­ments which they are replac­ing (and in many cases, the doc­u­ments from which they were gen­er­ated). Pro­vided it doesn’t hin­der machine-readability or require dupli­ca­tion of data, this famil­iar­ity can only be a good thing. The fact that iXBRL also hides away the hideous angle-bracket-and-slash-infected nature of XBRL doesn’t hurt either. XBRL may well be a great for­mat which is ideal for con­sis­tent, com­pa­ra­ble, and process­able finan­cial report­ing, but it’s miles away from any­thing an accoun­tant would actu­ally want to use or understand.

On a global scale, iXBRL is going to be a big deal pri­mar­ily because it solves the kind of prob­lems that the US have been endur­ing for years. The largest cor­po­ra­tions in Amer­ica have to file their 10-K and 10-Q reports to the SEC, but they have to file two copies of their returns: one in XBRL for­mat, and one in HTML for­mat. One pro­vides struc­tured data, and the other merely allows the ana­lysts who have been rely­ing on read­able returns for decades to con­tinue doing their jobs. This leaves us in a hor­ri­ble half-way house, with dupli­ca­tion of effort (and data!) plus a bor­ing, tire­some job com­par­ing the two doc­u­ments to ensure that they are con­sis­tent. Worse, it means that every­one can ignore the XBRL fil­ings for a few more years and work with the same HTML EDGAR fil­ings they’re already com­fort­able with—reducing the impe­tus for com­pa­nies to pro­duce high-quality XBRL returns.

In the UK, the sharp charge to iXBRL has deliv­ered all of the ben­e­fits of HTML and XBRL for­mats while cut­ting out the draw­backs of being forced to pre­pare both. I’d be will­ing to bet that even though the UK is the first coun­try to make the leap to iXBRL, it won’t be the last.

Wel­come to the world stage, iXBRL. You’re a wel­come addi­tion to the sta­ble of finan­cial report­ing for­mats, and I bet you’ll also be one of the most durable.