What if XBRL was deeply integrated into business and financial information systems?

Most companies have address the SEC’s XBRL filing requirements using a compliance based approach. Rather that trying to complete the effort in-house, many have relied on third party vendors to do the heavy lifting on XBRL. The result has been that companies are forced into timelines provided by their partner. The real question has become “Are companies managing their XBRL service provider or is the service provider managing them”?

Imagine a different scenario where companies integrate XBRL into existing systems. The existing consolidation process could generate much of the XBRL required for SEC filings. Additional supplemental information could be generated in a separate system, tagged with XBRL then used in connection with the consolidated XBRL to automate “the last mile of finance”. An Integrated approach like this one could free financial reporting professionals from some of the transactional work involved in filing a 10-Q or 10-K thereby allowing them the time for higher value analytical and advisory work.

What if XBRL creation could be completed with an easy to understand graphical user interface?

XBRL is still a new technology, barely over 10 years old in its development as a global standard. There are many powerful software tools available, but the long awaited easy to us semantic based approach to XBRL generation still escapes the imagination of many software providers. If an innovative software provider were able to take the technical syntax based decisions out of XBRL creation and provide such a tool with an easy to understand graphical user interface, XBRL creation would be a much easier process that many would choose to create internally.

What if traditional Edgarized SEC filings ceased and XBRL were the only filing format required by the SEC?

XBRL filings currently provide all of the same financial statement and footnote information traditional filings provide. In fact, when the SEC mandated XBRL, it insisted that the XBRL format was a change in filing format NOT a change in filing requirements. If XBRL was mandated for entire 10-Q and 10-K filings, traditional Edgarized filings could cease entirely. If XBRL were the only format required by the SEC, would companies finally embrace the idea of bringing XBRL in house? Would XBRL technologies finally be used to rationalize data flow within organizations? A change like this would certainly cause companies to revisit their XBRL creation approaches.

What if XBRL could be easily consumed by software tools that allowed users to pivot data and dive into the deeper details?

If there were software tools available to easily consume XBRL filings via RSS feed or directly from public websites, investors would likely begin to use XBRL data in lieu of more expensive aggregator provided data. If such a tool also provided robust analytical features like pivot tables, sub-totaling, filtering and similar functions investors and analysts would seek the tool and begin to demand easy access to XBRL data. Perhaps this would cause companies to embrace XBRL as a way of sharing information internally and externally.

What else could be done with XBRL? How else might XBRL be generated and used in the future? Please share your thoughts by commenting on this post.

The 2011 IFRS Taxonomy is based on IFRS as issued at January 1, 2011. The interim release of the IFRS Taxonomy contains additional taxonomy concepts that reflect new IFRS standards and improvements to existing IFRS standards published by the IASB. The interim taxonomy release gives companies the opportunity to report XBRL financial concepts using the latest IFRS standards without creating custom taxonomy elements.

The interim release of the 2011 IFRS Taxonomy follows the taxonomy architecture in The IFRS Taxonomy 2011 Guide and The Global Filing Manual.

XBRL Data in Use

A recent demonstration of XBRL is on the XBRL US Website at http://xbrl.us/research/Pages/data.htm. The tool allows users to see a graphical display of selected XBRL data broken down by year, by quarter, by selected financial concepts and by selected industry.

Brix iPhone App

XBRL US has another free tool that is available to iPhone users. The XBRL iPhone App, called “Brix” or “The Brix Project”, allows users to browse XBRL filings on an iPhone. Filings on the Brix App can be browsed by company or by taxonomy element. The tool also shows the most recent XBRL filings and tracks the total number of companies that file XBRL reports with the SEC as well as the total number of XBRL reports filed to date. The iPhone Brix App can be found at on the XBRL US website at http://xbrl.us/research/Pages/iphone.aspx.

Sample XBRL Data Issues

XBRL US has yet a third tool to inform XBRL users about the most common XBRL error types. The foundation of this site is the XBRL US Consistency Suite which is being used to test the validity and consistency of filings and saving the filing results in an XBRL database. The sample of common XBRL data issues is listed at http://www.xbrl.us/research/Pages/CSuiteSample.aspx. In addition, a count of the number of errors by type is shown on the lower right of the Consistency Suite page at http://xbrl.us/research/pages/Csuite.aspx.

The SEC’s Financial Explorer

Another interesting tool is the SEC’s Financial Explorer (http://209.234.225.154/viewer/home/). The Financial Explorer graphically represents XBRL filing data in a way that non-financial users may find beneficial.

Prime Aim

Prime Aim offers a user friendly XBRL query tool to enable the public to search XBRL filings. The tool is found at http://primeaim.com/ and offers assistance in helping users learn how to use the site. There are Advanced and Browse options as well as a help page and “how to” page.

Reporting Standard Query

Reporting standard has a tool that allows users to write their own queries of XBRL SEC filings. Filings that match the query criteria ar accessable from the query tool which can be found here: http://www.xbrl4.org/regulators/ExploreXBRL.html

XBRL Calculation Issues

XBRL Site, a Chalie Hoffman creation, offers a listing of possible XBRL calculation issues by filing company. The site allows links to the specific calculations that it highlights. Users should be aware that there are occasions when XBRL calculations may not work for valid reasons (like the total being a rounded amount as opposed to an exact amount). The list of possible calculation errors can be found at http://www.xbrlsite.com/demos/Analysis/2009-11-15/Viewer/Other/CalculationIssues.html.

Financial Filing Glossary and Logical Model

Another Charlie Hoffman site summerizes the SEC’s XBRL Logical Model and Provides a Glossary of SEC Filer XBRL terms. There are links throughout the site to take filers to the details of each topic covered. The site may be found at http://secxbrlglossary.wikispaces.com/.

XBRL Cloud

XBRL Cloud analyzes SEC filings and highlights the number of validation errors, warnings, and best practices. I was previously under the impression that XBRL Cloud used its own validation criteria, but thanks to direct contact with XBRL Cloud, I am happy to say that XBRL Cloud goes to great lengths to present findings based on publicly published documents such as the SEC’s EDGAR Filing Manual, and the US GAAP Architecture. Because the validation techniques are based in open and widely recognized standards, companies that have good report on XBRL Cloud can have confidence that their XBRL filings meet required standards. The beauty of XBRL Cloud is that companies, investors and other interested users see a “report card” on how companies are doing with their XBRL SEC filings. The site can be found at http://edgardashboard.xbrlcloud.com/.

Other XBRL Tools

There are other interesting XBRL tools available as well, including a Firefox XBRL add-on (https://addons.mozilla.org/en-US/firefox/addon/xbrl-addon/) that allows users to pivot XBRL data, multiple XBRL taxonomy viewers (http://viewer.xbrl.us/yeti2/resources/yeti-gwt/Yeti.jsp, http://bigfoot.corefiling.com/yeti/resources/yeti-gwt/Yeti.jsp, http://www.fasb.org/jsp/FASB/Page/SectionPage&cid=1176157088011, http://www.compsciresources.com/ – lower right side of page). Even Microsoft Office contains capabilities to help XBRL users access XBRL tagged data.

 The number of available XBRL tools will continue to grow as XBRL use expands around the globe. Already XBRL is being used in SEC filings and Bank FDIC Call Reports in the US, Tax Returns in the United Kingdom, a securities filings in China, stock exchange listings in Tokyo and more. XBRL use will not be limited to financial reporting. Projects are underway to apply XBRL to environmental and sustainability efforts, risk management projects and governmental transparency efforts. To see what’s going on in the world of XBRL see XBRL Planet at http://www.xbrlplanet.org/index.php.

I am sure there are other XBRL tools as well. If you know of other helpful XBRL tools that demonstrate the power of XBRL please share them by adding a comment to this post.

Before determining how to tag a dash, it is important to think about the role of  line item tags within the US GAAP Taxonomy. When a concept is tagged, all of the line item facts for that concept (i.e. in that line item or row) are tagged with the same element no matter what calendar they are in (i.e. what point in time or period of time the facts relate to). Since all of the amounts in that row or line are tagged with the same element, then any dash in that row is associated with the element as well. However, the dash is unique and needs additional consideration.

Companies may use a dash to represent different concepts. Most often it is thought to represent an insignificant undisclosed amount. Other times the dash may represent zero. It is essential to understand what the dash actually means before deciding how to tag it. If the dash actually represents a zero, then it can be tagged as a zero in the same way any other amount is tagged. If the dash represents an insignificant or immaterial undisclosed amount, then it needs a nil=true attribute. By assigning the nil=true to the period that contains the dash, the amount is understood to be “null” or “nil” (empty – not zero). The calendar with the nil=true attribute renders as a blank or empty field in the SEC’s viewer.

When the dash actually represents a zero, then a zero is tagged (not a dash) and the nil=true attribute does not apply. In this case, the amount is a zero and renders as a zero for the period that contains a dash in the traditional filing.

US GAAP Taxonomies were developed and maintained by XBRL US until early 2010. In February 2010, the Financial Accounting Foundation and the Financial Accounting Standards Board (together the “FASB”) assumed responsibility for maintaining and updating the US GAAP Taxonomy (“UGT”). Typically, a new UGT is released once each year. However, with the ownership of the UGT transitioning from XBRL US to the FASB, a 2010 US GAAP Taxonomy was not released. Since assuming responsibility for the UGT, the FASB has made significant improvements in the taxonomy. The improvements include:

• Updates for the accounting standards that have been issued since the 2009 UGT was published
• Expanded disclosure for previous omissions, including common reporting practices observed in XBRL filings over the last couple of years
• Correction of errors and rationalization of duplicated concepts
• Updated architectural modeling of existing taxonomy structures (dimensional tables for example).

Modifications to the US GAAP Taxonomy were made with the intent of minimizing the impact to the instance documents of filers who have used the 2009 UGT while also making the necessary changes to improve the UGT. A new element label type has been added, the New Concept label type, to indicate where new taxonomy elements have been added. The new taxonomy elements have a New Concept label of “2011 New Element”.

Summary of Changes to the UGT

Many changes were made to US GAAP during the last two years. Naturally, changes in US GAAP since the 2009 taxonomy was released have been incorporated into the new taxonomy. Where there was not a significant change in the context of an element, the element name remains the same to facilitate migration to the 2011 UGT. For elements with significant definitional changes, new UGT elements replaced the old UGT elements or new elements were added to provide alternative elements for filers to use. Where UGT elements have been replaced, the old UGT elements have been deprecated (a way of retiring the element from use but retaining it’s history in the UGT). In addition, several new presentation groups have been added to the UGT including:

• 124200 – Statement of Income, Additional Statement of Income Elements
• 152201 – Statement of Cash Flows, Additional Cash Flow Elements
• 152205 – Statement of Cash Flows, Supplemental Disclosures
• 985000 – Other Industries
• 195000 – Comprehensive Text Block List

One of the more notable changes in the 2011 UGT is the Comprehensive Text Block List (Presentation Group 195000). In the previous taxonomy text block elements for XBRL mappings at level 1 (footnote text blocks), level 2 (significant accounting policy text blocks) and level 3 (table text blocks) were labeled in the same way. In general, they all had a suffix of “[Text Block]”. In the new UGT level 1 text block elements have the suffix “[Text Block]”, level 2 text block elements have the suffix “[Policy Text Block]” and level 3 text block elements have the suffix “[Table Text Block]”. Additionally, presentation groups 795000–Statement of Cash Flows Supplemental Disclosures and 993550–Form SH Investments Sold Not yet Purchased have been removed from the 2011 UGT.

Many dimensional elements (e.g. Axes, Domains and Members) within the 2011 UGT have been remodeled and rationalized to more accurately represent the dimensional structure of US GAAP disclosures in the financial statements and footnotes of SEC registrants. Also duplicate and redundant dimensions have been rationalized and new dimensions added to provide better extension taxonomy modeling.

Removal of Non-GAAP Elements

The 2009 UGT consisted of US GAAP elements and non-GAAP elements. Examples of Non-GAAP elements that were previously included in the taxonomy include SIC elements, entity elements and document information elements. The following non-GAAP groups have been removed from the 2011 UGT:

• 994400 – Document – SEC Certification
• 994600 – Document – Management Report
• 994800 – Document – Management Discussion and Analysis
• 995000 – Document – Accountants Report
• 995200 – Document – Document Information
• 995400 – Document – Entity Information
• 995410 – Document – Country Code
• 995420 – Document – State or Province
• 995430 – Document – Currency
• 995440 – Document – Exchange
• 995450 – Document – SIC
• 995460 – Document – NAICS
• 995470 – Document – Investment

Maintaining non-GAAP taxonomy groups will now be the responsibility of the SEC. Non-GAAP taxonomy elements will be maintained and available for use on the SEC’s website. To use both US GAAP and non-GAAP taxonomy components, filers will need to import each taxonomy group into their XBRL software tools. Both US GAAP and non-GAAP taxonomies are available on the SEC’s website at http://www.sec.gov/info/edgar/edgartaxonomies.shtml.

When Are Companies to Adopt the New UGT and What Factors Should Be Considered?

The SEC strongly encourages companies to migrate to the 2011 Taxonomy. The new Taxonomy is a significant improvement over the 2009 Taxonomy. Things to consider when migrating from the 2009 UGT to the 2011 UGT include:

• Companies should make an orderly transition from the 2009 Taxonomy to the 2011 Taxonomy
• Companies who have already mapped their data to the 2009 Taxonomy are permitted to continue using the 2009 Taxonomy for their filings
• The SEC will remove the 2009 Taxonomy from the approved taxonomy list at some point, but filers will have plenty of notice before they do.
• It is likely that filers who migrate to the new taxonomy will be able to reduce the number of extension they use in their taxonomies.

Some filers may believe that that they must begin using the new Taxonomy for periods ended after July 15, 2011. That language was included on the SEC’s XBRL Taxonomy Website, but it has been removed. As of March 30, 2011 the SEC’s website contains the following instructions about the 2011 US GAAP taxonomy:

“The SEC staff strongly encourages companies to use the most recent version of the US GAAP taxonomy release for their Interactive Data submissions to take advantage of the most up to date tags related to new accounting standards and other improvements. However, due to the timing of the release of the US GAAP 2011 taxonomy in conjunction with the phase-in of the Rule, companies will be permitted to continue to use the US GAAP 2009 taxonomy.”

Conclusion

Many positive improvements are included in the 2011 US GAAP taxonomy. New accounting standards have been incorporated, disclosures have been improved, errors and duplications have been rationalized and the dimensional structure of the taxonomy has been enhanced. Companies should begin planning and implementing an orderly migration to the 2011 UGT to take advantage of its superior ability to eliminate taxonomy extensions, improve extension taxonomy structures and normalize comparability of new US GAAP disclosures.

Over the last two years the larger SEC filers have implemented XBRL into their quarterly SEC reporting process. In 2011 Tier 1 companies (Note 1) will lose the XBRL liability limitation that existed during implementation. 2011 will also see Tier 2 companies (Note 1) implement detail footnote tagging and Tier 3 companies (Note 1) implement XBRL for the first time.

One big open item in the 2011 XBRL agenda is the IFRS Taxonomy. The SEC’s XBRL rule requires all foreign private issuers that prepare their financial statements in accordance with IFRS as issued by the IASB to file the XBRL exhibit to their SEC filings beginning with quarters ended after June 15, 2011. To do so, these filers would be required to use a taxonomy that is approved by the SEC (approved taxonomies are listed on the SEC’s website). The problem is that there is not an approved IFRS taxonomy listed on the SEC’s website.

The bottom line for foreign private issuers that prepare their financial statements in accordance with IFRS as issued by the IASB is that they will be required to file XBRL as part of their 20-F or 40-F filings, however they will be unable to file XBRL because there is not an approved IFRS taxonomy. An investigation of this issue with the SEC confirmed this understanding as true. There is a 2011 IFRS taxonomy that is exposed for comment until March 18, 2011. Hopefully the SEC will consider approving the new 2011 IFRS Taxonomy or will issue additional guidance clarifying expectations for foreign private issuers that prepare their financial statements in accordance with IFRS as issued by the IASB.

Stay tuned for further developments.

Note 1: Tier 1 companies are domestic and foreign large accelerated filers that use U.S. GAAP and have a worldwide public common equity float above $5 billion, Tier 2 companies are all other domestic and foreign large accelerated filers using U.S. GAAP and Tier 3 companies are all remaining filers using U.S. GAAP, including smaller reporting companies, and all foreign private issuers that prepare their financial statements in accordance with IFRS as issued by the IASB.

Use of negated labels for monetary US GAAP elements (commonly called “tags”) can be challenging. Negated labels are used to “flip” the sign of a rendered amount. By incorrectly using negated labels to flip the sign of an amount that was tagged backwards, some filers have made renderings look correct when the underlying values are actually backwards. Thinking about when to use a negated label can be facilitated by thinking about monetary tags as either “one way” monetary tags or “two way” monetary tags.

One way monetary tags are almost always expected to be either a debit or a credit. Examples of one way monetary tags include Goodwill, Other Short Term Borrowings, Sales Revenue, and Cost of Goods Sold. US GAAP Tags like these are almost always expected to have either a debit or a credit balance. Amounts reported as positive numbers and tagged with one way tags will be correctly tagged the vast majority of the time. As expected, one way tags are typically presented as positive numbers in HTML financial statements and render as positive numbers in XBRL renderings. Negated labels are generally not need for one way tags.

Two way tags are more challenging. Two way tags could be properly debits or properly credits depending on a filer’s financial situation. Some examples of two way tags include Net Income (Loss), Increase (Decrease) in Accounts Receivable, and Net Cash Provided By (Used In) Financing Activities. Filers need to think carefully about the balance that is tagged and the balance type of the tag it is tagged with. After making sure that the tagged value is tagged in the right direction, filers can then consider how they want the rendering to look and whether a negated label is desirable.

Where amounts are reported as negative numbers in HTML versions of filings, it may be necessary to reverse the sign of the amount and negate its label for rendering – especially when the related tag is a one way tag. For example, treasury stock is typically reported as a negative number on the HTML balance sheet and it is normally tagged with a US GAAP Taxonomy tag named “TreasuryStockValue”, which has a debit balance type. If an amount is reported as a negative number on the HTML financial statements, it will be imported into most XBRL software tools as a negative number. If left alone, it will be reported in the instance document as a negative debit which is in fact a credit. A credit is not correct for Treasury Stock, so the reverse sign attribute would need to be applied to the Treasury Stock line item. By doing so, the negative HTML Treasury Stock amount which was imported as a negative value will be changed to a positive value making it a positive debit which is correct. Treasury Stock is now a positive number mapped to a one way tag with a debit balance type, it will therefore render as a positive number. Since Treasury Stock was reported as a negative number in the HTML financials it may be desirable to have it render as a negative value. In order to get the amount to show as a negative number in the rendering while keeping its now correct debit balance, a “negated” label is used to flip the view of the rendering to negative.

Based on the discussion above, it is easy to understand why actual instance document values, the balance type of tags they are mapped to and how they should be rendered must be carefully considered to make sure that amounts are not reported backwards. By remembering the factors described above, SEC Filers may get their XBRL right and keep their filings off the erroneous filings list.

What are you doing with XBRL?

The 2011 UGT contains many improvements over the 2009 UGT that is currently used for XBRL filings. The most notable improvements include (i) addition of Accounting Standards Updates that have been issued over the last two years, (ii) a build out of industry specific elements and (iii) distinguishment of elements used at each level of detail tagging. One of the more notable changes was the addition of a comprehensive text block tag section (Node 195000). Text bock tags in the 2011 UGT are distinguished from each other with the [Text Block] suffix for footnote disclosures, the [Policy Text Block] suffix for significant accounting policies and the [Table Text Block] suffix for tables within footnote disclosures.

The 2011 UGT is available here. For more information on XBRL and the latest guidance from the SEC please see the SEC’s XBRL Portal at http://xbrl.sec.gov/

Outsource:

When outsourcing, SEC filers choose a partner to do the heavy lifting of selecting and mapping XBRL tags to financial reporting facts, creating custom extensions, building the extension taxonomy and populating the instance document – in short creating the XBRL filing. In reality this process is iterative whereby the partner creates the XBRL files then returns some form of rendering (often a web based tool or an Excel workbook) for review. The SEC filer must review and comment on the tags selected and make changes where desired. There are usually three to five rounds of tag selection and approval, so the SEC filer is involved all along the way. You can outsource but you can’t abdicate your role

Insource

When “insourcing”, companies must do most of the heavy lifting themselves. There are many factors to consider when insourcing including what software tool to use, how to overcome the steep learning curve, what tags to choose, how to validate the files produced (usually the software tool can address this) and what internal procedures will be followed for gaining approval of the tags selected. The level of effort is significantly greater using this approach and will involve expert help from external partners due to complexity of initial XBRL implementation. You can insource, but you can’t eliminate your XBRL partners.

The Blended Approach

Companies should realistically consider initial XBRL implementation as neither purely outsource nor purely insource. With experience the insource approach can be fully realized, but not for initial compliance. By thinking about implementing XBRL using a blended strategy, companies can proactively choose what portion of XBRL implementation to tackle internally and what portion to trust to their partners.

The Integrated Approach

Companies should seek to integrate XBRL into their financial reporting systems over time. By doing so they can take advantage of XBRL enabled data validation and reuse. The goal would be to tag data deep with financial systems so that the tagged data can flow through the financial reporting value chain from bottom to top. One result of a fully integrated approach is automated production of XBRL tagged SEC filings.

The XBRL Continuum

Implementation and maintenance of XBRL should be seen as a continuum of choices. The XBRL continuum could be graphically depicted in this way:

As XBRL technologies mature and companies get past the learning curve, their processes should move from outsource toward integrated over time. By thinking about XBRL implementation as a continuum of choices, companies can develop an XBRL strategy that realizes the benefits of validated and contextualized data that persists throughout the financial reporting process.

No matter how you comply with the SEC’s XBRL mandate, make sure you think beyond compliance. What will you do with XBRL?

Each UGT element consists of labels, a financial concept definition, US GAAP references, and several attributes or properties. Certain properties, however, should play a more important role in determining which UGT element to map to reported data. It is helpful to consider what disclosure is being tagged then look to that node (section) of the UGT it is related to. For example, suppose the inventory footnote is being tagged. It is likely that most of the tags needed would reside in the Inventory section (node 340000) of the UGT. Beyond that, it is helpful to consider the following components of the UGT by placing a higher priority on components at the top of the list and a lower priority to those on the bottom of the list. 

• ATTRIBUTES OR PROPERTIES
  • Period type: Instant, Duration
  • Data type: Monetary, Shares, Per Share, Text, Strin
  • Element definition: Describes the financial concep
  • Authoritative references: US GAAP, SEC Regulations
• RELATIONSHIPS
  • Relationships: Land + Buildings + Equip = PPE
• LESS RELEVANT TO ELEMENT SELECTION
  • Element name: Camel Case name is a way of referring to the element and has no bearing on the data being tagged. The HTML is what XBRL renders. Element names (or labels) are intended to be descriptive but are less important than attributes that designate something about the data being tagged
  • Balance type: Debit / Credit

Period Type needs to be considered early in the tag selection process. It would be wrong to tag a balance sheet amount with a duration tag since duration tags represent a period of time. Likewise an income statement amount would never be tagged with an instant tag since instant tags represent a balance at a certain point in time.

Similarly Data Type needs to be considered early in tag selection. The selected tags need to represent the same type of data being disclosed. For example, the number of share outstanding needs an element that is a share type tag. It would be very misleading to tag shares with a monetary type tag.

Element Definition is clearly essential to knowing whether a particular tag adequately describes a disclosure amount. After all, disclosure definitions are integral to “telling the company story”.

Authoritative References can be very helpful in choosing a US GAAP taxonomy element. If the business acquisitions footnote is being tagged and it describes the financial impact of acquisitions that occurred during the period filers should be looking for a tags that reference Statement of Financial Accounting Standard 141.

Relationships can also be helpful in determining which tag to map to financial data. It is helpful to note that raw materials inventory, work in process and finish goods are presented in the same footnote and sum to total for inventory when mapping those facts to the appropriate tag.

The Element Name is purposely descriptive of what the element consists of, but it is less important than other more unforgiving attributes like period type and data type. If filers get the period type and data type wrong it clearly communicates the wrong information about their disclosures. The element name (or label) is more forgiving when period type, data type, definition, authoritative references and relationships are all correct.

The Balance Type is less important in tag selection. This seems counter intuitive, but balance types can be flipped to the opposite balance. Balance types are also likely right if all the other attributes accurately describe the data. While balance types are less important, they should still be considered, especially for amounts that are always expected to be debits (like cash, inventory, and fixed assets) or amounts that are always expected to be credits (like accounts payable, short term borrowings, and revenues). Balance types are much less important for facts that could be a debit or a credit (like net income/loss or cash provided by/used in operating activities) 

The order of preference in which attributes are to be considered is set forth in section 6.6.29 of the Edgar Filer Manual (EFM). It’s helpful to remember what to consider first when selecting an element from the UGT, but priority of considerations is just one part of getting XRL right.  There is a steep learning curve for understanding how to get XBRL right. Are you ready?