Freestyle Reporting with Inline XBRLA UK Company Tax Online Filing Case Study

Andy GreenerEnterprise Architect, HMRC IMS Strategy & Architecture

19th XBRL International Conference - June 2009 - 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+

0

2,000,000

2001 Aware of XBRL v1.0, v2.0 just emerging…CT600 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.

1st Candidate Rec published in July. UK GAAP published

2009 Mandated Inline XBRL for Returns from third-party filing

applications. 4th Candidate Rec published in April

2011 Mandation from April

2012 First 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

• 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

v0.1 (0.5Mb) v1.16 (12Mb) v1.21 (17Mb)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

• 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 --> 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='rowName'> <i>Use of derivatives</i> </td> </tr> <tr> <td colspan='100' class='rowName'><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.</ix:nonNumeric></td> </tr>

<uk-gaap-pt:FinancialInstrumentsRisksFree-textComment contextRef="FY2008"> 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:FinancialInstrumentsRisksFree-textComment>

iXBRL

Use of derivativesXBRL-TESTCO uses forward foreign currency contracts to reduce exposure to the variability of foreign exchangerates by fixing the rate of any material payments in a foreign currency.

Rendered

XBRL

<tr> <td class='rowName' /> <td class='rowName'>Depreciation</td> <td /> <td> <ix:nonFraction ix:contextRef='FY2007' ix:decimals='2’ ix:format='ixt:numcommadot’ ix:name='ct-CaseI:TradingProfitsIndividualTradeAdjustmentsDepreciation’ ix:unitRef='GBP'>347,375.00</ix:nonFraction> </td> </tr>

Non-Fractional Numeric data (example from Comp sample)

<ct-CaseI:TradingProfitsIndividualTradeAdjustmentsDepreciation contextRef="FY2007" decimals="2" unitRef="GBP">347375.00</ct-CaseI:TradingProfitsIndividualTradeAdjustmentsDepreciation>

Depreciation 347,375.00 Rendered

iXBRL

XBRL

<tr> <td class='rowName'>Date</td> <td id='DateSigningDirectorsReport' colspan='2'> <ix:nonNumeric ix:contextRef='FY20082'

ix:name='uk-gaap-pt:DateSigningDirectorsReport’ ix:format='ixt:datelonguk'>15 July 2008</ix:nonNumeric>

</td> </tr>

Dates (example from Accounts sample)

<uk-gaap-pt:DateSigningDirectorsReport contextRef="FY20082">2008-07-15</uk-gaap-pt:DateSigningDirectorsReport>

iXBRL

Date 15 July 2008Rendered

XBRL

Fractions (synthesised example)

iXBRL

XBRL

RenderedA1 Apportionment fraction for FY1 90 / 365

<tr> <td> <a href='#A1'>A1</a> </td> <td class='label'>Apportionment fraction for FY1</td> <td></td> <td align='right'> <ix:fraction ix:contextRef='NFC1’ ix:name='ct-Tax:CalculationOf…ApportionmentFraction' ix:unitRef='pure'> <ix:numerator>90</ix:numerator> / <ix:denominator>365</ix:denominator> </ix:fraction> </td></tr>

<ct-Tax:CalculationOf…ApportionmentFraction contextRef=“NFC1” unitRef=“pure”><xbrli:numerator>90</xbrli:numerator><xbrli:denominator>365</xbrli:denominator>

</ct-Tax:CalculationOf…ApportionmentFraction>

Tuples (example from Accounts sample)

<td class='rowName'> <b><i><ix:nonNumeric ix:contextRef='FY2008’ ix:name='uk-gaap-pt:TitleOtherSpecificAccountingPolicy' ix:order='1' ix:tupleRef='tuple.3'>Pensions</ix:nonNumeric></i></b> </td>

<td colspan='100' class='rowName'> <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:nonNumeric> </td>

<ix:hidden> <ix:tuple ix:name='uk-gaap-pt:OtherSpecificAccountingPolicy-Details’ ix:tupleID='tuple.3’> …</ix:hidden>

Firstchild

Secondchild

.

.

.

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 schemaRef and

linkbaseRef elements which are required by the target XBRL instance. --> <ix:references>

… </ix:references> <!-- The ix:resources element is used to contain XBRL roleRef, arcroleRef,

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