XBRL - What is it?

 

1.  What is XBRL?

XBRL is a data-rich dialect of XML (Extensible Markup Language), the universally preferred language for transmitting information via the Internet. It was developed specifically to communicate information between businesses and other users of financial information, such as analysts, investors and regulators. XBRL provides a common, electronic format for business reporting. It does not change what is being reported. It only changes how it is reported

XBRL is a language for the electronic communication of business and financial data which is revolutionizing business reporting around the world. It provides major benefits in the preparation, analysis and communication of business information. It offers cost savings, greater efficiency and improved accuracy and reliability to all those involved in supplying or using financial data. XBRL stands for eXtensible Business Reporting Language. It is already being put to practical use in a number of countries and implementations of XBRL are growing rapidly around the world.

XBRL is a world-wide standard, developed by an international, non-profit-making consortium, XBRL International Inc. (XII). XII is made up of many hundred members, including government agencies, accounting firms, software companies, large and small corporations, academics and business reporting experts. XII has agreed the basic specifications which define how XBRL works.

XBRL is an open, royalty-free software specification developed through a process of collaboration between accountants and technologists from all over the world. Together, they formed XBRL International which is now made up of over 650 members, which includes global companies, accounting, technology, government and financial services bodies. XBRL is and will remain an open specification based on XML that is being incorporated into many accounting and analytical software tools and applications.

XBRL tags

In XBRL, information is not treated as a static block of text or set of numbers.

Instead, information is broken down into unique items of data (eg total liabilities = 100). These data items are then assigned mark-up tags that make them computer-readable. For example, the tag <Liabilities>100</Liabilities> enables a computer to understand that the item is liabilities, and it has a value of 100.

Computers can treat information that has been tagged using XBRL ‘intelligently’; they can recognize, process, store, exchange and analyse it automatically using software.

Because XBRL tags are formed in a universally-accepted way, they can be read and processed by any computer that has XBRL software. XBRL tags are defined and organized using categorization schemes called taxonomies.

XBRL taxonomies

Different countries use different accounting standards. Reporting under each standard reflects differing definitions. The XBRL language uses different dictionaries, known as ‘taxonomies’, to define the specific tags used for each standard. Different dictionaries may be defined for different purposes and types of reporting. Taxonomies are the computer-readable ‘dictionaries’ of XBRL. Taxonomies provide definitions for XBRL tags, they provide information about the tags, and they organize the tags so that they have a meaningful structure.

As a result, taxonomies enable computers with XBRL software to:

• understand what the tag is (eg whether it is a monetary item, a percentage or text);
• what characteristics the tag has (eg if it has a negative value);
• its relationship to other items (eg if it is part of a calculation).

This additional information is called meta-data. When information that has been tagged with XBRL is transmitted, the meta-data contained within the tags is also transmitted.

Taxonomies differ according to reporting purposes, the type of information being reported and reporting presentation requirements. Consequently, a company may use one taxonomy when reporting to a stock exchange, but use a different taxonomy when reporting to a securities regulator. Taxonomies are available for most of the major national accounting standards around the world.

2.  How XBRL works?

XBRL is a member of the family of languages based on XML, or Extensible Markup Language, which is a standard for the electronic exchange of data between businesses and on the internet. Under XML, identifying tags are applied to items of data so that they can be processed efficiently by computer software.

XBRL is a powerful and flexible version of XML which has been defined specifically to meet the requirements of business and financial information. It enables unique identifying tags to be applied to items of financial data, such as ‘net profit’. However, these are more than simple identifiers. They provide a range of information about the item, such as whether it is a monetary item, percentage or fraction. XBRL allows labels in any language to be applied to items, as well as accounting references or other subsidiary information.

XBRL can show how items are related to one another. It can thus represent how they are calculated. It can also identify whether they fall into particular groupings for organisational or presentational purposes. Most importantly, XBRL is easily extensible, so companies and other organisations can adapt it to meet a variety of special requirements.

The rich and powerful structure of XBRL allows very efficient handling of business data by computer software. It supports all the standard tasks involved in compiling, storing and using business data. Such information can be converted into XBRL by suitable mapping processes or generated in XBRL by software. It can then be searched, selected, exchanged or analysed by computer, or published for ordinary viewing.

XBRL makes the data readable, with the help of two documents – Taxonomy and instance document. Taxonomy defines the elements and their relationships based on the regulatory requirements. Using the taxonomy prescribed by the regulators, companies need to map their reports, and generate a valid XBRL instance document. The process of mapping means matching the concepts as reported by the company to the corresponding element in the taxonomy. In addition to assigning XBRL tag from taxonomy, information like unit of measurement, period of data, scale of reporting etc., needs to be included in the instance document.

3.  Benefits of XBRL

XBRL offers major benefits at all stages of business reporting and analysis. The benefits are seen in automation, cost saving, faster, more reliable and more accurate handling of data, improved analysis and in better quality of information and decision-making. All types of organisations can use XBRL to save costs and improve efficiency in handling business and financial information. Because XBRL is extensible and flexible, it can be adapted to a wide variety of different requirements. All participants in the financial information supply chain can benefit, whether they are preparers, transmitters or users of business data.

XBRL enables producers and consumers of financial data to switch resources away from costly manual processes, typically involving time-consuming comparison, assembly and re-entry of data. They are able to concentrate effort on analysis, aided by software which can validate and manipulate XBRL information.

XBRL is a flexible language, which is intended to support all current aspects of reporting in different countries and industries. Its extensible nature means that it can be adjusted to meet particular business requirements, even at the individual organization level.

All types of organizations can use XBRL to save costs and improve efficiency in handling business and financial information. Because XBRL is extensible and flexible, it can be adapted to a wide variety of different requirements. All participants in the financial information supply chain can benefit, whether they are preparers, transmitters or users of business data.

Data Collection and Reporting

By using XBRL, companies and other producers of financial data and business reports can automate the processes of data collection. For example, data from different company divisions with different accounting systems can be assembled quickly, cheaply and efficiently if the sources of information have been upgraded to using XBRL. Once data is gathered in XBRL, different types of reports using varying subsets of the data can be produced with minimum effort. A company finance division, for example, could quickly and reliably generate internal management reports, financial statements for publication, tax and other regulatory filings, as well as credit reports for lenders. Not only can data handling be automated, removing time-consuming, error-prone processes, but the data can be checked by software for accuracy.

Data Consumption and Analysis

Users of data which is received electronically in XBRL can automate its handling, cutting out time-consuming and costly collation and re-entry of information. Software can also immediately validate the data, highlighting errors and gaps which can immediately be addressed. It can also help in analysing, selecting, and processing the data for re-use. Human effort can switch to higher, more value-added aspects of analysis, review, reporting and decision-making. In this way, investment analysts can save effort, greatly simplify the selection and comparison of data, and deepen their company analysis. Lenders can save costs and speed up their dealings with borrowers. Regulators and government departments can assemble, validate and review data much more efficiently and usefully than they have hitherto been able to do.

4.  Future of XBRL

XBRL is set to become the standard way of recording, storing and transmitting business financial information. It is capable of use throughout the world, whatever the language of the country concerned, for a wide variety of business purposes. It will deliver major cost savings and gains in efficiency, improving processes in companies, governments and other organisations.

5.  XBRL benefit the comparability of financial statements

XBRL benefits comparability by helping to identify data which is genuinely alike and distinguishing information which is not comparable. Computers can process this information and populate both pre defined and customised reports.

6.  XBRL & Accounting Standards

XBRL is simply a language for information. It must accurately reflect data reported under different standards – it does not change Accounting Standards.

7.  Benefits to a company from putting its financial statements into XBRL

XBRL increases the usability of financial statement information. The need to re-key financial data for analytical and other purposes can be eliminated. By presenting its statements in XBRL, a company can benefit investors and other stakeholders and enhance its profile. It will also meet the requirements of regulators, lenders and others consumers of financial information, who are increasingly demanding reporting in XBRL. This will improve business relations and lead to a range of benefits.

With full adoption of XBRL, companies can automate data collection. For example, data from different company divisions with different accounting systems can be assembled quickly, cheaply and efficiently. Once data is gathered in XBRL, different types of reports using varying subsets of the data can be produced with minimum effort. A company finance division, for example, could quickly and reliably generate internal management reports, financial statements for publication, tax and other regulatory filings, as well as credit reports for lenders. Not only can data handling be automated, removing time-consuming, error-prone processes, but the data can be checked by software for accuracy.

8.  Creating statements in XBRL

There are a number of ways to create financial statements in XBRL:

XBRL-aware accounting software products are becoming available which will support the export of data in XBRL form. These tools allow users to map charts of accounts and other structures to XBRL tags.

Statements can be mapped into XBRL using XBRL software tools designed for this purpose

Data from accounting databases can be extracted in XBRL format. It is not strictly necessary for an accounting software vendor to use XBRL; third party products can achieve the transformation of the data to XBRL.

Applications can transform data in particular formats into XBRL. The route which an individual company may take will depend on its requirements and the accounting software and systems it currently uses, among other factors.

9.  India and XBRL International

India is now an established jurisdiction of XBRL International. A separate company, under section 25 has been created, to manage the operations of XBRL India. 

The main objectives of XBRL India are

1. To create awareness about XBRL in India
2. To develop and maintain Indian Taxonomies
3. To help companies, adopt and implement XBRL.

For more information, visit www.xbrl.org/in

10.  Indian Taxonomies

Taxonomies for Indian companies are developed based on the requirements of

1. Schedule VI of Companies Act, 
2. Accounting Standards, issued by ICAI
3. SEBI Listing requirements.

Taxonomies for Manufacturing and service sector (referred as Commercial and Industrial, or C&I) and Banking sector, is acknowledged by XBRL International. These taxonomies are available at http://www.xbrl.org/in/

11.  About XBRL

Please visit www.xbrl.org  Also Ministry of Corporate Affairs would be shortly developing its webpage on XBRL with list of contact persons for training purposes.

12.  XBRL Documents

An XBRL document comprises the taxonomy and the instance document. Taxonomy contains description and classification of business & financial terms, while the instance document is made up of the actual facts and figures. Taxonomy and Instance document together make up the XBRL documents.

13.  Taxonomy

Taxonomy can be referred as an electronic dictionary of the reporting concepts. Taxonomy consists of all the data definitions, the basic XBRL properties and the interrelationships amongst the concepts. It includes terms such as net income, EPS, cash, etc. Each term has specific attributes that help define it, including label and definition and potentially references. Taxonomies may represent hundreds or even thousands of individual business reporting concepts, mathematical and definitional relationships among them, along with text labels in multiple languages, references to authoritative literature, and information about how to display each concept to a user.

14.  Extending Taxonomy

Taxonomy is extended to accommodate items/relationship specific to the owner of the information. Taxonomy extension therefore can be

1. Modification in the existing relationships
2. Addition of new elements in the taxonomy
3. Combination both a & b

15.  Taxonomies and Standards

Yes, taxonomies are based on the regulatory requirements and standards which are to be followed by the companies. Accordingly, depending on the requirements of every country, there can be country-specific taxonomies.

16.  Instance document

An XBRL instance document is a business report in an electronic format created according to the rules of XBRL. It contains facts that are defined by the elements in the taxonomy it refers to, together with their values and an explanation of the context in which they are placed. XBRL Instances contain the reported data with their values and “contexts”. Instance document must be linked to at least one taxonomy, which defines the contexts, labels or references.

Thus, in order to concluded the usage and explain the XBRL technology which leads to more information exchanges that can be effectively automated by use. This one standard approach leads to the best interest of the company or more so for the international business interests globally that warrant the accuracy of all the financial data for the end users and early collaborative decisions by the companies or those whose interest is involved for acquisition/ rights etc.

17.  Making Sense of XBRL In the US and the UK

There can be no doubt that XBRL (eXtensible Business Reporting Language) has become a hot topic for financial executives in the U.S. and also overseas. Many are already familiar, perhaps painfully so, with the U.S. Securities and Exchange Commission’s (“SEC”) XBRL reporting mandate for issuers and the requirements relating to 10-K annual reports and quarterly filings.

This Issue Alert looks at what is happening in the United Kingdom (UK), where the tax authorities (HM Revenue & Customs or "HMRC") have introduced an XBRL requirement that affects all companies required to file a tax return. This Alert highlights how the UK mandate differs in some key aspects from the SEC requirement, how the UK requirements are being addressed and outlines a wider agenda of considerations for financial executives in the U.S. and elsewhere, prompted by the introduction of XBRL by regulators around the globe.

18.  Key Considerations for Financial Executives

Financial executives should consider that the UK XBRL mandate:

1. Impacts all legal entities in the UK (both public and private);
2. Is required for both corporate tax filings AND statutory financial statement filings;
3. Requires UK GAAP Taxonomies, IFRS Taxonomies with some industry-specific taxonomies;
4. Is applicable for periods ending March 31, 2010, or later and has no transition period;
5. Requires detail tagging of the notes to the statutory financial statements in the initial filing with a minimum tagging requirement in the first few years moving to a greater tagging requirement;
6. Uses a “human readable” version of XBRL referred to as “iXBRL”;

Combined with the U.S. SEC XBRL mandate, as well as mandates by other regulators around the world, provides a catalyst for reengineering the currently highly manual last mile or assembly and review processes for a broad range of external and internal reports.

19.  The UK iXBRL Requirement

Like other country regulators around the world, UK regulators are migrating their compliance processes more fully onto the Internet and, in so doing, are seeking to enhance business processes for both themselves and their constituents. The UK Tax and Statutory regulators are collaborating to improve compliance processes by mandating that constituents provide their disclosures in a format that is more structured (e.g., XBRL) than those used to date (e.g., paper, pdf, html, word, excel) and is specifically designed to streamline preparation, consumption and analysis processes.

More specifically, for accounting periods ending on or after April 1, 2010, company tax filings (i.e., Form CT-600) and statutory accounts will have to be submitted online through the Government Gateway using structured electronic formats. Paper will no longer be permitted except in a few exception cases.

The UK XBRL mandate follows a two year phase-in wherein companies are initially required to structure a minimum disclosure set followed by a more complete requirement to structure all disclosures in the second year. This phase-in is designed to help users adapt to the new requirements and to limit the effort involved in manual processes, as companies adopt software that will partially or fully integrate the XBRL creation process with their compliance processes. To make some sense of the UK requirements in a U.S. context, useful data points include:

There are 1.6 million companies (legal entities) affected by the UK requirement. Each and every one will need to find a method to present financial statements in iXBRL format annually. It is perhaps worth reflecting what this means for a typical large company, either publicly or privately-held. The SEC requirement means that generally four (4) documents a year need to be tagged by the company. But a similar organization in the U.K. may have 50, 100, and possibly more individual companies within the group, each required to submit a tax return, and so each is required to prepare separate iXBRL financial statements. The breadth of the HMRC requirement is considerable.

The UK regulators are the first to leverage a more human readable version of XBRL referred to as “Inline XBRL” or “iXBRL”. While initially required by UK regulators, other regulators around the world, including the SEC, are planning to use the iXBRL format in the future.

iXBRL uses the same basic principles (and, alas, jargon) as XBRL: financial information is mapped into a standardized format using a library (a.k.a. “taxonomy”) of labels (a.k.a. “tags”). But there are technical differences in how final documents are produced (a.k.a. “rendered”). The iXBRL format substantially eliminates the “rendering” problem associated with raw XBRL reports (as is commonly the case with the SEC and other viewer applications) and simply includes the XBRL structured disclosures within a traditional html file.

As a first year accommodation, the SEC permitted notes to the financial statements to be “block tagged” – a time-saving concession that enabled accountants to become familiar with the process of tagging without necessarily tackling all the finer points of detail in the notes. In contrast, HMRC are requiring details within the notes to be tagged from Year 1 in a manner similar to the SEC's more detailed Year 2 level IV tagging which includes tagging of all amounts in the notes. 

The majority of legal entities in the UK are reporting in UK GAAP. To date, for the most part, only Group Accounts (a.k.a. Glossy’s) are prepared in IFRS. Most organizations are underway with transition plans from UK GAAP to IFRS in the next few years, which may require a partial Taxonomy transition as well.

But it wouldn’t be correct to present HMRC’s requirement as necessarily more challenging than the SEC’s. This is because:

iXBRL filing in the UK needs only be a private matter between the company and the tax inspector. There is no need to disclose the tagging externally and, perhaps surprisingly, the externally published, publicly available consolidated financial statements, which so interest analysts and investors, have no role in tax inspection and accordingly do not need to be tagged.

Tax filings need to be delivered one year after the end of the financial period to which they relate. UK accountants have a lot more time to get the tagging work completed than their U.S. counterparts.

Although organizations have the potential to require multiple company filings, each financial statement filing, known locally as statutory accounts, are substantially less in size to the group or SEC filings – ranging from 20 to 40 pages. This results in substantially less tags in comparison to SEC filings.

So, in our view, it isn’t really valid to contend that one or the other of the SEC or HMRC regulatory requirements is more onerous – they are just different, sometimes surprisingly so.

20.  The Pervasive Manual Last Mile of Reporting Processes

While there are significant differences in the regulatory requirements, the process adopted by preparers of financial information often look much more similar.

Although there is a growing band of organizations that are exceptions (more on them later), the most striking feature of many financial reporting processes in both the UK and the U.S. is a disconnection of the process somewhere between the general ledger and the final output. What do we mean by this? Standardization, defined processes and carefully devised and operated controls are often applied rigorously to general ledgers, trial balances, journal adjustments and consolidation systems to culminate in a group profit figure, a group balance sheet and supporting financial information. Under legal requirements in both the U.S. and UK, CEOs and CFOs take particular comfort from these when they ask themselves “how do I know these numbers are right?” before presenting the results to investors. So far, so good.

Then the disconnection occurs. Unlike the process automation and systems controls that reside in company ledgers and sub-systems, preparing the full financial information – the 10-K filing or the UK statutory accounts reflects a different type of process, a largely manual process. This “Manual Last Mile” reflects highly pervasive manual assembly and review processes that in many respects have not fundamentally changed in decades; only the report format has migrated from paper to electronic documents; most notably Word and Excel.

Key information is exchanged by e-mails or phone calls, validation steps are repetitive and manual, review processes involve distributed documents and thereby can become iterative, muddled or inefficient and in essence the whole process slows down and becomes more manual and, as a result, error-prone. For example many organizations will finalize their financial information by having the relevant managers sit in a room, turning the many pages of the document and discussing, sometimes “proving” numbers in the document.

Sometimes this happens late at night, when people are not at their sharpest, and many an accountant will have reflected “things don’t necessarily need to be done this way” during such meetings.

The financial reporting disconnects or “Manual Last Mile” we refer to is not directly related to XBRL – in fact it has existed for a long time. Regulatory requirements for XBRL do not, by themselves, represent a solution to the disconnection within reporting processes. Certainly it is possible to comply with the XBRL regulatory mandate without altering existing processes at all. To do so, simply bolt-on another process to structure or tag the completed report, perhaps accelerating the timetable for existing process. Such bolt-on processes include outsourcing the tagging work to a third party or purchasing a tagging tool to accomplish the task in-house. But what we are seeing is that XBRL provides a catalyst for change, a chance to pause, review how things are done and make plans for improvements.

21.  Catalyst for Change

We expect XBRL/iXBRL will be a catalyst for financial executives who realize that existing processes are open to improvement and wish to build a case for change within their organization. Software to do this is available today, and we expect that as demand grows, so will the development and diversity of available solutions. Accountants with a vision of an end-to-end financial reporting process may view XBRL as a trigger point. Something to kick-start change which delivers standardization, better process and rigorous control in a continuous flow from booking an accounting entry right through to the production of both internal management and external regulatory reports.

The potential rewards for doing this come in several forms:

First, the accuracy and quality of the required information can be expected to improve. This is a generally well understood benefit from standardization and should not be overlooked.

Also, review processes are enhanced through less manual iterations as more collaborative and less siloed processes are deployed; disclosure transparency within members of the company review process is a very useful outcome.

Next, the timeliness of the information – the speed of the reporting process should improve, freeing up accountants time for other valuable endeavors. Companies adopting the “built-in” implementation approach are reporting enhancements in their reporting process of 25% to 50% or higher.

Fourth, the flexibility provided by a systematic process should help management devise better management reports to make better decisions. These are not theoretical concepts. Remember the reference to a growing band of exceptions mentioned above? Those companies have found these benefits already.

Lastly, there is an opportunity to establish centers of excellence, creating specialized roles for financial statement production and XBRL maintenance, freeing up business unit accountants for more relevant tasks supporting local decision making. This could potentially lead to a greater return on investment and control over the entire process. For larger organizations, the Centre of Excellence model can be extended into Continental Europe reporting requirements over time.

How might this be done? In the UK, there is an established market for accounts preparation software. Such software takes trial balances and, by applying a mapping process, turns them into first-draft financial statements, ready for review, with relevant legal and regulatory disclosure requirements hard-wired into the document. Firms of accountants of all sizes in Financial Executives Research Foundation | 5

UK high streets have been using such software for years to produce financial statements for their clients. Companies themselves are now awakening to the benefits of this software to enable them to prepare financial statements, sharpening their systems, improving the quality of their work and crucially, shortening the timetable for the preparation and audit of reports of all types.

Other existing software solutions focusing on the process to produce complicated documents such as 10-Ks and annual reports can be used in both the UK and the U.S. to address XBRL regulatory requirements. These offer potential benefits far beyond simple regulatory compliance and are enabling companies to standardize information at earlier process stages and thereby streamline the currently pervasively manual report assembly and review process steps. Looking ahead, it seems probable that the accounting software industry will focus energy on providing ever-improving end-to-end packages which start at the general ledger work through to the final document.

But building a case for changing and standardizing processes is not straightforward and there are some common push-backs or concerns that need to be addressed.

22.  Common Push-Backs

One common push-back to the benefit of standardization comes from accountants who cherish the latitude that a fair presentation framework such as U.S. GAAP or International Financial Reporting Standards (IFRS) accords the preparer to set out financial information in ways that are most meaningful to the user. The concern is that somehow the structures of XBRL taxonomies will turn accounting into a “check the box” exercise and diminish the quality of financial information available to users. The principle underlying this concern is easy to understand and sympathize with. What is much more difficult is to find an accountant in practice that actually wants this to happen and advocates it. What’s more, any standardized process can (and probably should) include a step which requires the accountant to step back and ask themselves the question “does the disclosure make sense?” The accountants’ skill and expertise can then be applied to and focussed on disclosures where there is a problem, rather than turning each disclosure note into something resembling the accounting equivalent of a hand-crafted work of art.

Standardization of process is nothing new to those who work outside the finance space in disciplines that are part of supply chain management, such as warehouse management, transportation or retailing. There are many startling stories of increased quality and time-savings arising from standardization. For example, for those with relatively long memories, just look at how many more product lines became available in supermarkets in the years after the introduction of the UPC or bar-codes. Sometimes accountants appear concerned that standardization will change their job, or their perception of their job in ways that will diminish its importance and status. In our view this concern is overplayed – supply chain management and accounting are different and distinct disciplines. But in both areas what is often most valued is the insight to spot where change is required and the energy to deliver the change.

Everyone appreciates that implementing a new process involves some up front effort and planning involving other stakeholders, such as procurement and IT departments. Even the shortest and most optimistic payback periods cited by software vendors imply that there is a cost to be paid back. The cost is not merely that of the software itself, but also the management time and effort involved in setting up the system, process and controls that levers value from the new software. Financial executives are often acutely aware of this and are cautious about adopting change without sponsorship from senior figures in the organization.

23.  The Wider Agenda

Let’s turn then to those senior figures, the CFOs and Audit Committees. Where does XBRL fit on their radar screen? Here is our best expectation of how their perspectives will be shaped, which we term the “wider agenda”.

In recent years, both the U.S. and UK economies have been going through tough times and a very common response within companies has been to hold or seek to reduce the budget available for central finance activities. Yet levels of financial regulation and the work necessary to comply with that regulation continue to grow.

Taking a narrow view, one response is to have accountants carry on with existing processes, work longer hours and get more done. Those experienced in managing finance departments will recognize that thinking along these lines can play a role in the short term, but has a tendency to become like pulling ever harder on a piece of elastic – when something eventually snaps the result can be painful. So what else can be done?

Another narrow view might be to loosen the purse strings and budget for a larger accounting team without questioning existing processes. In a similar vein, it is possible to budget for XBRL tagging to be outsourced for the foreseeable future, which is acceptance of an annuity cost. The trouble is that senior financial executives tend to take a hard-headed stance to such proposals and rightly so. So what can be proposed that will resonate with senior figures?

Solving the XBRL/iXBRL requirement need only be part of the solution to a wider challenge: How to cope with increasing regulatory complexity, generate more useful information, control costs and speed-up accounting and reporting processes. Perhaps only by looking at the wider supply chain standardization agenda can a course of action be taken which transforms the reporting chain for the better.

So what might start as an XBRL tagging challenge might involve re-thinking the number of statutory entities that are necessary, the reporting process, the information needs of the business, the way in which accounting requirements are interpreted in the accounting policies and improving the value provided by people in the finance function. All with the combined objective of making the finance process better, the finance team more effective and business managers more aware of relevant information for decision making. To us, this seems a worthwhile and proactive way forward in response to the increasing tide of new regulation and rising costs for finance functions in the US, the UK and elsewhere.

24.  XBRL Glossary

Abstract

An attribute of an element to indicate that the element is only used in a hierarchy to group related elements together. An abstract element cannot be used to tag data in an instance document.

Attribute

A property of an element such as its name, balance, data type, and whether the element is abstract. Attributes of XBRL US GAAP Taxonomy elements cannot be changed.

Authoritative reference

Citations to specific authoritative accounting literature (pronouncements, standards, rules, and regulations) derived from various authoritative sources (Securities and Exchange Commission, Financial Accounting Standards Board, American Institute of Certified Public Accountants, etc.) and used to help define an element.

Axis (pl. axes)

An instance document contains facts; an axis differentiates facts and each axis represents a way that the facts may be classified. For example, Revenue for a period might be reported along a business unit axis, a country axis, a product axis, and so forth.

Axis-default relationship

The dimensional relationship indicating that the table axis has a default domain member. In the XBRL US GAAP Taxonomies 1.0, the default is always the domain element.

Axis-domain relationship

The dimensional relationship indicating that the table axis has members drawn from a domain.

Balance

An attribute of a monetary item type designated as debit, credit, or neither; a designation, if any, should be the natural or most expected balance of the element – credit or debit – and thus indicates how calculation relationships involving the element may be assigned a weight attribute (-1 or +1).

Calculation relationships

Additive relationships between numeric items expressed as parent-child hierarchies.

Concept

XBRL technical term for element.

Context

Entity and report-specific information (reporting period, segment information, and so forth) required by XBRL that allows tagged data to be understood in relation to other information.

Decimal

Instance document fact attribute used to express the number of decimal places to which numbers have been rounded.

Definition relationships file

Technical term for dimensional relationships file.

Dimension

XBRL technical term for axis.

Domain

An element that represents an entire set of other elements; the domain and its members are used to classify facts along the axis of a table. For example, “Arkansas” is a domain member in the domain “States,” and would be used to classify elements such as revenues and assets in Arkansas as distinct from other states. When a fact does not have any domain member specified, that means it applies to the entire domain.

Domain member

An element representing one of the possibilities within a domain.

Domain-member relationship

Dimensional relationship indicating that a domain contains the member.

Element

XBRL components (items, domain members, dimensions, and so forth). The representation of a financial reporting concept, including: line items in the face of the financial statements, important narrative disclosures, and rows and columns in tables.

Element definition

A human-readable description of a reporting concept. From an XBRL technical point of view, the element definition is the label with the type “documentation,” and there are label relationships in a label relationships file, but from a user point of view the definition is an unchangeable attribute of the element.

Extension taxonomy or extension

A taxonomy that allows users to add to a published taxonomy in order to define new elements or change element relationships and attributes (presentation, calculation, labels, and so forth) without altering the original.

Face of the financial statements

Financial statements without the notes or schedules.

Fact

The occurrence in an instance document of a value or other information tagged by a taxonomy element.

Hierarchy

Trees (presentation, calculation, and so forth) used to express and navigate relationships.

Hypercube

XBRL technical term for a table.

Imputed value

A value that is not specifically provided but could be calculated based on other provided numbers and calculation weights.

Instance or instance document

XML file that contains business reporting information and represents a collection of financial facts and report-specific information using tags from one or more XBRL taxonomies.

Item

XBRL technical term for a kind of element.

Label

Human-readable name for an element; each element has a standard label that corresponds to the element name, and is unique across the taxonomy.

Label type

A distinguishing name for each distinct element indicating the circumstances in which it should be used; each is given a separate defining role to use in different presentation situations.

Line item

Elements that conventionally appear on the vertical axis (rows) of a table.

Linkbase

XBRL technical term for a relationships file.

Mapping

Process of determining the elements that correspond to lines and columns in a financial statement and which elements must be created by extension.

Name

Unique identifier of an element in a taxonomy.

Namespace

Every element has a Universal Resource Identifier (URI) that identifies the organization that maintains the element definitions, with an indication of what the term covers. In the XBRL US GAAP Taxonomy, namespaces start with http://xbrl.us/us-gaap. A namespace prefix is not the namespace.

Nillable

An attribute that appears on all taxonomy elements, and is used (false) on elements that, if used in an instance document, must have a non-empty value. XBRL taxonomy tools normally have the default value for nillable as “true.” There is no need for any extension to define an element with nillable “false.”

Parent-child hierarchy

Relationship between elements that indicates subordination of one to the other as represented in a print listing or financial statement presentation. Relationships files use parent-child hierarchies to model several different relationships, including presentation, summation of a set of facts, and membership of concepts within a domain used as the axis of a table.

Period type

An attribute of an element that reflects whether it is reported as an instant or duration time period.

Prefix or namespace prefix

A shorthand sequence of letters for a namespace; “us-gaap,” for example, is a common prefix for the namespace http://xbrl.us/us-gaap/2008-01-31.

Presentation relationships

Relationships that arrange elements allowing them to navigate the taxonomy content in parent-child tree structures (hierarchies).

Render or rendering

To process an instance document into a layout that facilitates readability and understanding of its contents.

Scaling

A process that automatically scales numeric data by value, thus saving time of entering zeros during the entry or creation process. XBRL does not support the scaling of numeric values (all values must be reported in their entirety); however, it is a feature commonly found in instance document creation software.

Scenario

Tag that allows for additional information to be associated with facts in an instance document; this information encompasses in particular the reporting circumstances of the fact, as for example “actual or forecast.” The scenario of any fact can be left unspecified.

Schema

Technical term for an element declaration file.

Segment

Tag that allows additional information to be included in the context of an instance document; this information captures segment information such as an entity’s business units, type of debt, type of other income, and so forth.

Sign value

Denotes whether a numeric fact in an instance has a positive (+) or negative (-) value.

Standard label

The default label for an element. An extension may override the standard label.

Table

An element that organizes a set of axes and a set of line items to indicate that each fact of one of the line items could be further characterized along one or more of its axes. For example, if a line item is Sales and an axis is Scenario, this means that an instance document could have facts that are either for an unspecified scenario or for a specific scenario such as “actual or forecast.”

Tag (noun)

Identifying information that describes a unit of data in an instance document and encloses it in angle brackets (<> and ). All facts in an instance document are enclosed by tags that identify the element of the fact.

Tag (verb)

To apply tags to an instance document.

Taxonomy, taxonomies

Electronic dictionary of business reporting elements used to report business data. A taxonomy is composed of an element names file (.xsd) and relationships files directly referenced by that schema. The taxonomy schema files together with the relationships files define the concepts (elements) and relationships that form the basis of the taxonomy. The set of related schemas and relationships files altogether constitute a taxonomy.

Type or data type

Data types (monetary, string, share, decimal, and so forth) define the kind of data to be tagged with the element name.

Unit of measure

The units in which numeric items have been measured, such as dollars, shares, Euros, or dollars per share.

Validation

Process of checking that instance documents and taxonomies correctly meet the rules of the XBRL specification.

Weight

Calculation relationship attribute (-1 or +1) that works in conjunction with the balance of the parent and child numeric elements to determine the arithmetic summation relationship.

Please visit https://thehub.org.in 

#xbrl #tagging #financialreporting #accounting