Master File versus Transaction: Some Ramifications - a.k.a. Defining Defaults without Defiance 1.0

Working Group Note 17 February 2009

Copyright ©2009 XBRL International Inc., All Rights Reserved.

This version:
Eric E. Cohen, PricewaterhouseCoopers LLP <>
Gianluca Garbellotto, Iphix <>


Circulation of this Working Group Note is unrestricted. Other documents may supersede this document. Recipients are invited to submit comments to, and to submit notification of any relevant patent rights of which they are aware and provide supporting documentation.

Table of Contents

1 Conventions
2 Language independence
3 Introduction
4 Building Blocks of XBRL GL
5 Special Uses of XBRL GL
6 Finding Default With Others (See: “beam in your own eye”) [ 7 ]
7 Who Would You Associate With?
8 Working on Your Focus
8.1 One to one
8.2 One to many
8.3 Many to many
8.4 Measurable virtual enumerations


A Intellectual property status (non-normative)
B Document history (non-normative)
C Errata corrections in this document

End notes


1 Special uses and their distinguishing characteristics of XBRL GL
2 Use of entriesType
3 Table 3: Examples of individual default/operational items
4 Table 4: Measurables – not enumerated, but could agree on “virtual” enumerations

1 Conventions

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:

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:

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.

Table 1: Special uses and their distinguishing characteristics of XBRL GL
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.

Table 2: Use of entriesType
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.)?

Table 3: Table 3: Examples of individual default/operational items
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:

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.

8.1 One to one

In the simplest master file entry, nothing appears more than once. If that is the case, which aspect is the focus, and which are therefore the defaults associated with that focus item?

8.2 One to many

How do you best represent the items that a vendor can provide or alternatively those you wish to indicate are authorized for purchased from the vendor?

  1. A single inventory item (represented by a [measurable] structure) may be associated with many vendors (represented by the [identifierReference] structure). “You can buy this item from these vendors.”
  2. The same concept can be communicated by expressing each vendor individually with all of the items. “You can buy these items from this vendor.”

This tells us two things: that the focus is not necessarily the “single” item, and that there may be a relatively simple transformation between two views with no loss of information.

8.3 Many to many

For example, what might it mean if there are two [account] structures and two [identifierReference] structures within a single [entryDetail]? Is this a poor practices’ method of associating multiple customers or vendors with the appropriate balance sheet/income statement accounts (as illustrated above)? It adds ambiguity.

8.4 Measurable virtual enumerations

Most of our master file groupings are enumerated to remove any question about their content. The [account] structure has enumerated values for [accountType]. The [identifierReference] structure has enumerated values for [identifierType]. However, the concern was that we wouldn’t be able to develop a comprehensive enough list of things that can be measured to develop an appropriate list of enumerations.

However, we want to encourage consistent usage. In the following table, such a list is provided.

Table 4: Table 4: Measurables – not enumerated, but could agree on “virtual” enumerations
Possible enumerated entries Description
BP Business Processes
FA Fixed Assets
IN Inventory
KPI Performance Metrics
NT Intangibles
SP Supplies
SV Services
OT Other

Appendix A 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 regarding 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 ( ).

Appendix B Document history (non-normative)

29 September 2008Gianluca Garbellotto

Initial document.

17 February 2009Gianluca Garbellotto

Editorial review.

Appendix C Errata corrections in this document

This appendix contains a list of the errata that have been incorporated into this document. This represents all those errata corrections that have been approved by the XBRL International XBRL GL Working Group up to and including 17 February 2009 . Hyperlinks to relevant e-mail threads may be followed only by those who have access to the relevant mailing lists. Access to internal XBRL mailing lists is restricted to members of XBRL International Inc.

No errata have been incorporated into this document.

End Notes

To date, we have not chosen to enumerate the [measurableCode]. We have suggested in the past entries such as "(I) for inventory, (F) for fixed assets, (N) for intangibles, (KPI) for performance metrics, (S) for services.” See also the suggested listing in Table 4.
But trying to avoid derived/calculated fields
In my separate document, One Man’s entryDetail is Another Man’s entryHeader, I described how different uses of XBRL GL require careful consideration of the XBRL GL section hierarchy. In my separate document, Cross-referencing from XBRL FR to XBRL GL, I introduced a notation to describe the different levels of hierarchies that might be considered.
A horrible pun based on Matthew 7:1-5