1 Conventions

• Elements from the XBRL Global Ledger Framework are indicated within straight brackets. For example, [entryDetail].
• Enumerated values from the XBRL Global Ledger Framework are indicated within curly brackets. For example, {voucher}.
• Elements from the XBRL Specification are indicated within angle brackets. For example, <schemaRef> .

2 Language independence

The official language of XBRL International's own work products is English and the preferred spelling convention is UK English.

3 Introduction

XBRL's Global Ledger Framework (XBRL GL) represents the information that is found in the General Ledger and sub-ledgers of multinational (and small business) operational, business and accounting systems, bridging information from original transaction to end reporting. Some of the data found in an accounting system is not historical in nature, but serves instead as a "library" of entries for later reuse. In this document, we discuss XBRL GL’s special data fields for maintaining master transaction/entry records used for reminders or as templates for later reuse.

These are "templates" as found in source (or as required in target) accounting/ERP applications. But XBRL GL can also be used to provide templates - pre-established structures of XBRL GL tags with missing or sample data - that help its own implementation, guiding consuming applications in the interpretation of different types of XBRL GL data or providing mapping information between different sets of XBRL GL, XBRL or XML data. These "templates for XBRL GL" and mapping templates will also be discussed in this document.

4 Need for Template Entries

There is information found within business and accounting systems that goes beyond historical records. Some entries are made to make planning and operations more efficient. Examples of these entries:

5 XBRL GL Elements

Where do you find the elements that you would use to create these representations? Most of them are found in the USK (US-UK Advanced Accounting) module. They were included in USK as we were told in the past that some countries’ regulators, where tracing entries to their manually posted source is especially important, would be concerned about any applications that included these capabilities. (This lets you know that some of the data fields in XBRL GL are more meaningful in some regions and business environments than others.)

6 Discussion?

Most people are surprised when they find out about the depth and the breadth of XBRL GL’s representative power. When they find out that XBRL GL can represent templates, libraries of entries maintained by many accounting products, they ask, “When would you ever want to move these templates from one system to another? They aren’t real entries! It is foolish to be able to represent them.”

XBRL GL’s ability to represent templates is useful for many reasons. Here are just three:

• Data migration: if you need to move from one accounting system to another, why should you need to reenter all of these templates just because they aren’t “real entries”? They are an important part of the setup of the system.
• Data communication: the templates may be prepared by another part of the organization or an external entity. Standardization facilitates the exchange between parties. As we will be exploring in more detail, the USSGL is an example of such templates prepared by a third party and shared amongst the federal agencies and departments.
• Audit and control purposes: an auditor who has standardized access to templates reflecting anticipated entries can find evidence about intentions that have not yet been committed.

7 Templates "for" XBRL GL

One of the greatest values of XBRL GL is its flexible structure and the broad representational power that comes with it. XBRL GL can represent business and accounting data as found in any ERP system or accounting application, which means that its 350 elements or so can be combined in different ways to represent such different things as trial balances, ledgers, sub-ledgers, invoices, fixed assets lists, orders, bills of lading, project costing reports, and accounting entries. This is obviously a good thing, but it also represents the biggest challenge for those who approach XBRL GL and that sometimes find it difficult to understand the underlying data model and to apply it consistently for all these different purposes.

There are different ways to deal with this issue and to provide guidance for XBRL GL implementations. The XBRL GL Working Group has published a set of "best practice" annotated instance documents, available as a Working Group Note at the XBRL International web site [XBRL GL WGNs] or at [GaLaPaGoS]. These annotated instances show a best practice approach to the representation of specific documents, and provide possible alternatives and comments about the reasons for choosing one approach over another.

Discussions are under way between the XBRL GL WG and representatives from OMG ^{[ 1 ]} for a joint effort to create Unified Modeling Language (UML) models of how XBRL GL can be used to represent different documents, This will be another important tool to document the use of XBRL GL in different applications in a format that can be easily consumed and "understood" by software developers and IT professionals.

Moving from an educational/documentation oriented perspective to a more practical approach focused on implementation, an XBRL GL instance is perhaps the most immediate way to provide guidance on what fields and what structure should be used to represent a certain document with XBRL GL.

One template instance can be created for each type of document that needs to be represented, with an approach similar to the one used in the best practice annotated instances mentioned above, but intended for automatic consumption by a software application rather than for "human" use. The template can be used to guide the automatic consumption of an incoming XBRL GL document, or to provide indications on the fields required to generate one. If appropriate some fields in the template can be pre-populated with values that can be used as defaults in the generation/consumption process.

Also, a template can help firm up the basic set of elements "necessary and sufficient" to represent, say, an invoice, while still allowing the producing or consuming applications to add more information as required in a specific case. When you extend an XBRL FR taxonomy, you know that if you add your own elements and sum them up to existing elements in the base taxonomy then you will not have to worry about introducing data comparability issues. In the same way, you can add more information to an XBRL GL template knowing that any consuming application will still have what is required to unequivocally process the document, and interoperability will be guaranteed.

8 Mapping Templates

In its simplest and more immediate form, a mapping template in XBRL GL provides mapping information between two different representations, for example two (or more) different chart of accounts for consolidation purposes. In this case, two [account] structures, each one representing one CoA, are held together by an [entryDetail] structure to indicate to the processing application that one account (usually identified with a "primary" value of [accountPurposeCode]) maps to the other (usually identified with a "consolidating" value of [accountPurposeCode]) like in the fragment of XBRL GL instance below:

This simple model can be extended to cover cases in which the mapping from one account to another is not a 1 to 1 mapping, and the exact allocation depends on the value of other fields, like for instance products, departments, business units etc. This additional information can be included in the template, so that conditional mapping information like "if the department is 001 the primary account 100 maps to the consolidation account 1010, but if the department is 002 the primary account 100 maps to the consolidation account 1020" becomes easy to standardise.

A similar approach can be used to provide mapping information from detailed XBRL GL data to summarized data represented in XBRL FR or other formats based on XML. This is the space of the Summary Reporting Contextual Data (SRCD) module of XBRL GL. In this case the mapping is represented by one multiple [xbrlInfo] structures, one for each target XBRL FR or XML summarized representation, held together by an [entryDetail] structure, that also contains the detailed information being mapped. In the most basic situation one account can be mapped to one target element in an XBRL FR taxonomy:

Again, more complex conditional mappings can be represented including the additional information required to define the conditions in the template.

9 Conclusion

XBRL GL represents master files, transactions, history files, status files – and templates of entries (ledger and sub-ledger/operational). Key fields in XBRL GL are important for delineating the definitions and limits that relate to template entries – whether you call them master, repeating, recurring, standard or simply template entries.

One should always try to eat one's own dog food - and templates for XBRL GL and mapping templates help us do just that by putting XBRL GL's flexibility and representational power at work to facilitate XBRL GL based implementations.