2. Hiding the Angle Brackets Rendering XBRL for compliance professionals and regulators Lucian Holland 27 April 2005

3. Introductions  About DecisionSoft  Leading supplier of XBRL technology and consulting to regulators worldwide  Industry standard True North Validator  About me  Technical Architect responsible for True North  Regular contributor to XBRL and XML conferences

4. Presentation overview  The rendering problem  Requirements  Challenges  Look at available solutions  Focus on one promising possibility

5. This is some very tiny text that is supposed to be part of the report that is on display. ??**£$&%! The CFO’s Dilemma <usfr-pt:MarketableSecurities AvailableSecuritiesCurrentNon current precision=“INF” contextRef =“Inst2002” unitRef=“USDollar”> 23445182</usfr-pt:MarketableSecurities AvailableSecuritiesCurrentNoncurrent> <usfr-fst:LoansHeldSale precision=“INF” contextRef=“Inst2002” unitRef=“USDollar” >7747793 <usfr-fst: LoansLoansHeldPortfolio precision=“INF” contextRef="Inst2002“ unitRef="USDollar"> 73167935 <usfr-fst:NetLoansAllowanceLoanLeaseLosses precision=“INF” contextRef=“Inst2002” unitRef= “USDollar”>930114</usfr-fst:NetLoansAllowanceLoan LeaseLosses>

6. The need for readability  The CFO wants to read what he’s sending out  Regulators want to cross-check reports flagged for closer inspection  Analysts and investors want to see the entity’s own presentation as well as the new analyses made possible by XBRL  Key driver for adoption – people must be able to “see inside” the XBRL

7. Requirements for rendering  Comprehensible to the non-XBRL-literate  XBRL is not human-readable  XBRL does things differently to traditional presentations  Needs a robust “sign-off” mechanism  Get to the point where the XBRL can be audited?  Transparent mapping between rendering and XBRL  Information mustn’t be able to change after sign-off  Signing must be integrated to be of real use  Portability  No specialist software at point of consumption  Needs to be lightweight

8. Challenges  Dimensions  Rendering patterns  Segmentation of information

9. Dimensions  XBRL supports multi-dimensional information  Will soon support even more with new Dimensional Taxonomies work  Which dimensions should you use for display?  Facts can be positioned on 3,4,5 (…100?) dimensions at once – which ones should be used?  Dimensions built-in to existing report layouts  XBRL will often be generated from such layouts (e.g. Excel); dimensional structure gets “lost in translation”  Taxonomy authors have minimal control  Almost no interaction possible between semantic structure of taxonomy and dimensions expressed in reports.

10. Dimensions: an example USUK 2004 Sales20001000 Costs200100 Profit1800900 2005 Sales30002000 Costs300200 Profit27001800 2005 (Actual) 2005 (Projected) 2004 (Actual) Division 1 Sales500400300 Division 2 Sales15001200700 Total Sales1600 Division 1 Costs504030 Division 2 Costs15012070 Total Costs160 World-wide overview UK report 2000 1000 200 100 Period: 2004 Segment: US Total Scenario: Actual Period: 2004 Segment: US Total Scenario: Actual Period: 2005 Segment: US Total Scenario: Actual Period: 2005 Segment: US Total Scenario: Actual Period: 2005 Segment: UK Total Scenario: Actual Period: 2005 Segment: UK Total Scenario: Actual Period: 2004 Segment: UK Total Scenario: Actual Period: 2004 Segment: UK Total Scenario: Actual

11. Movement analysis  A specific problem with dates in XBRL  Relationship between fact and date changes semantics: beginning vs.end  No way to make this explicit in standard XBRL  Perhaps should be fixed at a specification level, but unlikely to happen soon  Important for rendering  Will require tool support, along with more metadata

12. Movement analysis: an example Taxonomy Movement analysis Balance Change in balance periodType: Instant periodType: Duration Report Movement analysis Balance=100 Balance=200 Balance=250 Balance=200 Balance=100 Change=100 Change=50 Change=-100 Date: 2004-04-01 Scenario: Actual Date: 2004-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Date: 2005-04-01 Scenario: Actual Date: 2005-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Projected Date: 2004-10-01 Scenario: Projected Date: 2005-04-01 Scenario: Projected Date: 2005-04-01 Scenario: Projected Period: H1 2004-5 Scenario: Actual Period: H1 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Projected Period: H2 2004-5 Scenario: Projected

13. 2004-04-01 – 2004-10-01 250 Ending Balance 50 Profits 200 Starting Balance 2004-10-01 – 2005-04-01 200 Ending Balance 100 Profits 100 Starting Balance 2004 Actual Movement analysis example continued Movement analysis Balance=100 Balance=200 Balance=250 Balance=200 Balance=100 Change=100 Change=50 Change=-100 Date: 2004-04-01 Scenario: Actual Date: 2004-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Date: 2004-10-01 Scenario: Actual Date: 2005-04-01 Scenario: Actual Date: 2005-04-01 Scenario: Actual Date: 2004-10-01 Scenario: Projected Date: 2004-10-01 Scenario: Projected Date: 2005-04-01 Scenario: Projected Date: 2005-04-01 Scenario: Projected Period: H1 2004-5 Scenario: Actual Period: H1 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Actual Period: H2 2004-5 Scenario: Projected Period: H2 2004-5 Scenario: Projected 2004-10-01 – 2005-04-01 200 Ending Balance 100 Profits 100 Starting Balance 2004 H2 Projected

14. Segmentation  Presentation linkbase only gives a hierarchy  No indication of how to split into tables/sections  As discussed, no link to date, segment or scenario dimensions  Unclear what to do when information is missing  Already a problem for calculations in US-GAAP sample preparation  Will be problematic for rendering as well – how to present a hierarchical structure when some parts may be missing?

15. Presentation overview  The rendering problem  Requirements  Challenges  Look at available solutions  Focus on one promising possibility

16. The shape of a solution  Must handle complex processing – simple transformations inadequate  Will need significant metadata:  “Patterns” – identify standard ways of expressing information and define renderings (e.g. describe the XBRL “shape” of a movement analysis)  “Hints” – allow authors of taxonomies or instances to specify rendering in more detail (e.g. identify specific elements used for movement analysis)  Must be possible for non-technical domain experts to define and shape this metadata

17. Possible solutions: Rekeying  Requires no technology investment  Unreliable  Expensive  Huge maintenance cost  Assumes that XBRL is not the primary format 343563789B 222323432423A 2643944799C 43 3 338 1 5799D 2 Spreadsheet Report

18. Distributable Package Possible solutions: Standalone HTML  Portable, open standard  Signing possible, but not built-in  Not an integrated solution, lacks a lot of features  Hard for domain experts to define format  Every report must pass through renderer Processor Report 343563789B 222323432423A 2643944799C 43 3 338 1 5799D 2

19. Web Browser Distributable Package Possible solutions: XSLT  Widely available, standard and light weight  Rendering can be generated by end user  Can’t sign final rendering  Poor support/performance for complex processing  Nightmarishly difficult to support extension taxonomies  Specialist technical knowledge required to write  Works best for “closed form” solutions Report 343563789B 222323432423A 2643944799C 43 3 338 1 5799D 2

20. Presentation overview  The rendering problem  Requirements  Challenges  Look at available solutions  Focus on one promising possibility

21. The real answer: PDF  “PDF – isn’t that just a static rendering format?”  Can contain a wide variety of machine-readable data including XML  Dynamic layouts that restructure based on XML data  Interactive controls  Sophisticated document management including element-level digital signing

22. PDF: Encapsulating an XBRL instance Report PDF Report  Rich client, ubiquitously available  Already a standard medium for accounts presentation  Rendering driven directly from the data  Signing the rendered form signs the data  Can support complex document workflows  Sophisticated design environments

23. Conclusions  Rendering XBRL poses a lot of challenges technically, logically and on a business level  The obvious solutions aren’t necessarily the right ones!  In general terms, the way forward is to look for “patterns” of standard usage and build rendering support for them  May even lead to a formal specification in the long run  However the “shape” of the output is defined, PDF has the edge as a delivery mechanism: power, flexibility and ubiquitous deployment

24. Thanks for listening!