<

<?xml version="1.0" encoding="UTF-8"?>

Sample detailed listing of vendor invoices file for XBRL GL 2005 with annotations. Version 1.0.50727.1

This file contains data fields considered very important to representing its subject. Annotations have been provided for the "most important" of those fields. XBRL GL has many other fields that could be helpful in expressing the information, but have been omitted because their presence is more circumstantial. This file was created for educational purposes only, does not represent real company data and we welcome suggestions on improvement. Contact xbrlgl@xbrl.org with comments.

The "root" of every XBRL file ("instance document") is xbrl.

<xbrli:xbrl

xmlns:xbrli="http://www.xbrl.org/2003/instance"

xmlns:xbrll="http://www.xbrl.org/2003/linkbase"

xmlns:xlink="http://www.w3.org/1999/xlink"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:gl-cor="http://www.xbrl.org/int/gl/cor/2005-11-07"

xmlns:gl-muc="http://www.xbrl.org/int/gl/muc/2005-11-07"

xmlns:gl-bus="http://www.xbrl.org/int/gl/bus/2005-11-07"

xmlns:gl-plt="http://www.xbrl.org/int/gl/plt/2005-11-07"

xmlns:iso4217=http://www.xbrl.org/2003/iso4217

xmlns:iso639=http://www.xbrl.org/2005/iso639

xsi:schemaLocation="http://www.xbrl.org/int/gl/plt/2005-11-07 ../plt/case-c-b-m-u/gl-plt-2005-11-07.xsd">

<xbrll:schemaRef xlink:type="simple" xlink:arcrole="http://www.w3.org/1999/xlink/properties/linkbase" xlink:href="../plt/case-c-b-m-u/gl-plt-2005-11-07.xsd"/>

The container for XBRL GL, accountingEntries, is not the root of an XBRL GL file - the root, as with all XBRL files, is xbrl. This means that a single XBRL GL file can store one or more virtual XBRL GL files, through one or more accountingEntries structures with data inside. The primary key to understanding an XBRL GL file is the entriesType. A single physical XBRL GL file can have multiple accountingEntries structures to represent both transactions and master files; the differences are signified by the appropriate entriesType enumerated values. This is especially important in a representation of this kind. A file creator can create a single physical file but have information about the vendors in one accountingEntries section and in information about the invoices in another referencing only the vendor number, thereby reducing the duplicated information (vendor name, address, etc.) in the file resulting in smaller file sizes.

<gl-cor:accountingEntries>

Because entriesType is strongly suggested, documentInfo will be required.

<gl-cor:documentInfo>

This field, entriesType, provides the automated guidance on the purpose of the XBRL GL information. This use of XBRL GL, to represent a grouping of vendor invoices, uses the enumerated value "other". Automated consumption would be based on other factors, such as "vendor" for indentifierType and "voucher" for documentType.

<gl-cor:entriesType contextRef="now">other</gl-cor:entriesType>

Like a serial number, this field, uniqueID, provides a place to uniquely identify/track a series of entries. It is likely less relevant for ad-hoc reports, like a list of invoices. XBRL GL provides for later correction through replacement or augmentation of transferred information.

<gl-cor:uniqueID contextRef="now">001</gl-cor:uniqueID>

<gl-cor:language contextRef="now">iso639:en</gl-cor:language>

The date associated with the creation of the data reflected within the associated accountingEntries section. Somewhat like a "printed date" on a paper report.

<gl-cor:creationDate contextRef="now">2005-07-05</gl-cor:creationDate>

<gl-bus:creator contextRef="now">XBRL GL Working Group</gl-bus:creator>

A description related to the batch of information express in the accountingEntries structure. Why was this batch of information put together and published? It would be helpful to put that information in the entriesComment.

<gl-cor:entriesComment contextRef="now">A best practice listing of invoices instance document</gl-cor:entriesComment>

The period of time reflected by the listing of invoies. Future discussion of what date is used - the document date or the accounting relevance data - may be necessary. For a start, all invoices have their document date within that period, and all of the invoices with a document date within that period are included.

<gl-cor:periodCoveredStart contextRef="now">2005-06-01</gl-cor:periodCoveredStart>

<gl-cor:periodCoveredEnd contextRef="now">2005-06-30</gl-cor:periodCoveredEnd>

<gl-bus:sourceApplication contextRef="now">XABRA</gl-bus:sourceApplication>

<gl-muc:defaultCurrency contextRef="now">iso4217:usd</gl-muc:defaultCurrency>

</gl-cor:documentInfo>

Typically, an export from an accounting system does not carry with it information specifically about the company. However, the name of the company would be a very good thing to include with the file, making the entityInformation tuple necessary.

<gl-cor:entityInformation>

The name of the company would be a very good thing to include with the file; this structure and its content are where that would be stored. OrganizationDescription is not currently enumerated.

<gl-bus:organizationIdentifiers>

<gl-bus:organizationIdentifier contextRef="now">ABC Company</gl-bus:organizationIdentifier>

<gl-bus:organizationDescription contextRef="now">Company Name</gl-bus:organizationDescription>

</gl-bus:organizationIdentifiers>

</gl-cor:entityInformation>

Most representations of business detail require entry in entryHeader and entryDetail. Few files can be represented using only documentInfo and entityInformation sections, but it is certainly possible.

<gl-cor:entryHeader>

For audit purposes, the date the invoices were posted to the original system may be helpful. It is important to differentiate between the many dates of XBRL GL. In particular, postedDate (the date information was posted to the computer) should be differentiated from postingDate (accounting significance) or documentDate (the date printed on the form).

<gl-cor:postedDate contextRef="now">2005-07-01</gl-cor:postedDate>

For audit purposes, the person who entered the invoices into the original system may be helpful.

<gl-cor:enteredBy contextRef="now">Otto Wellwood</gl-cor:enteredBy>

For audit purposes, the date the invoices were actually entered into the original system may be helpful.

<gl-cor:enteredDate contextRef="now">2005-07-01</gl-cor:enteredDate>

This is an enumerated entry that ties the source journal from the reporting organization to a fixed list that helps in data interchange. Invoices are likely sourced from the purchase journal, which is enumerated by pj.

<gl-cor:sourceJournalID contextRef="now">pj</gl-cor:sourceJournalID>

Since sourceJournalID is enumerated (you must pick one of the entries already identified within XBRL GL), sourceJournalDescription lets you capture the actual code or term used to describe the source journal by the organization.

<gl-bus:sourceJournalDescription contextRef="now">Vendor purchases journal</gl-bus:sourceJournalDescription>

The entry origin would indicate whether the invoices came in from another automated system or were manually entered.

<gl-bus:entryOrigin contextRef="now">imported entry</gl-bus:entryOrigin>

Documents are defined at the line level. When representing the lines on invoices, an individual document is represented at the header level, so the entryDetail lines can represent the detailed lines of the invoices. The entryNumber can also be used to represent the documentNumber (which would be repeated in the entryDetail).

<gl-cor:entryNumber contextRef="now">50</gl-cor:entryNumber>

The reason for making an entry goes here. If a comment is associated with an invoice, it can go here.

<gl-cor:entryComment contextRef="now">Invoice: #51029 Vendor: #1130</gl-cor:entryComment>

As noted, when illustrating details on a form/document, individual line are represented using entryDetail which must be held together by entryHeaders - one primary amount per entryDetail line. However, you can list different accounts within the same entryDetail line that are associated with that amount. For example, if you capitalize for US GAAP and expense for IFRS, you can have multiple account structures within one entryDetail section. The generic nature of XBRL GL means that much of the information that is common to each line, such as the vendor, or the document attributes, must be repeated on each detail line, or be entered into one of the lines with an understanding that it is common to all.

<gl-cor:entryDetail>

A unique identifier for each entry detail line within an entry header, this should at the least be a counter, representing the line relative to others on the invoice form.

<gl-cor:lineNumber contextRef="now">1</gl-cor:lineNumber>

Accounts may or may not be associated with entry lines; they are omitted here for the sake of this instance.

Amounts in systems may be a signed number, a separate sign, and/or a separate debit/credit indicator. While the use of the sign indicator or the separate debit/credit indicator is more likely with journal entries, it is unlikely with invoices.

Amounts in XBRL GL when representing invoices and details can be tricky. In the simplest sense, the amount at the line level can simply represent the extended amount of the line (the cost per is within the measurable structure). Sales tax, freight and other non-line items can be represented with a measurable item representing those items, or with a GL account representing those items. Should the user choose to represent the "total" amount, the individual lines or the total can be notated with the amountMemo to minimize the risk of amounts being double-counted if the invoices will later be turned into accounting entries.

<gl-cor:amount contextRef="now" decimals="2" unitRef="usd">500</gl-cor:amount>

This date is the accounting significance date, not the date that entries were actually entered or posted to the system, nor the date on the document proper.

<gl-cor:postingDate contextRef="now">2005-06-30</gl-cor:postingDate>

<gl-bus:amountMemo contextRef="now">false</gl-bus:amountMemo>

Invoices from vendors require vendor information. This is held in the identifier structure. As systems may or may not store individual components of the structure all of the time - they may have the vendor's number but not the name or vice versa, the only "mandatory" field here is the identifierType to state without question that this is a vendor. It may be confusing that the vendor must be identified for each line of an invoice. Why isn't the vendor at the Header level? The answer - the generic nature of XBRL GL means it must accommodate both detail and summary style of entry. Rather than duplicate the identifier structure at both header and detail level, it is at the detail level.

<gl-cor:identifierReference>

<gl-cor:identifierCode contextRef="now">1130</gl-cor:identifierCode>

<gl-cor:identifierDescription contextRef="now">Rettaler Property Ltd</gl-cor:identifierDescription>

<gl-cor:identifierType contextRef="now">V</gl-cor:identifierType>

</gl-cor:identifierReference>

As noted previously, the identifierType of vendor and the documentType of voucher provide automated guidance that this batch of information has to do with invoices from vendors. Vouchers are invoices received from vendors.

<gl-cor:documentType contextRef="now">voucher</gl-cor:documentType>

Document number in this representation is the number of the invoice.

<gl-cor:documentNumber contextRef="now">51029</gl-cor:documentNumber>

Document reference is a textual description of the document. Some systems allow for manual entry of this information; some have a default format; some apply an internal counter/unique serial number.

<gl-cor:documentReference contextRef="now">Voucher#: 100900 </gl-cor:documentReference>

The document date is the date printed on the document proper. There are a number of other fields for other dates associated with the handling of the document.

<gl-cor:documentDate contextRef="now">2005-06-15</gl-cor:documentDate>

One example of an alternative date associated with a document is the date it was received by the company. Having this date available is helpful when the date received differs significantly from the date on the document itself and negotiations about terms and discounts are raised.

<gl-bus:documentReceivedDate contextRef="now">2005-06-14</gl-bus:documentReceivedDate>

Few systems track the place where the "physical" invoice is filed - whether paper or electronic - but as part of the audit trail, the documentLocation allows representation so one can find their way to the physical location (Bin 3, bottom drawer) or virtual location (c:\docMgmt\4$5%68.doc)

<gl-bus:documentLocation contextRef="now">Fred's desk drawer.</gl-bus:documentLocation>

In the case of detail invoice listings, the detailComment is not significantly different than the documentReference.

<gl-cor:detailComment contextRef="now">Vendor#: 1130 Document#: 51029 Date: 6/15/05</gl-cor:detailComment>

Maturity date is the due date of the invoice.

<gl-cor:maturityDate contextRef="now">2005-07-15</gl-cor:maturityDate>

Terms is currently a free form expression of the terms of a document. The XBRL GL WG has had discussions of a structure or adoption of existing standards that enumerate this information.

<gl-cor:terms contextRef="now">2% 10 Net 30</gl-cor:terms>

The measurable structure is the primary tool for collecting data at the line level. It represents inventory, services, supplies, processes, KPIs, fixed assets and other things that are matched to a code (as opposed to an account) and collects numeric (measurableQuantity) and non-numeric information (measurableQualifier). A typical invoice would have one measurable per entryDetail line. The amount fields in the entryDetail would be the extension of measurableQuantity times MeasurableCostPerUnit. There are a number of elements within the measurable structure - at least ONE of measurableCode or measurableDescription is necessary; anything else is optional, used as needed.

<gl-bus:measurable>

<gl-bus:measurableCode contextRef="now">Widget1</gl-bus:measurableCode>

<gl-bus:measurableDescription contextRef="now">Red Widger</gl-bus:measurableDescription>

<gl-bus:measurableQuantity contextRef="now" decimals="2" unitRef="NotUsed">100</gl-bus:measurableQuantity>

<gl-bus:measurableUnitOfMeasure contextRef="now">Each</gl-bus:measurableUnitOfMeasure>

<gl-bus:measurableCostPerUnit contextRef="now" decimals="2" unitRef="usd">5</gl-bus:measurableCostPerUnit>

</gl-bus:measurable>

</gl-cor:entryDetail>

As noted above, the additional entryDetail lines will likely need to duplicate the typical header information necessary to support that which is truly at the line level - the amount, the line number, the measurable. With agreement, that information could be provided in one entryDetail line (e.g., the first line) and then other lines could inherit that information if applications were designed to do so.

<gl-cor:entryDetail>

<gl-cor:lineNumber contextRef="now">2</gl-cor:lineNumber>

<gl-cor:amount contextRef="now" decimals="2" unitRef="usd">300</gl-cor:amount>