Freestyle Reporting with Inline XBRL A UK Company Tax Online Filing Case Study Andy Greener Enterprise Architect, HMRC IMS Strategy & Architecture 19th XBRL International Conference - June Paris

Background UK CT is an annual self-assessment regime CT Filing Requirements: –A CT600 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 CT600 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 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 300, ,000, Aware of XBRL v1.0, v2.0 just emerging… CT600 XML Schema proposed + PDF Tax Comp & Accts 2003Live service launched with a plan to migrate PDF Tax Comps and Accts to XBRL in due course. Began development of Tax Computation Taxonomy 2005Live service updated to accept XBRL Tax Comps 2006Carter Report recommends mandatory online filing using XBRL for Tax Comps and Accounts 2008Became aware of Inline XBRL proposal and supported it. 1st Candidate Rec published in July. UK GAAP published 2009Mandated Inline XBRL for Returns from third-party filing applications. 4th Candidate Rec published in April 2011Mandation from April 2012First full year of mandatory online filing Submissions

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 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) v0.1 (0.5Mb)v1.16 (12Mb)v1.21 (17Mb) concepts2,000 concepts3,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 A method of embedding encoded XBRL mark-up as metadata in an XHTML (or HTML) document 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 human- consumable rendering Opportunity to assure correspondence (via a GUI)

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 --> or ,00 --> –e.g. 17 October 2009 or Oct 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) Use of derivatives <ix:nonNumeric ix:contextRef='FY2008' ix:name='uk-gaap-pt:FinancialInstrumentsRisksFree-textComment'> 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-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. iXBRL Use of derivatives 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. Rendered XBRL

Depreciation <ix:nonFraction ix:contextRef='FY2007' ix:decimals='2’ ix:format='ixt:numcommadot’ ix:name='ct-CaseI:TradingProfitsIndividualTradeAdjustmentsDepreciation’ ix:unitRef='GBP'>347, Non-Fractional Numeric data (example from Comp sample) <ct-CaseI:TradingProfitsIndividualTradeAdjustmentsDepreciation contextRef="FY2007" decimals="2" unitRef="GBP"> Depreciation347,375.00Rendered iXBRL XBRL

Date <ix:nonNumeric ix:contextRef='FY20082' ix:name='uk-gaap-pt:DateSigningDirectorsReport’ ix:format='ixt:datelonguk'>15 July 2008 Dates (example from Accounts sample) iXBRL Date15 July 2008 Rendered XBRL

Fractions (synthesised example) iXBRL XBRL RenderedA1Apportionment fraction for FY1 90 / 365 A1 Apportionment fraction for FY1 <ix:fraction ix:contextRef='NFC1’ ix:name='ct-Tax:CalculationOf…ApportionmentFraction' ix:unitRef='pure'> 90 /

Tuples (example from Accounts sample) <ix:nonNumeric ix:contextRef='FY2008’ ix:name='uk-gaap-pt:TitleOtherSpecificAccountingPolicy' ix:order='1' ix:tupleRef='tuple.3'>Pensions <ix:nonNumeric ix:contextRef='FY2008’ ix:name='uk-gaap-pt:ContentOtherSpecificAccountingPolicy' ix:order='2’ ix:tupleRef='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:tuple ix:name='uk-gaap-pt:OtherSpecificAccountingPolicy-Details’ ix:tupleID='tuple.3’> … First child Second child......

All the invisible stuff… … <!-- The ix:hidden element is used to contain XBRL facts that are not to be displayed in the Inline XBRL Document. --> … <!-- The ix:references element is used to contain XBRL schemaRef and linkbaseRef elements which are required by the target XBRL instance. --> … <!-- The ix:resources element is used to contain XBRL roleRef, arcroleRef, context or unit elements which are required by the target XBRL instance. --> …

Commercial Software Vendors We are heavily dependent on 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