1 Motivation (non-normative)

To effectively exchange business reporting information between a producing and a consuming application often requires the applications to perform validation on data types and values, apply consistency checks, test data quality, augment the data with calculated values and possibly corrections, and to provide feedback to the producing application that indicates the nature and severity of problems encountered. A producing application may also add calculated values and perform tests on its own outputs before sending results to consuming applications. Applications based on the exchange of spreadsheets that contain both data and formulas are common but present maintenance problems; here the intent is explicitly to separate the representation and location of formulas and validation criteria from a given instance.

These different functions are characteristic of many XBRL-enabled applications. That is because it is a goal of XBRL to allow applications to consume XBRL formatted business information no matter what its original source. Data entry validation (e.g., prohibiting dates such as February 31, 2001 from entering the system) is a familiar example of using a formula to flag errors, but the breadth and scope of formulas is much broader than this. Good information management practice generally recognizes that validations should be tested, adhered to, and corrections made as far “upstream” in an information supply chain as possible – recognizing, of course, that the same tests may be applied repeatedly as data makes its way from its many possible origins, to its many ultimate destinations.

Any general programming language could be used to perform computations on business data. However, there is regularity in business reporting information: regularity that is encoded in XBRL in instance constructs such as “facts,” “periods,” “entities,” and in taxonomies as items, definitions, and other relationships. Furthermore, applications that consume XBRL formatted data should be able to “publish the formulas” that govern documents containing XBRL data, so that producing applications can test and apply those formulas and thereby reduce delay, rework and retransmissions, and smooth and accelerate the flow of business reporting information.

Rule languages—in which rules are expressed as patterns to be matched and actions to be taken when the data matches the pattern—have a rich tradition and are nearly as old as computer science itself ([Newell, 1962]). They enjoyed a heyday in the 1980’s for the programming of “expert systems”, and today rule languages live on in languages such as Prolog, and in commercial products such as the Blaze Rule Engine [HNC] and JRules [ILOG]. Rule languages tend to be fairly compact and concise and resemble a database of logical sentences (“all people are mortal” “if X is a mountain, then the elevation of X must be positive”). They declare the rules to be obeyed, and an interpreter (or compiler) is responsible for efficiently executing the rules (matching patterns and executing actions) correctly when presented with incoming data.

Even if the goal of synthesizing information is set aside so as to merely detect violation of constraints, XML Schema [XSDL] itself is still not sufficient to this task because it allows the validation of individual data elements (“Revenues are a 12-digit nonnegative number”) and structural relationships (e.g., “an invoice must contain a header, a list of items, and an amount”) but does not express constraints between elements, also known as co-constraints (“if more than 10 dependents are claimed then Schedule K must be completed”). Besides, the nature of rules is that they generally compute a whole series of results, some of which may be considered fatal errors, others as warnings, others as merely informational; an XML Schema validator mainly detects fatal errors. Other general programming languages, including XML Schema Transformation [XSLT], could be pressed into service since they have the requisite pattern-action structure, but these neither take any account nor take any advantage of the constrained nature of XBRL instances, taxonomies, and so on.

XBRL-specific formulas are well motivated. The language would be, like XBRL itself, suitable for publishing and transporting between applications; it would exploit the XBRL language itself, and provide a concise and well constrained way of expressing common rules such as “Net Receivables cannot be negative,” “Net revenues are the difference between Gross revenues and Gross expenses,” “Unless income for the previous quarter was zero, income growth for the quarter is the ratio of the change in income between the current and previous quarter, divided by the income of the previous quarter,” and so on. The earliest discussions of XBRL acknowledged the need to express not only specific numeric facts (“1988 Revenue for TLA Inc. was $40m”), but also relationships among those facts (“TLA Inc. revenue consists of TBD Inc. revenue plus BFD Ltd. revenue less eliminations”) and general relationships (“The write down allowance for an asset in any year after 1993 is limited to 25% of its original purchase price”). There has now been sufficient experimentation and implementation experience with XBRL for the exchange of business reporting information in live and planned applications to have illustrated both the need for an extension to the language to meet this need, as well as illustrating deficiencies in schemes used to date and the typical patterns of usage and the limitations on what that language actually needs to cover. This information is advantageous to have because it limits the scope and guides the design of the language.

1.1 Terminology and formatting conventions

Terminology used in XBRL frequently overlaps with terminology from other fields. The terminology used in this document is summarised in Table 1.

Table 1: Terminology

abstract element, bind, concept, concrete element, context, Discoverable Taxonomy Set (DTS), duplicate items, duplicate tuples, element, entity, equal, essence concept, fact, instance, item, least common ancestor, linkbase, period, taxonomy, tuple, unit, taxonomy schema, child, parent, sibling, grandparent, uncle, ancestor, XBRL instance, c-equal, p-equal, s-equal, u-equal, v-equal, x-equal, minimally conforming XBRL processor, fully conforming XBRL processor.

As defined in [XBRL].

must, must not, required, shall, shall not, should, should not, may, optional

See [RFC2119] for definitions of these and other terms. These include, in particular:

SHOULD	Conforming documents and applications are encouraged to behave as described.
MUST	Conforming documents and consuming applications are required to behave as described; otherwise they are in error.

expression

An expression using constants, variables, arithmetic, logical, and functional operators.

formula

An expression along with criteria that indicate the domain of each variable in that expression and how they are to be bound.

rule

The term “rule” is not used in this version of the requirement, although it appeared previously as a synonym for “formula”.

variable

A “variable” appears in expressions as a symbol that the application of a formula binds to a value, so that the expressions of that formula can be evaluated.

argument

An “argument” of a formula is a formal parameter bound to some portion of an input instance. Some of the arguments will be identified as variables to be used in expressions.

The following highlighting is used for positive examples:

Example 1: Example of an example

Counterexamples indicate incorrect or unsupported examples:

Example 2: Example of a counterexample

Non-normative editorial comments are denoted as follows and removed from final recommendations:

WcH: This highlighting indicates editorial comments about the current draft, prefixed by the editor’s initials.

Italics are used for rhetorical emphasis only and do not convey any special normative meaning.

Distinctively bracketed and coloured numbers {1.2.3} refer to that particular numbered section of the XBRL 2.1 Specification Recommendation [XBRL].

1.2 Normative status

This document is normative in the sense that any formula specification recommendations by XBRL International MUST satisfy the requirements as they are stated here.

This document version depends upon XBRL 2.1 Specification Recommendation [XBRL].

XBRL Specification 2.1 does not depend in any way upon this document.

1.3 Language independence

The official language of XBRL International’s own work products is English and the preferred spelling convention is UK English. Unless otherwise stated, XBRL specifications must not require XBRL users to use English in documentation, item, tuple, entity, scenario or any other elements.

2 Use cases

The general use case for an XBRL formula specification is the externalisation and publication of a set of formulas that will be applied by a consuming application:

· A financial regulator collecting quarterly balance sheets and income statements;

· A statistical agency collecting market valuations of various asset categories;

· A tax authority accepting electronic tax filings;

· A stock exchange accepting registration requests;

· A bank evaluating loan applications or checking loan covenants;

More specifically, there are general use cases that these consuming applications may have:

1. Test XBRL instances for consistency and signalling the failure of a formula, in the same sense that an inconsistent set of fact bindings for the summation-item arcs of a calculation linkbase signals an inconsistency.

2. Test XBRL instances for consistency and provide detailed messages for each formula that failed. In this case, general XML output for further processing and rendering as appropriate by an application is likely to be sufficient.

3. Creating a tuple-free XBRL instance based on existing XBRL instances. In this case, it is sensible for a formula processor to produce a valid XBRL instance. If producing applications verify that their own output will be accepted by those consuming applications, significant efficiencies are possible, particularly in a distributed environment such as the Internet.

4. Transforming, adjusting, or composing XBRL instances. By contrast with use case 3 in which fact order is not relevant, element order can be significant in tuples.

Use case 4 encompasses use case 3, which encompasses use case 2, which encompasses use case 1.

The examples are expressed as “consistent” and “inconsistent” fact sets for use cases 1 and 2, and as “before” and “after” fact sets and instances for use cases 3 and 4, along with a structured description of the relevant generalisation of the behaviour illustrated by that case.

The examples shown in the requirements all depend on a single taxonomy shown in Figure 1 consisting mainly of financial position and performance items.

Figure 1: Items Appearing in Examples

@name	@type	@periodType	Label (en, standard)
Assets	monetaryItemType	instant	Assets
CurrentAssets	monetaryItemType	instant	Current Assets
FixedAssets	monetaryItemType	instant	Fixed Assets
Equity	monetaryItemType	instant	Equity
Shares	sharesItemType	instant	Shares
Price	monetaryItemType	instant	Price
Earnings	monetaryItemType	duration	Earnings
AvgShares	sharesItemType	duration	Average Shares
PE	pureItemType	instant	Price-Earnings Ratio
ROE	pureItemType	instant	Return on Equity
EPS	decimalItemType	duration	Earnings per Share
AssetsEquity	pureItemType	instant	Assets-to-Equity Ratio
Rating	integerItemType	instant	Rating
AssetsOkay	booleanItemType	instant	Assets Okay
EquityOkay	booleanItemType	instant	Equity Okay
AssetsMessage	stringItemType	instant	Assets Message
AssetsLB	booleanItemType	instant	Assets in Lower Bound
AssetsUB	booleanItemType	instant	Assets in Upper Bound
AssetsLarge	booleanItemType	instant	Assets not too Large
AssetsSmall	booleanItemType	instant	Assets not too Small
IntangiblesPatents	monetaryItemType	instant	Intangibles (Patents)
IntangiblesClass	stringItemType	instant	Intangibles Class
IntangibleGross	monetaryItemType	instant	Intangible Gross
IntangibleReserve	monetaryItemType	instant	Intangible Reserve
IntangibleNet	monetaryItemType	instant	Intangible Net
IntangibleAsset	tupleType		Intangible Asset
AutoWriteDown	tupleType		Automobile Write-Down
AutoName	tokenItemType	duration	Automobile Name
AcquisitionDate	dateItemType	duration	Acquisition Date
WriteDownAllowance	monetaryItemType	duration	Write-Down Allowance
WDVBroughtForward	monetaryItemType	duration	Write-Down Value Brought Forward
UsefulLife	durationItemType	duration	Useful Life

All facts in the examples have a unitRef and contextRef drawn from the units and contexts shown in Figure 2 and Figure 4, respectively. The namespace prefix si refers to international standard scientific units.

Figure 2: Units Appearing in Examples

@id	measure
usd	iso4217:USD
gbp	iso4217:GBP
pure	xbrli:pure
shs	xbrli:shares
usdsh	iso4217:USD/xbrli:shares
gbpsh	iso4217:GBP/xbrli:shares
year	si:year

The namespace prefix co with elements aaa and bbb are used to distinguish segments of entity 444. The elements actual, budgeted and variance are used to distinguish scenarios.

Figure 3: Segments and Scenarios Appearing in Examples

prefix	element
co:	<aaa/>
co:	<bbb/>
co:	<actual/>
co:	<budgeted/>
co:	<variance/>

Figure 4: Contexts Appearing in Examples

@id	entity/ @identifier	entity/ segment	period/ instant	period/ startDate	period/ endDate	scenario
c01	333			2003-01-01	2003-12-31
c02	333		2002-12-31
c03	333		2003-12-31
c04	444			2003-01-01	2003-12-31
c05	444		2003-12-31
c06	333		2003-12-31
c07	444	<geo>ON</geo>		2003-01-01	2003-12-31
c08	444	<geo>ON</geo>	2003-12-31
c09	444	<geo>MI</geo>		2003-01-01	2003-12-31
c10	444	<geo>MI</geo>	2003-12-31

Name	Contact	Affiliation
Walter Hamscher	walter@hamscher.com	Standard Advantage / Consultant to PricewaterhouseCoopers

Geoff Shuetrim	gshuetrim@kpmg.com.au	KPMG LLP
David vun Kannon	dvunkannon@kpmg.com	KPMG LLP

Editors

Contributors

Status of this document

Table of contents

Table of examples

Table of figures

1 Motivation (non-normative)

1.1 Terminology and formatting conventions

1.2 Normative status

1.3 Language independence

2 Use cases