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

I keep a list of conceptually useless tools for appropriate occasions. Some examples include:

• Kerosene-powered electric blanket
• Inflatable hammer
• Smoke detector with a snooze button
• Frozen bandages for cold cuts
• Artificial appendix
• Waterproof sponge
• Parachute that opens upon impact

When it comes to more useful tools, some have a single function (“for hitting things”), and some are multi-purpose (“for dicing, slicing and making julienne fries ^{[ 1 ]} ). Sometimes it is difficult to tell the difference. (“When all you have is a hammer, everything looks like a nail.”)

Whether you think of XBRL GL as a hammer, a Swiss Army(TM) knife, or something in between, knowing how to work with XBRL GL’s generic representational capabilities is an important part to successful implementation.

The purpose of this document is to discuss in particular how some data fields have slightly different meanings when used as “defaults” or describers in master files and used differently in transactional representations.

To define a default value: In a typical system, files that provide “default” values are allowing the entry of a value that will be 1) automatically suggested; 2) used unless a specific value is provided by the user, or 3) used unless overridden in later entries of all sorts. As we will see, some fields in XBRL GL serve both purposes – and sometimes their use as a default may be less than obvious at first glance.

4 Building Blocks of XBRL GL

XBRL GL, the Global Ledger Taxonomy Framework ^{[ 2 ]} , is a growing set of interlocking XBRL 2.1 Specification ^{[ 3 ]} compliant taxonomies that act as one to allow organizations to interchange, in a standardized way, the information contained in business, operational and accounting systems’ databases. It is a unified generic conceptual model of this information, made up of a series of building blocks representing important aspects of these systems; these blocks are “assembled” in different ways to represent information as disparate in nature as setup files and master files, transaction files, history files, and summary reports - everything from a generic representation of the original source documents, through the audit trail information supply chain, and bridging to external reporting schemas.

The building blocks include:

• Detailed information about people and companies, including the reporting company, its accountants and advisors, and those involved at the detail level - customers, employees, vendors, salespersons and contractors.
• Information about things measured, traded, consumed or used, including inventory, supplies, services, fixed assets, metrics, and intangible assets. ^{[ 4 ]}
• Document-related information, such as document number, date, terms, received data and due date.
• Entry related information, such as account and nature of entries.
• Job costing information, including jobs and phases.
• Links to external reporting schemas, such as XBRL for Financial Reporting or proprietary tax document schemas.

Assembling the blocks in different ways (within the limitations of the framework and schema design) permits representation of a wide variety of information without needing to create entirely new sets of schemas for different types of documents and ad-hoc import/export needs. Reusing the same generic components may mean that those responsible for mapping from their database to XBRL GL representations have to spend more time understanding the existing taxonomy elements than being able to pick from specialized elements; but it keeps the taxonomy significantly smaller so learning the taxonomy is easier for new students and managing the taxonomies is easier for those responsible.

As XBRL GL is meant to represent all of the information stored in typical business operational and accounting systems ^{[ 5 ]} , we may be able to look to accounting systems for some ideas of classes of files and reports, and to consider whether there are any special distinctions that are important to consider.

5 Special Uses of XBRL GL

Certain categories of usage of XBRL GL to represent information will bring with them distinguishing characteristics. Some of these categories, unique attributes, and distinguishing characteristics are described in Table 1.

The [entriesType] enumerations are illustrated in Table 2. [entriesType] is the one required element in XBRL GL files, the first key to automated understanding of an XBRL GL instance.

As the table shows, some types of XBRL GL documents are master files and others are transactional files. There are other primary categories, including summary/status reports. These have unique characteristics that drive the use of the items. In addition, some design choices may also impact the use of those items ^{[ 6 ]} . There is much commonality, and some subtleties and distinctions to using our reusable components that merit discussion.

Use	entriesType	Comment
Setup file	Other	Setup files include Configuration files (which are generally application specific and rarely record-oriented) Support files I (salesperson, warehouse, terms) which support the creation of master files Support files II (pricing, discount, commissions, and authorized vendors for specific items) which associate master files with important information, and support transactional processing.
Master file	Account	Master files include customer master, vendor master, employee master, and inventory master. The account master is relied upon by other master files, making it a hybrid, but it is associated with this entriesType.
Generic document representation	Other	Representing listings of pre-accounting documents (“raw” invoices, time sheets and similar reports) do not have a specific entriesType.
Transaction file with accounting significance	entries journal ledger	See the definitions – various listings of entries.
Summary status report	assets	As we have discussed, the enumeration {assets} is confusing – this refers to reports that tie to the balance sheet: asset, liability or equity. This includes AR agings, AP agings, inventory stock status, job cost work in process (WIP) and fixed asset values.

Description	Examples	enumeration
Anything normally coded with the account structure	account, bank, employee, customer,job, vendor, fixed asset, statistical	account
Can tie to balance sheet	Aged AR, aged AP, inventory stock status, fixed assets/depreciation, job cost report	assets
Listings of tax tables	VAT, PST	taxtables
Directly related to journal entries and their summary in the GL proper	Source journal report, month end trial balance	entries journal balance ledger trialbalance
Summary status report	assets	As we have discussed, the enumeration {assets} is confusing – this refers to reports that tie to the balance sheet: asset, liability or equity. This includes AR agings, AP agings, inventory stock status, job cost work in process (WIP) and fixed asset values.

6 Finding Default With Others (See: “beam in your own eye”) ^{[ 7 ]}

As this document was meant to discuss how to use XBRL GL’s elements and structures both to represent “default” values and actual values, it would be good to actually get to that topic. How can this be approached? Let’s begin with an assumption – that defaults are established in setup files and master files. Some questions important to ask:

Question #1: How do you associate a default with the focus of the master file? See the section below Who Would You Associate With?.

Question #2: What actually is the focus of a master file? This topic is easier to determine in proprietary/specific designs, but more difficult to ascertain in a generic design. See the section below Working on Your Focus

Question #3: How can fields that were added to XBRL GL primarily to meet a transactional or other specific need be “backward engineered” to be useful to master files? We have to ask, “What would [field] mean in a generic sense in this particular context?” If we can agree, document it, and then implement it - then we are golden.

This has been done in practice – the [depreciationMortgage] structure has had more meaning added to it by adding more cash management information. As long as there are mutually exclusive uses, users can infer the use or an enumerated field to drive meaning can be provided.

This also is where an intellectual challenge comes into play.

In Table 3, you can see some examples of fields that serve as “defaults” in a master file and then as “actuals” in a transactional file.

Associating [terms] with a customer or a vendor makes sense; what does it mean to associate it with an employee? Can it mean how often the employee is paid (e.g., hourly/weekly, salaried/biweekly)?

Likewise, associating [paymentMethod] (which would store trade values like check, credit card, line of credit, or perhaps “under the table”) is obvious for a customer – what is the meaning for employee (check, direct deposit, under the table, etc.)?

Element	Master File	Transaction File
[amountCurrency]	Default currency	Actual currency
[paymentMethod]	Expected way to pay	Actual payment method used
[shipFrom]	Default warehouse from which to ship	Actual warehouse
[terms]	Default terms	Actual terms

Can default items be at a higher hierarchical level than entryDetail? This might be useful to identify which [account]s can be associated with a particular [sourceJournal]. But this would be difficult to automate.

7 Who Would You Associate With?

When creating master files, all of the information contained within a single [entryDetail] may be considered “associated” together. Some examples of this usage would include:

• What inventory items have been authorized for purchase from a particular vendor? An [entryDetail] section containing a vendor ([identifierReference] with identifierType=”v”) and numerous [measurable] structures can represent that. Could that grouping have other meaning? Perhaps showing a history of purchases rather than an authorization for future purchases?
• What is the default receivables/sales accounts for a customer or payables/expense account for a vendor? A couple of accounts with appropriate [mainAccountType] enumerated values listing the {asset}/{income} or {liability}/{expense} can provide that information when partnered with the associated [identifierReference].
• How about associating accounts for US reporting with accounts for IFRS reporting, taxonomy elements for US reporting with taxonomy elements for IFRS reporting, or accounts with taxonomy elements? Put them all in the same [entryDetail].

Through this association, default items can be associated with the focus, or topic, of a master file. How do you determine what that focus is?

8 Working on Your Focus

Is it important to understand the “focus” of a master file? When you mix together the building blocks, is it important to know which one is dominant and which represent the defaults?

There are times when a particular item needs to be the anchor – or focus – of an association. At other times, the focus is an artificial one, based on one desired view of associated data.

One way to approach this is to consider the “tuple” items that appear in [entryDetail], and which appear only once in the [entryDetail] as opposed to those that might appear more than once.