Freestyle Reporting with Inline XBRL A UK Company
Freestyle Reporting with Inline XBRL A UK Company Tax Online Filing Case Study 19 th XBRL International Conference - June 2009 - Paris Andy Greener Enterprise Architect, HMRC IMS Strategy & Architecture
Background • UK CT is an annual self-assessment regime • CT Filing Requirements: – A CT 600 Return form (plus up to 10 supplementary “pages”) – Declaration, liability and summary of liability calculation – Supporting Financial Statements – Full Statutory Accounts (inc a P&L, Balance Sheet, etc) – Tax Computation (full liability calculation) – Other relevant supporting documentation
Background continued • The CT 600 form (and supplementary pages) lend themselves well to a “traditional” structured XML solution • But the Financial Statements have no prescribed format - there is much custom and practice: Finance Act, 1998, Sch 18, Company tax return 3 (1) The Inland Revenue may by notice require a company to deliver a return (a “company tax return”) of such information, accounts, statements and reports (a) relevant to the tax liability of the company, or (b) otherwise relevant to the application of the Corporation Tax Acts to the company, as may reasonably be required by the notice.
History of CT Online Filing 2001 Aware of XBRL v 1. 0, v 2. 0 just emerging… CT 600 XML Schema proposed + PDF Tax Comp & Accts 2003 Live service launched with a plan to migrate PDF Tax Comps and Accts to XBRL in due course. Began development of Tax Computation Taxonomy 2005 Live service updated to accept XBRL Tax Comps 2006 Carter Report recommends mandatory online filing using XBRL for Tax Comps and Accounts 2008 Became aware of Inline XBRL proposal and supported it. 1 st Candidate Rec published in July. UK GAAP published 2009 Mandated Inline XBRL for Returns from third-party filing applications. 4 th Candidate Rec published in April 2011 Mandation from April 2012 First full year of mandatory online filing Submissions 0 300, 000+ 2, 000
The CT Online Filing Service • Approx 20% of filers use the HMRC Portal – This is migrating from an online forms application to an offline intelligent form in October – PDF Tax Comps and Accounts are “uploaded” to the form • The rest use commercial filing packages to submit an XML-based transaction to HMRC – Often with the support of specialised production packages for the “attached” Tax Comps and Accounts - at present these are almost exclusively PDF-based, for human consumption
Why Present For Human Consumption? • Automated risk rules (dependent on marked-up data) rarely identify specific risk cases • The best we can do is eliminate uninteresting cases, to leave a “needle-rich haystack” • Experienced inspectors still need to work these cases, and need to see them in a familiar form • Investigations require dialog between HMRC and the Company, with reference to documents that both have access to - rendering consistency is vital
The “traditional” Rendering Approach • 2005 - XBRL Tax Computations supported by XSLT stylesheet for rendering to HTML – Basic semi-automatically generated stylesheet, austere format user-supplied stylesheets considered too much of a security risk – Even so, the stylesheet was large and hard to maintain – It was clearly going to be difficult to handle all the “corner cases”, oddities and every last Taxonomy item, not to mention private company Extension Taxonomies (required for raw XBRL filing of all but the most straightforward companies’ Tax Computations) 2004 2007 2009 v 0. 1 (0. 5 Mb) v 1. 16 (12 Mb) v 1. 21 (17 Mb) 2 -300 concepts 2, 000 concepts 3, 500+ concepts
Extending Taxonomies - for what? • Existing disclosure requirements are not affected by online filing – Every last piece of disclosable data, down to the most detailed schedules (e. g. company cars) needs to be reported – XBRL needs to be stretched to its very limits to cope, with liberal use of private company Extension Taxonomies – But the original intention of Lord Carter’s recommendation was to enable automated risk analysis allowing better targeting of resources, along with the collection of structured data for statistics, economic forecasting, etc – We were only ever going to use a core set of data items for automated risk rules (mostly confined to the base Taxonomies) so most of the data supplied via Extensions is only of use to humans…
Why Inline XBRL? • Coercing everything into XBRL and then building complex rendering solutions for it just so humans could read the detail seemed pointless • Inline XBRL provides a much closer and more efficient requirements “match” – Detail can be rendered for human consumption only – That data which needs marking-up can be marked up – Producers are free to define the look & feel, branding, etc – Heavyweight transformative rendering technology is not required
Inline XBRL - What Is It? • • A Specification of the XII Rendering Working Group • Data item content is rendered by the browser, encoded XBRL mark-up is ignored • Encoded mark-up and data can be easily extracted and transformed to “raw” XBRL • One document contains both structured data and humanconsumable rendering • Opportunity to assure correspondence (via a GUI) A method of embedding encoded XBRL mark-up as metadata in an XHTML (or HTML) document
The Benefits For Our Use-Case • Addresses the rendering issue by putting it back in the hands of the producing application, where it belongs – Current production applications control layout, look & feel, branding, etc. , for paper and PDF output - why should XBRL be any different? – Both creator and recipient are guaranteed the same/close enough rendering • Eliminates the need for private Extensions (mostly) – Not all disclosable information needs to be marked up – Detail needs to be human-readable, not machine-readable – Extension Taxonomies may still be needed where existing Dimensions are extended or new Dimensions/Hypercubes are required
Inline XBRL Format Transformation • Date and numeric values are often ‘visually adorned’ for human consumption – e. g. thousands separators (comma, dot, space - regional/cultural variants) • but must be transformed to canonical form for XBRL – e. g. 3, 400, 000 --> 3400000 or 3. 400. 000, 00 --> 3400000. 00 – e. g. 17 October 2009 or Oct 17, 2009 --> 2009 -10 -17 • Part 3 of the Spec: the Transformation Rules Registry – Extensible set of transformation rules – Mapping of human conventions to canonical data formats
Statutory Accounts & Computations Samples - demo
Non-Numeric data (example from Accounts sample) <tr> <td class='row. Name'> <i>Use of derivatives</i> </td> </tr> <td colspan='100' class='row. Name'><ix: non. Numeric ix: context. Ref='FY 2008' ix: name='uk-gaap-pt: Financial. Instruments. Risks. Free-text. Comment'> XBRL-TESTCO uses forward foreign currency contracts to reduce exposure to the variability of foreign exchange rates by fixing the rate of any material payments in a foreign currency. </ix: non. Numeric></td> </tr> Use of derivatives i. XBRL Rendered XBRL-TESTCO uses forward foreign currency contracts to reduce exposure to the variability of foreign exchange rates by fixing the rate of any material payments in a foreign currency. <uk-gaap-pt: Financial. Instruments. Risks. Free-text. Comment context. Ref="FY 2008"> XBRL-TESTCO uses forward foreign currency contracts to reduce exposure to the variability of foreign exchange rates by fixing the rate of any material payments in a foreign currency. XBRL </uk-gaap-pt: Financial. Instruments. Risks. Free-text. Comment>
Non-Fractional Numeric data (example from Comp sample) <tr> <td class='row. Name' /> <td class='row. Name'>Depreciation</td> <td /> <td> <ix: non. Fraction ix: context. Ref='FY 2007' ix: decimals='2’ ix: format='ixt: numcommadot’ ix: name='ct-Case. I: Trading. Profits. Individual. Trade. Adjustments. Depreciation’ ix: unit. Ref='GBP'>347, 375. 00</ix: non. Fraction> </td> </tr> Depreciation 347, 375. 00 i. XBRL Rendered <ct-Case. I: Trading. Profits. Individual. Trade. Adjustments. Depreciation context. Ref="FY 2007" decimals="2" unit. Ref="GBP">347375. 00</ct-Case. I: Trading. Profits. Individual. Trade. Adjustments. Depreciation> XBRL
Dates (example from Accounts sample) <tr> <td class='row. Name'>Date</td> <td id='Date. Signing. Directors. Report' colspan='2'> <ix: non. Numeric ix: context. Ref='FY 20082' ix: name='uk-gaap-pt: Date. Signing. Directors. Report’ ix: format='ixt: datelonguk'>15 July 2008</ix: non. Numeric> </td> </tr> Date i. XBRL 15 July 2008 Rendered <uk-gaap-pt: Date. Signing. Directors. Report context. Ref="FY 20082">2008 -07 -15</uk-gaap-pt: Date. Signing. Directors. Report> XBRL
Fractions (synthesised example) <tr> <td> <a href='#A 1'>A 1</a> </td> <td class='label'>Apportionment fraction for FY 1</td> <td></td> <td align='right'> <ix: fraction ix: context. Ref='NFC 1’ ix: name='ct-Tax: Calculation. Of…Apportionment. Fraction' ix: unit. Ref='pure'> <ix: numerator>90</ix: numerator> / <ix: denominator>365</ix: denominator> </ix: fraction> </td> </tr> A 1 Apportionment fraction for FY 1 90 / 365 <ct-Tax: Calculation. Of…Apportionment. Fraction context. Ref=“NFC 1” unit. Ref=“pure”> <xbrli: numerator>90</xbrli: numerator> <xbrli: denominator>365</xbrli: denominator> </ct-Tax: Calculation. Of…Apportionment. Fraction> i. XBRL Rendered XBRL
Tuples (example from Accounts sample) <ix: hidden> <ix: tuple ix: name='uk-gaap-pt: Other. Specific. Accounting. Policy-Details’ ix: tuple. ID='tuple. 3’> … </ix: hidden> First child <td class='row. Name'> <b><i><ix: non. Numeric ix: context. Ref='FY 2008’ ix: name='uk-gaap-pt: Title. Other. Specific. Accounting. Policy' ix: order='1' ix: tuple. Ref='tuple. 3'>Pensions</ix: non. Numeric></i></b> </td>. . . <td colspan='100' class='row. Name'> <ix: non. Numeric ix: context. Ref='FY 2008’ ix: name='uk-gaap-pt: Content. Other. Specific. Accounting. Policy' ix: order='2’ ix: tuple. Ref='tuple. 3'>The company makes contributions to a group personal pension scheme on behalf of its employees. Contributions are charged to the profit and loss account as they become due, in accordance with the rules of the scheme. </ix: non. Numeric> </td> Second child
All the invisible stuff… <html version='-//XBRL International//DTD XHTML Inline XBRL 0. 1//EN' xmlns=. . . . > <head> … </head> <body xml: lang='en'> <div style='display: none'> <ix: header> <!-- The ix: hidden element is used to contain XBRL facts that are not to be displayed in the Inline XBRL Document. --> <ix: hidden> … </ix: hidden> <!-- The ix: references element is used to contain XBRL schema. Ref and linkbase. Ref elements which are required by the target XBRL instance. --> <ix: references> … </ix: references> <!-- The ix: resources element is used to contain XBRL role. Ref, arcrole. Ref, context or unit elements which are required by the target XBRL instance. --> <ix: resources> … </ix: resources> </ix: header> </div>
Commercial Software Vendors • We are heavily dependent on 30 -40 vendors to integrate Inline XBRL into their products – Principally by re-purposing existing formatted output capability to generate XHTML and embed Inline XBRL mark-up • Many are already well into their development cycle and actively using our test service – Where software is already used, companies are dependent on their existing software providers to step up to the mark – Where software is not used (other than word-processors or spreadsheets), the step-up is bigger, and requires specialised software for the first time
Summary • UK CT software providers are gearing up for Inline XBRL submission of Tax Comps and Accounts from Oct 2009 onwards, working towards mandation in 2011 • Inline XBRL suits our specific use-case very well and provides the right balance between disclosure requirements and mark-up requirements • Transformative rendering (stylesheets, formatting linkbases, etc) have their place in more formulaic applications
Questions? Thank you - you can also send questions to me at andy. greener@hmrc. gsi. gov. uk
- Slides: 22