This public exposure version was available for comment until July 17, 2017.
Return to XBRL US Style Guide || Review comments and DSC responses

The XBRL US Style Guide is designed to be used by developers as they build new taxonomies or update existing taxonomies, to facilitate the creation of consistent, high-quality, easy-to-use taxonomies. The Style Guide serves as the basis for the naming styles of XBRL concepts, labels and other components.

This Style Guide should be used in conjunction with a Taxonomy Guide which is currently under development. The Taxonomy Guide will cover topics such as background and history of XBRL, how to create a data model, development steps in building a taxonomy, examples of business cases, instance document and taxonomy guides, as well as resources. Therefore these areas will not be covered within this Style Guide.

This draft release was developed by the XBRL US Domain Steering Committee (DSC) for a 90-day public review period that ends on July 17, 2017.

The DSC requests comments about the following:

  • Areas that were not included but should be added to the Style Guide (please keep in mind the topic areas noted above that will be included in the Taxonomy Guide)
  • Suggestions on recommendations made
  • Suggestions on clarifications needed

When commenting, please indicate the numbered section of the Style Guide to which your comment pertains.

The DSC recognizes that certain published taxonomies may not follow all the rules set forth in the Style Guide. The Style Guide is principally meant as a reference document for new taxonomies, and to the extent practical, for revisions to existing taxonomies.

XBRL US Style Guide

A Language Guide for Creating Concepts and Labels

Draft for Public Review – Version Published on 04/07/2017

Table of Contents

1. Introduction. 1

1.1 Scope and Purpose. 1

1.2 Goals. 1

1.3 Conventions. 2

1.4 Terminology. 2

1.5 Style Guide Position and Reference Materials. 4

2. Data Organization and XBRL Conventions. 5

3. Language Guidelines. 7

3.1 Use of Articles/Adjectives. 7

3.2 Nouns. 7

3.3 Pronouns. 7

3.4 Adverbs. 8

3.5 Expressing Numbers. 8

3.6 Spelling and Alternative Terms. 9

3.7 Use Concise Descriptions. 9

3.8 Use of Units. 10

3.9 Use of Scaling. 10

3.10 Use of the Word “Other” 10

3.11 Use of the Words “Total” 10

3.12 Use of Terms of Art as Adjectives. 10

3.13 Characters/Character Set 11

3.14 Percentages. 12

4. Concepts. 13

4.1 Common Concepts. 13

4.2 Organization of Concepts. 13

4.3 Language Usage. 13

4.4 Word Ordering and Use of Adjectives. 13

4.5 Concept Naming. 15

4.6 Financial Term Guidance. 16

5. Labels. 18

5.1 Overview of Labels. 18

5.2 Label Roles. 18

5.3 Language Usage. 19

5.4 Capitalization. 20

5.5 Hyphen Usage. 20

5.6 Label Descriptions. 21

5.7 Label Suffixes. 24

6. Guidelines for Documentation Labels. 26

6.1 Creating Accurate Documentation Labels. 26

6.2 Punctuation. 26

7. References 27

7.1 Reference Consistency. 27

7.2 Standard Reference Roles. 28

7.3 Reference Changes. 28


Appendix A — References (non-normative) A–1
Appendix B — Intellectual Property Status (non-normative) B–1
Appendix C — Acknowledgements (non-normative) C–1
Appendix D — Document Revision History (non-normative) D–1
Appendix E — Taxonomy Vernacular Examples (non-normative) E–1

1. Introduction

1.1 Scope and Purpose

The purpose of this Style Guide is to facilitate the creation of consistent, high-quality, easy-to-use taxonomies by serving as a basis for the naming styles of XBRL concepts, labels and other components. This Style Guide should be followed for taxonomy development and architecture for all taxonomies, including for open and extendable taxonomies, created and used in the United States.

Deviations from Style Guide Specifications should be substantiated and noted in a supplement to the taxonomy guide that corresponds to the deviating taxonomy.

This 2017 Style Guide is intended for use by developers in new taxonomy development. Taxonomies created prior to 2017 may not adhere to Style Guide Specifications. Governing bodies are encouraged to consider adopting the Style Guide in subsequent or revised taxonomy releases.

1.2 Goals

Consistency in all aspects of XBRL, including style, is critical to the successful deployment of the XBRL standard. Consistent styling of concept names, labels, and documentation will facilitate the efficient creation and consumption of XBRL data.

The primary goals of this document are the following:

  1. Provide a basis for the consistent development and maintenance of US taxonomies.
  2. Increase the efficiency and effectiveness of US taxonomies.
  3. Improve taxonomy extensibility for end users and taxonomy developers.
  4. Maximize comparability of data, reduce the ambiguity of data, and promote the normalization of data.
  5. Increase compatibility of taxonomies.
  6. Improve the reliability and consistency of the concepts, labels and documentation.
  7. Reduce the cost of taxonomy implementation.

These goals can be achieved through standardization. An effective standard for taxonomy creation will provide developers with the tools to create consistent taxonomies, resulting in taxonomies that end users can effectively navigate. Standard taxonomies can be adopted more quickly by end users, reducing the time and cost associated with implementing and consuming XBRL.

This Style Guide promotes adherence to XBRL International Incorporated (XII) and XBRL US (XUS) best practices, as applicable to style. Other XII and XUS best practices should also be followed during taxonomy creation for topics that are not covered by this guide.

1.3 Conventions

The following highlighting is used for non-normative commentary in this document:

Non-normative editorial comments are denoted by indentation and the prefix “NOTE:

: This is a non-normative editorial comment.

Normative requirements will contain capitalized key words. MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this specification, are to be interpreted as described in IETF RFC 2119.

All specifications within this document are considered normative except those marked as non-normative.

1.4 Terminology

The terminology used in XBRL frequently overlaps with terminology from other fields. The following list is provided to reduce ambiguity and confusion.

Table 1. Terms and Definitions



Abstract Element

A Concept used specifically to organize or group other Concepts within a presentation. An abstract element cannot define a fact or data.

Compliant Taxonomy

A Taxonomy being developed through use of this Style Guide.


A Concept is defined in two correlative ways. In a syntactic sense, a Concept is an XML element defined in the XML schema. On a semantic level, a Concept is defined for which a value or text can be provided in an Instance.


A period of time, as either a specific instant in time or a duration of time. Contexts can be further qualified by Segments and Scenarios to provide a dimensional representation of Facts.

Documentation Label

A specific Label Role meant to relay textual information conferring the meaning (definition) for a specific Concept.


The terms Element and Concept are sometimes interchanged. For XML, an element is defined using XML Schema. Fact data is contained inside an XML/XBRL element. For XBRL, an element is the representation of a Concept. Since many implementations of XBRL use XML to represent instance data, the term Element is an acceptable synonym for Concept.


A data point represented by the intersection of a Concept, Context and a Unit.


A collection of facts, contexts and units. An instance is usually a snapshot, report or other collection of data for a specified period.


A human-readable description of a Concept usually displayed when rendering a taxonomy or instance document. Labels are further broken down by common Roles where Concept data might be displayed. Examples of Label types include: Standard, Terse and Documentation.

Label Role

Also “Role” in this document. A unique identifier (usually a URI) set in the @xlink:role
attribute that distinguishes different types of Concept Labels.


A file that defines relationships between Concepts. A linkbase is described using an XML Linking Language called XLINK. For XBRL, a linkbase describes presentations, calculations and other information.

Presentation (linkbase)

An arrangement of Concepts for reference or display of Concepts in a human-readable form. Presentations also describe a parent-child relationship between Concepts.


Authoritative references may be cited in a taxonomy to provide the user with further information about an element. The FASB Codification is an example of an authoritative reference.

Semantic Data Model

A model that not only describes data points but the relationships of the data points modelled for use in a specific application such as describing business information.

Standard Label

The default human-readable Label associated with a Concept.


The grammar and word choices used to define Concepts and Labels.


The individual idea or item to which a Concept refers in the Semantic Data Model.


Taxonomy is the practice and science of classification. For XBRL, a Taxonomy defines Concepts, Labels, relationships, data types, units, presentations and other information to accurately describe, classify and express complex business data. A Compliant Taxonomy allows for the expression of the Semantic Data Model.

Taxonomy Vernacular

All human-readable Concept names, Labels and Linkbase titles defined by a Taxonomy.

Terse Label

Short Labels in which parts of the description that can be inferred, may be omitted. Terse Labels are used in a taxonomy in addition to Standard Labels, not as a replacement to Standard Labels.

1.5 Style Guide Position and Reference Materials

This guide serves in a larger scheme of specification and other published materials:

Figure 1. Style Guide Position

At the lowest level are documents such as the XML specifications and other materials related to the XML specification. This is the foundation for the XBRL specifications from XII, which include a variety of documents.

The Style Guide serves as a foundation for Taxonomy development and maintenance in the United States with the Style Guide’s governance controlled by XUS.

Taxonomies themselves may incorporate other taxonomies developed and controlled by other government entities and/or non-government organizations (NGOs). In addition, many NGOs control or contribute to various taxonomies while government agencies can contribute to and approve such taxonomies.

Taxonomies included in a Compliant Taxonomy do not have to be compliant. It is the purview of the authors of those incorporated taxonomies to comply with the rules set forth in the Style Guide. For more information on Taxonomy development, refer to the XBRL US Taxonomy Guide.

Return to Table of Contents

2. Data Organization and XBRL Conventions

Data organization is paramount when creating a Compliant Taxonomy. Compliant Taxonomy developers SHOULD review the Taxonomy Guide before beginning XBRL taxonomy creation for additional information about creating and analyzing the Semantic Data Model.

The structure and style of the resulting taxonomy impacts software developers, preparers of data, and analysts, as well as systems that generate and receive data. A significant strength of XBRL is data organization and the ability to describe, examine, and compare data. Authors should consider how the end data might be explored and whether the data structure, concepts names, and labels are conducive to allowing users to utilize the strengths of XBRL.

Developing the Taxonomy Vernacular should not be seen as a second part of the taxonomy development process that occurs after the Semantic Data Model has been completed. Neither should the development of the Semantic Data Model occur after developing the Taxonomy Vernacular.

Rather, creating a Compliant Taxonomy will be an iterative process that involves making changes to the Semantic Data Model during the development of the Taxonomy Vernacular. Shortcomings will become apparent in even the most well-prepared data models as Developers attempt to assign language and describe each element in the model. For example, Developers may find that certain data requires restructuring, that there are redundancies that need to be eliminated, or that certain Subjects require additional Concepts for further granularity.

Figure 2. Taxonomy Creation Workflow

Part of taxonomy style is organizing the Semantic Data Model. Proper organization of the Semantic Data Model will aid Developers in structuring the taxonomy, determining Concepts, and selecting language for each Concept’s Label Roles. Combined with the Functional Requirements and XBRL Requirements, an initial Taxonomy Vernacular can be created. Imported Taxonomies will likely be included which can also influence the design process. During the design cycle, the iterative process continues until the Taxonomy is approved and ready for the stakeholders. Changes may flow back into both the Semantic Data Model and the Functional Requirements as discrepancies, missing items, or other errors are discovered.

The Developer SHOULD avoid overlapping or redundant data points. Such points may make sense in the description of the Semantic Data Model but not when applied to the Taxonomy. However, the same concept can appear in more than one presentation within the Taxonomy.

The “Structure” aspect of “Concepts & Structure” is important in terms of how the various features of XBRL are employed and can heavily impact the naming of Concepts. XBRL defines a fact to be an intersection of a Concept, a Context and a unit. On a basic level, Contexts provide the time dimension to a fact but can be further expanded by defining additional dimensionality through the use of member and scenario Concepts. Concept hierarchy can be expressed using presentations and calculations as well. These different methods of structuring data can impact how Concepts are named and where dimensions and dimensional Concepts may be more appropriate than individual Concepts.

Finally, the design of the Taxonomy Vernacular should take into consideration extensibility, the revision process and the ease of understanding.

Return to Table of Contents

3. Language Guidelines

Language Guidelines MUST be followed for all Taxonomy Vernacular. This includes Labels, Concepts, and Roles. A well-structured, easily understandable taxonomy flows down from the guidelines set forth in this section. It is critical for authors to employ this as a minimum basis in developing clear and concise taxonomy structure.

Language Guidelines in other sections that are specific to Labels or Concept names supersede the rules here where conflicts occur.

For the purposes of creating Compliant Taxonomies within the United States, Developers SHOULD create the taxonomy using American English and use the XML language identifier to indicate “en-US” as the language for the taxonomy. Additional languages MAY be included in the taxonomy by creating a specific Label Role for that language. However, in all Compliant Taxonomies, Concept names, the Standard Label, and the Documentation Label SHOULD be written using grammar and spelling common to American English.

: The language guidelines contained within this Style Guide pertain to Taxonomy Vernacular written in American English. Within any language Label for an additional language, Developers should use the proper grammar, spelling, and conventions of that language while following the rules set forth in the Style Guide to the extent possible.

3.1 Use of Articles/Adjectives

Articles SHOULD be restricted to Documentation Labels.

Table 2. Restricted Articles

Restricted Articles



Adjectives MUST be used with a noun.

Adjectives MUST be used when there is ambiguity surrounding the subject.

3.2 Nouns

Each item in the Taxonomy Vernacular SHOULD contain a noun. The data being modelled by the taxonomy refer to specific subjects and objects (such as finances, employees, equipment, etc.) and therefore the Taxonomy Vernacular should use nouns to describe the data.

3.3 Pronouns

Personal Pronouns MUST NOT be used.

Possessive Pronouns MUST NOT be used.

Other Pronouns SHOULD NOT be used except in Documentation Labels.

Table 3. Disallowed Pronouns

Disallowed Pronouns


I, Me, We, Us, You, She, Her, He, Him, It, They, Them


That, Which, Who, Whom, Whose, Whichever, Whoever, Whomever


This, These, That, Those


Anybody, Anyone, Anything, Each, Either, Everybody, Everyone, Everything, Neither, Nobody, Nothing, One, Somebody, Someone, Something, Both, Many, Several, All, Any, Most, None, Some


Myself, Ourselves, Yourself, Yourselves, Himself, Herself, Itself, Themselves


What, Who, Which, Whom, Whose


My, Our, Your, His, Her, Its, Their, Mine, Ours, Yours, Hers, Theirs

: Many of the words in Table 3 can be used as pronouns, adjectives or nouns in the English language. This rule refers specifically to their usage as pronouns.

Gender neutral personal pronouns such as “ze” or “xe”, which are gaining adoption in many countries including the United States, should be considered the same as traditional personal pronouns and MUST NOT be used in Taxonomy Vernacular.

3.4 Adverbs

Adverbs SHOULD NOT be used. Adverbs MAY be used to express a recurring Subject.

Example 1. Allowable Use of Adverbs

“Oil and Gas Delivery Commitments and Contracts, Daily Production”

“Sale Leaseback Transaction, Monthly Rental Payments”

3.5 Expressing Numbers

Use the following rules for numbers:

– Exact numbers one through nine MUST be spelled out, except for percentages and page or section numbers.

– Numbers of 10 or more MUST be expressed in figures.

3.6 Spelling and Alternative Terms

3.6.1 Spelling

For words that have multiple correct spellings, developers SHOULD use agreed-upon spelling as noted in Table 4 below. Words not in this list MUST be spelled consistently throughout the taxonomy.

Table 4. Agreed-upon Spellings

Spelling to use

Do not use:


Pro forma, Pro-forma, ProForma


Non Current, Non-Current, NonCurrent


Post-Employment, Post-Retirement


Non accrual, Non-accrual, Non-Accrual


Non cancelable, Non-cancelable, Non-Cancelable


Non cash, Non-cash, Non-Cash


Non deductible, Non-deductible, Non-Deductible


Non interest, Non-interest, Non-Interest


Non operating, Non-operating, Non-Operating


Non performing, Non-performing, Non-Performing


Non production, Non-production, Non-Production


Non recurring, Non-recurring, Non-Recurring


Non taxable, Non-taxable, Non-Taxable

3.6.2 Alternative Terms

Alternative terms in the Taxonomy Vernacular SHOULD be avoided. If a subject can be described using alternative terms, those terms most widely used in practice SHOULD be used in the taxonomy. The selected term MUST be used consistently throughout the Taxonomy Vernacular.

Developers SHOULD avoid using synonyms for both nouns and adjectives within the Taxonomy Vernacular.

3.7 Use Concise Descriptions

All Taxonomy Vernacular MUST be concise, follow commonly used terminology, and avoid being excessively descriptive. Language used should avoid Labels that reference other line items on a financial statement.

Example 2. Concise Language and Common Terminology


Property, Plant, and Equipment, Net

Instead of:

Property, Plant, and Equipment, After Accumulated Depreciation



instead of


3.8 Use of Units

Concept names and Labels MUST NOT specify the unit of the data being described.

3.9 Use of Scaling

Concept names and Labels MUST NOT specify scaling.

3.10 Use of the Word “Other”

The word “Other” SHOULD NOT be used by itself or solely in conjunction with an adjective. The word “Other” SHOULD be used only when there are groups of like items in the Taxonomy Vernacular. A Label or Concept that describes all other data does not make sense without another Label or Concept that describes a specific portion of that data.

The term “Miscellaneous” SHOULD NOT be used; “Other” should be used instead, provided that it adheres to the proper use rule as noted above.

Example 3. Acceptable Use of the Word “Other” Within A Group of Subjects

“Current Deposit Assets”

“Current Regulatory Assets”

“Current Other Assets”

3.11 Use of the Word “Total”

The word “Total” SHOULD be used only for the Total Label Role.

3.12 Use of Terms of Art as Adjectives

Developers MAY use “terms of art” within the Taxonomy Vernacular provided the term of art is defined in supporting user and preparer guides for the Compliant Taxonomy.

Example 4. Using a Term of Art

Preparer’s Guide or User Guide states:

“The term ‘off the shelf’ when it appears as part of an element name or label means “a product or service that is already completed by a third party.”

Example Labels for a Concepts in the Taxonomy

“Software, Off the Shelf, Contracted”

“Software, Off the Shelf, Commercial”

Developers MAY shorten certain “terms of art” to a single adjective within the Compliant Taxonomy, provided that such use follows the additional rules below:

  1. The adjective when used alone is only used to represent the term of art.
  2. The term of art does not appear in any Concept names or Labels with the exception of the Documentation Label.
  3. If multiple terms of art could be shortened to the same adjective, only shorten the most common term as it appears in the taxonomy.

Example 5. Shortening a Term of Art to a Single Adjective

Preparer’s Guide or User Guide states:

“The term ‘net’ when it appears alone as part of an element name or label means ‘net of tax’.”

Example Labels for Concepts in the Taxonomy

“Assets, Net”

“Lease Rent Payments, Net of Collateral Accounts”

3.13 Characters/Character Set

The Taxonomy Vernacular SHOULD contain only characters from the Unicode Latin code charts.

The following characters MUST NOT be used:

Table 5. Disallowed Characters

Disallowed Characters

Control Characters

ASCII codes less than 0x20 or other characters marked as CONTROL by the Unicode Standard


Exclamation Mark


Number Sign






Plus Sign

As Minus Sign




Less-Than Sign


Equals Sign


Greater-Than Sign


Question Mark


Commercial At


Reverse Solidus


Circumflex Accent


Low Line


Grace Accent


Left Curly Brace


Vertical Line


Right Curly Brace



Developers SHOULD avoid using symbol characters except in the Documentation Label.

3.14 Percentages

The word “Percent” SHOULD be spelled out except when used in Documentation Labels. When Documentation Labels contain an example with percentages, numerical percentages SHOULD be expressed by using the percent symbol (%).

Return to Table of Contents

4. Concepts

4.1 Common Concepts

Concepts that exist in other taxonomies MUST NOT be recreated as part of a Compliant Taxonomy; rather, a Compliant Taxonomy MUST reference the other taxonomy by importing its namespace. When incorporating existing taxonomies, the Style Guide SHOULD be employed for consistency purposes, even if the imported taxonomy is not a Compliant Taxonomy.

For a list of available taxonomies that have been approved, see

4.2 Organization of Concepts

Elements in the same topic area SHOULD be associated through the use of abstract elements and presentation structure.

4.3 Language Usage

The guidelines stated in 3. Language Guidelines
also apply to Concepts. The section below provides additional guidance specific to language associated with Concept names.

4.3.1 Use of Dashes

Dashes SHOULD NOT be used in Concept names.

4.3.2 Acronyms and Abbreviations

Acronyms and abbreviations MAY be used in Concept names if the acronym itself is more commonly understood by target end users than the acronym’s meaning or if the length of the expanded acronym would be prohibitively long. When using an acronym, all letters in the acronym SHOULD be capitalized.

Example 6. Acceptable Concept Name
Containing an Abbreviation or Acronym



Example 7. Unacceptable Concept Name
Containing an Abbreviation or Acronym



When an acronym or abbreviation is used as part of a Concept name, at least one of the Concept’s Labels SHOULD contain the spelled-out version. Brevity is important in Concept names but clarity to the user is more important.

4.4 Word Ordering and Use of Adjectives

4.4.1 Word Ordering

Consistent ordering of words in the Taxonomy Vernacular is important as it helps end users and consumers identify similar items. The goal is to create language that is consistent and easy to read.

Each Concept name MUST follow the same pattern:

{Noun} ({Adjective} …)

Any number of adjectives MAY follow the noun when describing the Subject of the Concept. Adjectives used in more than one Concept MUST appear in the same order throughout the Taxonomy Vernacular.

Open compound, closed compound and hyphenated compound nouns SHOULD be treated as the noun in the word order.

Example 8. Proper Use of the Noun Before Adjectives Pattern



instead of




instead of


4.4.2 Adjective Order

The Developer should consider that Concepts are often sorted alphabetically by end users without regard to Concept relationships.

When multiple adjectives are being used to modify a noun, the order of precedence set in Table 6. Adjective Order MUST be followed.

Table 6. Adjective Order


Relating To












Physical Quality






















Operating, Other

† The Examples in this column are non-normative.

Developers SHOULD NOT use adjectives related to quantity in Concept names.

4.5 Concept Naming

4.5.1 Concept Naming Rules

Concept names SHOULD be derived from the Subject they represent. Concept names MUST follow the XBRL 2.1 specification for element names.

Concept names SHOULD adhere to upper camel case. Upper camel case requires that each word in the Concept name begins with a capital letter with no intervening spaces or punctuation. The initial letter in a Concept name must be an upper case letter.

Example 9. Upper Camel Case Concept Names




Use the following additional rules for naming Concepts:

  • The first character of the Concept name MUST be a capitalized letter.
  • The Concept name MUST NOT contain special characters as defined by XML naming restrictions.
  • The Concept name MUST NOT contain the word “Total” or any synonym of that word. The fact that a value is a “total” SHOULD be expressed using calculation relationships.
  • Optionally, connective words and conjunctions that normally would be used to describe the Concept’s subject MAY be omitted from the Concept name provided that such omissions are consistent throughout the Compliant Taxonomy.

4.5.2 Concepts and Data Types

Concepts MUST use data types from the XBRL 2.1 specification or data types included in the Data Type Registry (DTR) . New data types MAY be created but SHOULD be more restrictive forms of the data types specified by XBRL 2.1 or the Data Type Registry.

Data that can be expressed using multiple data types SHOULD have multiple Concepts to describe it. In this instance, each Concept SHOULD have a name that reflects its data type. Concepts that have a single data type do not need to indicate the data type in its name.

Concept names for Concepts that describe nonmonetary data MUST contain a descriptor indicating the type of data the Concept represents. This is to avoid having Concepts with different data types that have indistinguishable names. Users should be able to determine which Concept to use for data without the need to reference a Concept’s data type.

Example 10. Concepts with Names That Express Data Type





4.5.3 Concepts and Dimensions

Concept names that express dimensional components SHOULD contain the appropriate component name at the end of the Concept name, as per the rules below:

  • Member Concepts SHOULD end with “Member.”
  • Axis Concepts SHOULD end with “Axis.”
  • Domain Concepts SHOULD end with “Domain.”
  • Line item Concepts SHOULD end with “LineItem.”
  • Table Concepts SHOULD end with “Table.”

4.5.4 Concepts and Tuples

Each tuple MUST have a companion Concept that facilitates searching, for consumers, by providing a textual version of the tuple data as a single value. Additionally, providing this Concept helps to organize the taxonomy and makes it more readable.

This equivalent Concept SHOULD have a name that is the plural form of the subject of the tuple. This is because the textual equivalent Concept will contain all data tagged by the tuple.

4.6 Financial Term Guidance

4.6.1 Guidance for Using Financial Terms in Concept Names

Direct cash flow Concepts MUST contain “Proceeds” for Concepts describing cash inflows and “Payments” for Concepts describing cash outflows.

Indirect cash flow Concepts MUST use “IncreaseDecrease” or “FromUsedIn” for net Concepts.

Example 12. Proper Naming for Cash Flow Concepts




Concepts that represent data valued “at Cost” or “at Fair Value” SHOULD describe the valuation method in the Concept name. This description SHOULD appear after the noun and use “at” to represent “valued at”.

Example 13. Proper Naming for Valuation Concepts



4.6.2 Preferred Adjectives for Accounting

The following preferred adjectives MUST be used:

Table 7. List of Preferred Adjectives for Data

Preferred Adjectives



Beginning Balance

Ending Balance

at Cost

at Fair Value







Net of Tax

Gross of Tax

Return to Table of Contents

5. Labels

5.1 Overview of Labels

The guidelines in this section apply to all Labels, including the Documentation Label. There are additional guidelines for Documentation Labels in 6. Guidelines for Documentation Labels of the Style Guide.

Two common errors that domain experts make while trying to create a taxonomy are worth noting:

(a) using a sentence from a disclosure checklist as the Label; and

(b) accepting a financial statement or other line item description as a Label,

without verifying that either of the above accurately and sufficiently describes the expressed Concept.

It is the task of the taxonomy developer to provide the shortest possible Label which contains sufficient information to describe the meaning of a Concept. The precise meaning of a Concept is provided by taxonomy documentation, references and element relationships. However, it is valuable to users and consumers to be able to accurately discern the meaning of a Concept without needing to reference the documentation or other materials.

The primary goals of creating a standard form for all Labels within a taxonomy are:

  1. To provide users with Labels that are clear and consistent and that minimize the need to use documentation resources or other reference materials to ensure data is being tagged by the correct Concept.
  2. To provide enough information within Labels to maximize Label usability and uniqueness, while minimizing Label length and complexity.

Taxonomy developers MUST provide, at a minimum, one unique Standard Label and one unique Documentation Label for every Concept in the Compliant Taxonomy. Users should not be required to refer to the Concept name to ensure that they have the appropriate Concept.

5.2 Label Roles

Before creating Labels, the taxonomy developer MUST determine the Label Roles for the taxonomy. All Compliant Taxonomies MUST have a Standard Label Role and MUST have a Documentation Label Role. All other Label Roles are optional and can be used to apply specified characteristics to a Concept. If a Concept is expected to be used with a particular Label Role, Developers MUST include a Label for that Label Role.

Developers SHOULD refer to the XBRL 2.1 specification Table 8 for standard Label Role attribute values and the XII Link Role Registry (LRR) prior to creating new Roles for the Compliant Taxonomy. Developers MAY create new Label Roles for usages not specified in Table 8 or the LRR.

It is RECOMMENDED that the Standard Label Role matches the Concept name with proper punctuation, capitalization, and spacing with human-relatable word ordering.

It is recognized that taxonomy revisions may result in changes to the Standard Label Role. In such cases, the Standard Label Role will not match the original Concept name. Concept names SHOULD NOT be changed during taxonomy revision due to a revision of the Standard Label. A common reason for a Standard Label change would be a governing body making a change to the nomenclature surrounding a Concept. The Subject of the Concept has remained the same, while the language used by humans to describe it has changed. In this case, the Standard Label would be revised; the Concept would not.

5.3 Language Usage

The guidelines stated in 3. Language Guidelines
also apply to Labels. The section below provides additional guidance specific to language associated with Labels.

5.3.1 Use of Dashes

Dashes SHOULD NOT be used in Labels (except tuples) where commas can be used instead. For example, DO NOT use “Assets – Current”, but rather use “Assets, Current.”

Dashes MUST NOT be used to represent a minus sign. Dashes MUST NOT be used to represent a range. A range in a Label SHOULD be spelled out using “to”.

5.3.2 Acronyms

Acronyms SHOULD be spelled out, followed by the acronym initials in parentheses.

Acronyms MAY be used alone if the acronym itself is more commonly understood by the target end users than the acronym’s meaning. When using an acronym, all letters in the acronym SHOULD be capitalized.

5.3.3 Abbreviations

Abbreviations SHOULD NOT be used in Labels except in the Documentation Label.

When abbreviations are used, usage MUST be consistent.

Periods MAY be used in abbreviations, but period usage in abbreviations MUST be consistent.

5.3.4 Comma Usage in Lists

In a series of three or more items, commas MUST be used after each item, including the penultimate item. A comma SHALL be used before the final “and.”

Example 11. Acceptable Comma Usage in a List

Property, Plant, and Equipment

5.3.5 Combinations

The combination “and/or” SHOULD NOT be used. Use “and” to express “and/or.”

5.3.6 Expressing Numbers

Use the following additional rules for numbers in Labels:

  • Labels SHOULD NOT start with a number.
  • Numbers SHOULD be treated alike throughout a Label; do not use figures for some and spell out others. If the largest number is 10 or more, use figures for all numbers. For example, “Investments, Year 6 Through 10”.
  • At the beginning of a sentence in the Documentation Label, a number that would ordinarily be written in figures SHOULD be spelled out, regardless of the inconsistency this may create.
  • (OPTIONAL) When a Label contains an example with numbers, those numbers do not need to be spelled out.

Example 12. Acceptable Use of Numbers in Labels

Long Term Debt, Maturing in Years Four and Five

Financial Guarantee Insurance Contracts, Future Expected Premium Revenue to be Recognized, Year 11 Through 15

5.4 Capitalization

Labels except the Documentation Label SHOULD use title capitalization as set forth below:

  • Capitalize nouns, pronouns, verbs, adjectives, adverbs and subordinating conjunctions.
  • Do not capitalize articles, prepositions, coordinating conjunctions and “to” if using an infinitive.

5.5 Hyphen Usage

Generally, words formed with the following common prefixes SHOULD NOT be hyphenated.

Table 8. Common Prefixes


Example of Proper Usage





















Developers SHOULD use the following rules for hyphens:

  • Use a hyphen if the second element is a proper noun, a capitalized word, or a numerical figure.
  • Use a hyphen if it is necessary to distinguish homonyms.
  • Use a hyphen if the second element consists of more than one word.
  • Use a hyphen to avoid doubling a vowel (except after the short prefixes co, de, pre, pro, and re, which generally are printed solid).
  • Use a hyphen before a compound term.
  • Use a hyphen to separate the repeated terms in a double prefix.
  • Use a hyphen when a prefix or combining form stands alone.
  • Use a hyphen as part of adjectival phrases.
  • Use a hyphen in compound terms if a root word ends in a double consonant and its suffix begins with the same consonant.
  • Use a hyphen in compound terms if the first element is a proper name.


Example 13. Examples of Proper Hyphen Usage



Second element is a proper noun


Second element is a figure


To distinguish homonyms


Second element consists of more than one word

pre-nuclear-age civilization

To avoid doubling a vowel


Before a compound term


To separate the repeated terms in a double prefix


When a prefix or combining form stands alone

over- and underused

As part of adjectival phrases


If a root word ends in a double consonant and its suffix begins with the same consonant


If the first element is a proper name


5.6 Label Descriptions

5.6.1 Labels for Numerical Concepts

For Concepts that represent nonmonetary or nontext data, the corresponding Label(s) SHOULD start with an appropriate descriptor. These include Concepts that are decimals, percentages and dates.

Table 9. Common Appropriate Descriptors to Begin a
Label for a Nonmonetary or Nontext Concept

Descriptive Text

Percentage of…

Date of…

Number of….

Average Number of …

Weighted Average Number of …

5.6.2 Labels for Textual Concepts

For Concepts that represent textual data, the corresponding Label(s) SHOULD start with an appropriate descriptor that explains the nature of the text.

Table 10. Common Appropriate Descriptors to
Begin a Label for a Textual Concept

Descriptive Text

Explanation of …

Description of …

Reason for ….

Method of …

Nature of …

Basis for …

Name of …

5.6.3 Sign Representation

For Concepts that can be either negative or positive, the Concept Label MUST use parentheses () to indicate which Concept will be represented as negative values in the instance document. Parenthesis MUST NOT be used for other purposes.

There are occasions in an instance document when the value of a Concept could be either positive or negative. A space SHOULD appear between the positive item and the opening parenthesis. A slash SHOULD NOT be used. The positive item should always appear before the negative item.

Example 14. Proper Sign Representation Within Labels

Gains (Losses)

Increase (Decrease)

Surplus (Deficit)

from (used in)

Retained Earnings (Accumulated Losses)

Earnings (Losses)

Losses (Reversals)

Purchase (Sale)

from (to)

Income (Expense)

5.6.4 Total Labels

The word “total” or any synonym of “total” SHOULD be used only for the Total Label Role.

5.6.5 Authoritative References

Labels SHOULD NOT include the name of authoritative literature. Developers SHOULD use the reference linkbase to add references to Concepts.

Labels MAY contain references when the Concept describes a change due to a specific rule change or update from a governing body where the reference distinguishes the Concept from similar Concepts.

5.6.6 Period Start and Period End Labels

Labels using the period start Label Role MUST end in the following phrase “, Beginning Balance”.

Labels using the period end Label Role MUST end in the following phrase “, Ending Balance”.

5.6.7 Labels for Tuples

The Label for the tuple Concept MUST follow the normal Label guidelines from this guide.

All Tuple Labels MUST be singular.

Each Concept used in the tuple MUST have a Label in the following format:

{Tuple Label} – {Label describing the second Concept}

In the case of nested tuples, developers SHOULD only use the Label of the tuple which directly holds the item when creating the Label.

Developers MAY shorten the Tuple Label for the Labels of Concepts in the tuple as the Labels may get exceedingly large.

Example 15. Tuple Labels

Given the example tuple (excerpt from XBRL 2.1 specification Example 22):

<element name=”managementName” type=”xbrli:tokenItemType” xbrli:periodType=”instant”substitutionGroup=”xbrli:item”/>

<element name=”managementTitle”type=”xbrli:tokenItemType” xbrli:periodType=”instant”substitutionGroup=”xbrli:item”/>

<element name=”managementAge” type=”xbrli:nonNegativeIntegerItemType”

<element name=”managementInformation”substitutionGroup=”xbrli:tuple”>   <complexType>


      <restriction base=”anyType”>


          <element ref=”s:managementName”/>

          <element ref=”s:managementTitle”/>

          <element ref=”s:managementAge” minOccurs=”0″/>


        <attribute name=”id” type=”ID” use=”optional”/>





Use these Labels (respectively):

“Management Information – Manager Name”

“Management Information – Manager Title”

“Management Information – Manager Age”

“Management Information”

Example 16. Shortened Tuple Labels

Given the Tuple “EnvironmentalLiabilitiesRemediationProject” with the following secondary Concepts:








Use these Labels (respectively):

“Environmental Liabilities Remediation Project” (Label for Tuple)

“Remediation Project – Remediation Project Description”

“Remediation Project – Costs Accrued to Date”

“Remediation Project – Anticipated Costs”

“Remediation Project – Explanation of Possible Additional Losses”

“Remediation Project – Undiscounted Amount of Liability”

“Remediation Project – Discount Rate Used to Estimate Liability”

“Remediation Project – Explanation of Expected Future Payments”

Tuple Concepts SHOULD have a textual equivalent Concept. This equivalent Concept SHOULD have a Label that begins with “Schedule of” followed by a plural version of the Label of the tuple.

Example 17. The Label for a Textual Equivalent Concept to a Tuple

“Environmental Liabilities Remediation Project” (Label for Tuple)

“Schedule of Environmental Liabilities Remediation Projects”

5.7 Label Suffixes

Label suffixes add clarity to the taxonomy structure. Suffix types MUST be contained in brackets [ ] and brackets MUST only be used to denote suffix types.

The “[Abstract]” suffix MUST be used to delineate abstracts Concepts. This section contains additional Label suffixes that are RECOMMENDED but not required. If one suffix type other than “[Abstract]” is used, all suffix types MUST be used.

5.7.1 Abstract

Developers MUST append the suffix “[Abstract]” to the Label for abstract Concepts.

5.7.2 Axis

Developers MAY append the suffix “[Axis]” to the Label for hypercube Concepts.

5.7.3 Domain

Developers MAY append the suffix “[Domain]” to the Label for dimensional member Concepts used as the dimension-default Concept.

5.7.4 Members

Developers MAY append the suffix “[Member]” to the Label for dimensional member Concepts.

5.7.5 Line Items

Developers MAY append the suffix “[Line Items]” to the Label for dimensional line item Concepts.

5.7.6 Table

Developers MAY append the suffix “[Table]” to the Label for table Concepts.

5.7.7 Default

Developers MAY append the suffix “[Default]” to the Label for the default member that is not the domain.

5.7.8 No Default

Developers MAY append the suffix “[No Default]” to the Label for typed dimensions.

5.7.9 Text Blocks

Developers MAY append the suffix “[Text Block]” to the Label for Concepts that express large portions of textual data such as a Note.

5.7.10 Deprecated Concepts

Developers MUST append “[Deprecated]” to the Label for Concepts that are to be retired and should not be used by preparers.

5.7.11 Other Suffixes

Developers MAY append other suffixes to the Labels for Concepts to aid end users in identifying groups of Concepts that pertain to similar disclosures or that are structurally alike. Developers SHOULD be consistent in the use of other suffixes.

Return to Table of Contents

6. Guidelines for Documentation Labels

The guidelines stated in 5. Labels also apply to the Documentation Label. The section below provides additional guidance specific to language associated with the Documentation Label.

All Concepts MUST have a Documentation Label that accurately and concisely describes the Concept and its properties. The Documentation Label SHOULD help the users differentiate between similar Concepts in the taxonomy.

Words that are disallowed in other Label Roles MAY be used in the Documentation Label as part of the explanation for a Concept unless otherwise stated in this Style Guide.

6.1 Creating Accurate Documentation Labels

The goal of the Taxonomy Vernacular is to enable end users to identify Concepts without using outside reference materials. The Documentation Label MUST be used to provide information about the nature of a Concept such that an end user or consumer can clearly understand the tagged data. Therefore, the documentation Label SHOULD contain enough information to clarify questions end users might have about the intended use of a Concept. However, the Documentation Label SHOULD NOT contain so much outside information as to make Concept decisions overly time-consuming or complex.

Concepts MAY be derived from a governing document for the data. This governing document will aid developers in providing clear and consistent Documentation Labels for end users. If no governing documents are available, then the Compliant Taxonomy will become the governing document.

Documentation Labels derived from a governing document SHOULD be conformed to the Style Guide.

The Documentation Label SHOULD contain the following components in the order stated below:

  1. The Documentation Label SHOULD first identify the data type of the Concept using plain English.
  2. The Documentation Label SHOULD secondly include a description of the Concept derived from a governing document, authoritative literature or other resources.
  3. The Documentation Label SHOULD thirdly identify the components of the Concept (if applicable).
  4. The Documentation Label SHOULD fourthly identify the components that the Concept does not include when such components are included in a related Concept.
  5. (OPTIONAL) The Documentation Label can fifthly include the format of the data when clarification is needed.

Use the following guidelines when forming the description of the Concept:

  • Developers SHOULD NOT include accounting recognition or measurement guidance.
  • Developers SHOULD NOT include the Standard Label of the Concept in the Documentation Label.
  • Developers SHOULD NOT include a reference to specific rules or regulations in the Documentation Label but rather use the reference linkbase. Documentation Labels MAY contain references when the Concept describes a change due to a specific rule change or update from a governing body where the reference distinguishes the Concept from similar Concepts.

6.2 Punctuation

Developers SHOULD use full sentences in the Documentation Label where possible. The Documentation Label MUST end with a period.

Return to Table of Contents

7. References

The following guidelines apply for creating references.

7.1 Reference Consistency

All reference parts MUST be consistent across the entire taxonomy framework. This is particularly true of the publisher and regulation name.

7.1.1 Distinct References

Each reference SHOULD be a distinct reference. A reference link should not consolidate reference components.

Example 18. Shortened Tuple Labels


ASC 230-10-45-25(a)

ASC 230-10-45-25(c)

Instead of:

ASC 230-10-45-25(a),(c)

7.1.2 Presentational References

For presentational disclosure references the presentation Reference role attribute MUST be used. (

7.1.3 Released Taxonomy Versions

To indicate changes to the taxonomy over time the change note role defined by the FASB SHOULD be used. [requires further documentation and should be part of XUS guidance, perhaps the same so as to not conflict with FASB, see]

TaxonomyVersion: Taxonomy Version in CCYY format.

ChangeDate: Date change was made in the taxonomy in CCYY-MM format.

SourceName: Source for change label. Examples include: Extraordinary Items; Revenue Recognition

NewElement: Identifies new elements

ElementDeprecated: Identifies deprecated elements

ModifiedDeprecatedLabel: Identifies modified Deprecated Label

ModifiedReferences: Identifies reference changes

ModifiedLabels: Identifies modified Standard, Period Start, Period End, or Total Labels

ModifiedDocumentation: Identifies modified Documentation Label

PreviousDocumentation: Provides the definition (documentation label) of the element as defined from the prior version of the Taxonomy

DeprecatedDate: Deprecation date in [CCYY-MM] format

DeprecatedLabel: Provides the details of the deprecated element. Specifically, the reason that the element was deprecated and the new elements that may be used, if applicable

ModifiedBalanceType: Identifies that the balance type attribute on an element has been adjusted

ModifiedPeriodType: Identifies that the period type attribute on an element has been adjusted

ModifiedDataType: Identifies that the data type attribute on an element has been adjusted

7.1.4 Taxonomy Specific Reference Roles

Taxonomy specific references can be defined but they must not replicate reference roles already defined by, or
[are there any SEC?]

7.2 Standard Reference Roles

References MUST be identified by the standard reference role. The XBRL Specification offers several roles for identifying the type of reference that is being used. URI’s should only be included if links are guaranteed to be stable through time.

7.3 Reference Changes

Reference parts that contain a URI should only be included if links are guaranteed to be stable through time.


A References (non-normative)

FRTA Financial Reporting Taxonomies Architecture 1.0 Recommendation with errata corrections dated 2006-03-20. Walter Hamscher (editor).
ISO International Organization for Standardization.
ISO 4217 Currency codes, ISO 639 Language codes, ISO 3166 Country codes, ISO 8601 international standard numeric date and time representations.
USFR U.S. Financial Reporting Taxonomy Framework
LRR XBRL Link Role Registry, Recommendation of

Walter Hamscher (editor), Hugh WallisUCUM

The Unified Code for Units of Measure

Schadow, G. and C. J.  McDonald. words for use in RFCs to Indicate Requirement Levels, March 1997. Scott Bradner Business Reporting Language (XBRL) 2.1 Recommendation with corrected errata to 2005-11-07. Phillip Engel, Walter Hamscher, Geoff Shuetrim, David vun Kannon, Hugh Wallis Linking Language (XLink) Version 1.0. Steve DeRose, Eve Maler, David Orchard

B Intellectual Property Status (non-normative)

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to XBRL International or XBRL organizations, except as required to translate it into languages other than English. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (


The attention of users of this document is directed to the possibility that compliance with or adoption of XBRL International specifications may require use of an invention covered by patent rights. XBRL International shall not be responsible for identifying patents for which a license may be required by any XBRL International specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. XBRL International specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. XBRL International takes no position about the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Members of XBRL International agree to grant certain licenses under the XBRL International Intellectual Property Policy (

C Acknowledgements (non-normative)

This Style Guide could not have been written without the contributions of many people.

The participants in the Domain Steering Committee, XBRL Domain Working Group, public commentators, and personal advisors all played a significant role.

D Document Revision History (non-normative)

Date Editor/Contributor Activity
Revised Base Style Guide
2017 – April

2016 to 2017

Scott Theis (Novaworks)Editors:
Campbell Pryde (XBRL US)
Erin Rybinski (Novaworks)
Michelle Savage (XBRL US)
David Theis (Novaworks)Contributors:
Lisa Cousino, CPA (Summit Financial Printing)
Joel Stiebel, CPA (Stiebel Associates)
Rob Nehmer (Oakland Univ)
Yemisi Lawal, CPA (Exelon Corp.)
Revised and reorganized Style Guide, removed US GAAP specific information and created base version.
Non-Ratified 2007 Version
2007-01-09 Domain Call Amended for issues that were identified as part of the SME training
2006-10-13 Charles Hoffman Tuned document from conference call review.  Added examples. Removed all comments that were addressed.  Accepted changes where consensus exists.
2006-10-13 Campbell Pryde

Charles Hoffman

Paul Sappington

Eric Linder

Reviewed document incorporating changes via conference call. Completed through the “Guidelines for Documentation” section.
2006-10-11 Charles Hoffman Went through IFRS-GP taxonomy recalling rules used and added them to the Style Guide
2006-10-10 Eric Linder Added various items and comments
2006-10-06 Charles Hoffman

Campbell Pryde

First draft of the Style Guide

E Taxonomy Vernacular Examples

[insert example based on various industries or business data, table should contain concept name, at least on label (preferably standard and documentation) and comments as to how and why. It obviously must conform to the Style Guide]

Return to Table of Contents

This public exposure version was available for comment until July 15, 2017.
Return to XBRL US Style Guide || Review comments and DSC responses

Topic -

2 comments on “XBRL US Style Guide (Public Review Version)”

  1. Charles Hoffman says:

    The terms and definitions are extremely helpful. However, they can be made more helpful if they are precise, unambiguous definitions.

    The term “context” is really syntax and should not be included, or included and stating that it defines syntax rather than semantics. I would propose the following two definitions:

    Fact: A fact defines a single, observable, reportable piece of information contained within a business or financial report, or fact value, contextualized for unambiguous interpretation or analysis by one or more distinguishing characteristics. Facts can be numbers, text, or prose.

    Characteristic: A characteristic describes a fact (a characteristic is a property of a fact). A characteristic provides information necessary to unambiguously describe a fact and distinguish one fact from another fact. A fact may have one or many distinguishing characteristics.

    Finally, while “Concept” is defined although the definition is not precise; Table (or hypercube), Axis (or dimension), Member, Line Items (or primary items). Something that is an “Element” could be further categorized as a Concept, Table, Axis, Member, Line Items, or Abstract. Precise definitions of these categories are very useful to software developers creating software that is easy for business professionals to use.

  2. Laura Rusu says:

    Email with some feedback sent today to DSC Chair.

Comments are closed.


Terms and Conditions