XBRL GL - Working Group
Note - XBRL Global Ledger Frequently Asked Questions (FAQ)
Working Group Note dated 2007-08-01
Copyright
© XBRL International, Inc. 2007. All Rights Reserved.
XBRL-GL-WGN-FAQ-2007-08-01.htm
is non-normative.
Gianluca
Garbellotto |
PricewaterhouseCoopers Iphix |
Contributors
Hugh Wallis Dan Roberts Greg
Zegarowski Prasanna
Perera |
XBRL
International Grant Thornton Financial Leadership Corporation Dynaxys |
Abstract
A non-authoritative and non-exhaustive list of questions
with even less-exhaustive answers about XBRLs Global Ledger Framework (XBRL
GL) developed by the XBRL GL Working Group.
This list of frequently asked questions is a compilation of questions we have been asked, or ask ourselves. The answers come from experience where possible; in some cases, they are simply educated guesses. The document is meant to be a living document. Please feel free to submit questions to xbrlgl@xbrl.org.
Status
Circulation of this Working Group Note is unrestricted. Recipients are invited to submit comments to the author or to the XBRL GL Working Group xbrlgl@xbrl.org, and to submit notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Table of Contents
XBRL GL - Working Group Note - XBRL Global Ledger
Frequently Asked Questions (FAQ)............ 1
Working Group Note
dated 2007-08-01.................................................................................. 1
Copyright © XBRL
International, Inc. 2007. All Rights Reserved........................................... 1
XBRL GL Basics........................................................................................................................ 4
1. What is XBRL GL?................................................................................................. 4
2. Why is XBRL GL needed? Arent there other standards
out there?...................... 4
3. Why do you call it the Global Ledger Framework?............................................ 5
4. Why is it called GL if it isnt General Ledger?.................................................. 5
5. What can XBRL GL be used for?........................................................................... 5
6. Can/should XBRL GL be used to represent transactions?.................................... 5
7. What is the status of XBRL GL? Is it done?.......................................................... 6
8. Who is using XBRL GL?........................................................................................ 6
Technical issues...................................................................................................................... 6
9. What software supports XBRL GL?....................................................................... 6
10. Doesnt XBRL GL create really big files?............................................................... 6
11. What is the difference between XBRL GL and normal
XBRL?............................. 7
12. Why is context not relevant in XBRL GL?............................................................. 7
13. What background do I need to have to understand XBRL
GL?............................. 7
14. Where can I learn about XBRL GL?....................................................................... 7
15. What competitors does XBRL GL have?............................................................... 9
16. Do I require an XBRL compatible data storage system?...................................... 9
17. Can I implement a single XBRL environment, for
internal and external reporting? 9
18. Can I use Formulas in XBRL GL?.......................................................................... 9
Implementation and
Use........................................................................................................ 9
19. How hard is it to customize XBRL GL?.................................................................. 9
20. How much does XBRL GL cost?........................................................................... 9
21. How much does an XBRL GL implementation cost?.......................................... 10
22. What are the challenges of implementing XBRL GL?......................................... 10
23. Does the flexibility of XBRL GL make it difficult to
implement it?....................... 10
24. Is it necessary to change existing systems to
implement XBRL GL?................ 10
25. Who can benefit from XBRL GL? Is it just for big
corporations?......................... 10
26. Do I need to start with XBRL FR and then move on to
XBRL GL?....................... 10
27. I am a company. How do I start implementing XBRL GL?.................................. 11
28. I am a software developer. How do I add XBRL GL to my
software?.................. 11
29. I am a regulator, or an analyst, or an investor. Why
should I care about XBRL GL?.. 11
30. I am an accountant/auditor. Is XBRL GL relevant to me?
Where should I start? 11
31. Does developing XBRL GL take away resources from
developing XBRL more broadly? 11
32. What is the XBRL GL Philosophy?....................................................................... 11
33. What are palettes? Why would I use one over another?................................... 11
Internationalization
issues.................................................................................................... 12
34. Some of our subsidiaries operate in local languages.
How can XBRL GL facilitate reporting in multiple languages?................................................................................................................. 12
35. Our subsidiaries operate in different countries with
different GAAP/accounting rules. Can XBRL GL help us? 12
36. We are considering using International Financial
Reporting Standards (IFRS) for our consolidated reports. Can XBRL GL be helpful
in migrating to that standard?...................................................... 12
37. Can XBRL GL help with US GAAP/IFRS convergence?......................................... 12
38. Can XBRL GL Co-habitat with XBRL FR?............................................................ 12
Other XBRL GL
Applications................................................................................................... 13
39. Is XBRL GL primarily about accounting information
leading to the financial statement? Can XBRL GL help with operational
reporting, benchmarking, balanced scorecard, etc.?............................... 13
40. Can XBRL GL add efficiency to the data collection
process for sustainability (corporate citizenship) reporting?.................................................................................................................. 13
41. How can XBRL GL help me identify potential fraud?........................................... 13
XBRL GL Philosophy*
(as of January 2006)............................................................................ 14
A. Intellectual Property Status
(non-normative).................................................................... 17
B. Document History (non-normative).................................................................................. 18
XBRL GL, XBRLs Global Ledger Framework, is the use of XBRL taxonomies to model the information found in ERP systems. XBRL GL is a single, global, holistic way to support the collection of business information from business event through end reporting. It can represent the information found in a typical general ledger system globally; it can represent the information that flows in from sub-ledgers, such as Accounts Receivable, Accounts Payable, Inventory, Payroll, Fixed Assets and Order Entry; it can represent the setup files, master files, transaction files and status files you would find in any of those modules. It is modular, today having recommended modules to represent most of the information found in back-room ERP systems; additional modules can be created to meet specific jurisdictional and industry requirements, which should be added in light of the XBRL GL Philosophy.
XBRL GL provides a seamless interface to transactional standards, provides a common model for moving data through an ERP system, and links unambiguously to end reporting schemas and XBRL taxonomies.
We have likened XBRL GL to the human genome project; as we continue to map and find patterns in ERP systems, XBRL GL will grow as necessary to meet the representational needs. This will likely come in the form of new modules rather than affecting the existing modules or the framework.
There are numerous solutions, but none meet but a fraction of the business requirements identified for XBRL GL.
Global many works are region-specific; the needs of an indirect taxation country are different than the needs of a direct taxation country, for example.
Holistic many works are purpose-specific; just for sharing information with an accountant or a tax auditor.
Generic many works are industry specific
Openly developed some of the best known current works were developed by one organization without any public vetting
Extensible some of the best known current works are simple XML schema approaches with no agreement on specifications and extensibility. They cannot be extended for specific internal uses; they cannot be expanded without making the standard use non-standard
XBRL GL was designed with global feedback and is unique in that respect. Other efforts in this space are either regional or purpose-focused. It is a framework as it has a core module that sets up a structure to be expanded upon; all of the building blocks are assembled based on this framework.
XBRL GL did indeed begin as a representation of the
information to flow in to and out from a US-centric general ledger system.
Theoretically, a sophisticated ERP systems general journal history file can
hold almost all of the information you would expect to see in sub-ledgers. As
we began to collaborate with others around the world, we found that one country
or regions general ledger held different information, in different levels of
detail, than others. Continental European general ledger systems needed to
store detailed information that might be found in separate Accounts Receivable
and Accounts Payable sub-ledger systems in the
To quote an earlier document on the idea behind XBRL GL:
The idea behind XBRL GL
is relatively simple; if you model the
journal history file of a sophisticated accounting system, you can reuse the
fields to represent all of the master and transactional files that were called
upon to flow into history.
Accounting
systems are basically databases that summarize business transactions and allow
for summarizing that underlying data in a number of ways. The bulk of the data
flowing into the database is from standardized business documents. By
standardizing the most important pieces of information from these standardized
documents, expanding coverage to other pieces of information maintained in the
accounting system, and providing a tool for extensibility for specific industry
and jurisdictional needs, XBRL GL provides a framework for representing the
underlying database from which to draw most financial and business reports.
XBRL GL alone: for data migration, data archival, data integration, consolidation, as a payload for Web-services-oriented architectures, for auditing and compliance, for tax reconciliations. Together with XBRL for financial reporting: as a bridge between transactions and end reporting, for reconciliation between different end reporting represented with an XBRL FR taxonomy or other XML schema. And more
XBRL GL is
not a transactional standard, and it does not aim at replacing existing
purpose-specific transactional standards. However, it is capable to represent
all those standards, and it can represent transactions and all the related
events that are triggered in different moments of their lifecycle as they flow
from their first generation to their final representation in some kind of end
report.
The CORE (gl-cor) module and numerous extension modules:
Advanced US/UK (gl-usk)
Business facts (gl-bus)
Multicurrency (gl-muc)
Tax Audit File (gl-taf)
are Recommendations from XBRL International. These are done and ready to use.
Additional extension modules are in design to expand upon XBRL GLs presentational power. Currently available as a public working draft is the Summary Reporting Contextual Data (SRCD) module, for enhanced linkages between XBRL GL and XBRL (or non-XBRL schemas) for end reporting.
The current modules are done. Future updates to these modules will be limited and the needs of current implementers taken into account. But
The list of organizations that have publicly discussed or allowed discussion of their use of XBRL GL includes Wacoal (http://www.wacoal.co.jp) and the U.S. Department of Housing and Urban Development (HUD - http://www.hud.gov/). Hitachi Systems and Services and Fujitsu have both discussed additional customers with whom they have done XBRL GL projects. PricewaterhouseCoopers has discussed its use of XBRL GL to improve its collection and internal sharing of client data. Because XBRL GL is more internally focused than traditional XBRL for external reporting, companies adopting XBRL GL have less reason to share the fact that they are using XBRL GL; we have had reports of other companies adopting XBRL GL for some uses in their organizations that have not been willing to be public about this usage.
A. Because XBRL GL is indeed XBRL, any fully compliant XBRL taxonomy or instance tools can work with XBRL GLs taxonomies and instances. However, the nature of the data shared with XBRL GL is different than that of financial reporting, and spreadsheets to manually tag FR data isnt suitable for row upon row of extracts from business operational and accounting systems.
DynAccSyss XABRA has been designed for working with XBRL GL data; Rivet Softwares Crossfire claims XBRL GL capabilities as well.
Because XBRL GL acts like traditional XML Schema, products designed for working with XML and XML Schema (Microsoft .Net 2.0, Altova MapForce, Datawatchs VortexML) but not specialized for XBRL can also be used with XBRL GL.
XML is verbose, and representing a CSV or fixed length ASCII file using XBRL instance documents can be many times the initial size. There will be cases where XBRL GL must be kept in native XBRL instances, for on the line processing by routers, for example. As bandwidth, storage and processing speed all increases and becomes less expensive, these issues will fade; some of those routers can also decompress/compress and compressed XBRL data is relatively small. XBRL GLs semantics can also be used to describe more space efficient file formats like CSV or ASCII for great benefit as well.
Most of the XBRL taxonomies to date have been about summarized, aggregated data, where agreement on a business concept found on a report or form is necessary. Each concept is specific to an area of business reporting, and governed by some authoritative rule. XBRL GL is one step lower on the information chain; a representation of the data fields found in a typical ERP system, so that operational data, statistical data, accounting data, and other information that supports and represents business trade documents, the master files that support those documents and various summaries can be represented. XBRL GL is independent of accounts and end-reporting concepts, but can reference and tie them together for cross-GAAP and cross-functional reporting.
As per the XBRL 2.1 Specification each XBRL item must be
linked to a context element that contains information about the entity being
described, the reporting period and the reporting scenario, all of which are
necessary for understanding a business fact captured as an XBRL item. However,
in XBRL GL most of the contextual information that is associated with an XBRL
item is contained in other items. Due to the nature of the data and documents
that are represented with XBRL GL it is not enough, for instance, to provide
only one date or one period of time as context. The date in which an entry or a
document was created, or entered in a system, or posted, its accounting
relevance date, its maturity date etc. can all be relevant. To provide a single date in the context would involve
selecting one of these dates as "THE" date. This could lead to
endless debate as to which is the most important of these dates
since "importance" will vary depending on the purpose for which
the data is being used. Therefore clearly it is not possible to
define a single "most important" date that will satisfy all users. This is why
the link to the context becomes redundant, and is provided only to comply with the
XBRL 2.1 Specification.
XBRL GL is primarily two things:
· A semantic agreement on how to represent business and accounting documents, entries, sub-ledgers and ledgers in a standard, consistent way no matter in which application they were originated or reside in;
· A technical agreement on how to represent the semantics above using XBRL.
The semantics of XBRL GL are gained through an understanding of the business domain and the many educational tools developed by the XBRL GL Working Group. The technical agreement is based on XBRL taxonomies, which leverage XML Schema and XLink to capture the data elements, attributes/definitions and interrelationships, so a basic understanding of these technologies is necessary to fully understand XBRL GL. However, an understanding of XML Schema and restrictions such as enumerations should be sufficient for an initial approach to the technology of XBRL GL.
On the web,
the official home of XBRL GL is the XBRL web site, and the starting page is
http://www.xbrl.org/GLTaxonomy - the files are found at
http://www.xbrl.org/GLFiles as the official home. The Working Group attempts to
provide a monthly webcast you can find archived webcasts at Gianluca Garbellottos
web site (http://gl.iphix.net) which also has annotated instances, examples of
different uses of XBRL GL with commentary on the use of XBRL GL. The public
facing mailing list can be found at
http://groups.yahoo.com/group/xbrl-gl-public and emails can also be sent to
xbrlgl@xbrl.org. Members have additional resources, including internal facing
mailings lists and file sharing areas. We conduct XBRL GL training whenever
possible at XBRL International and XBRL
There is no other work that is global, holistic and XML-based that represents the information that XBRL GL can. XBRL GL is not optimized for one use (e.g., tax audit) over another (e.g., internal data integration). So while there are EDI standards for some of the data interchange purposes of internal reporting, and there are files for pulling data from accounting systems for tax audit, there is no true competition for XBRL GL. There is no other standard that can track book reporting versus tax reporting simultaneously and track the permanent and timing differences. There are various standards competing for the role of vital core component, being standards for names, addresses, inventory items and other building blocks, XBRL GL has a generic set for binding them all together.
While XBRL-compatible data storage systems will facilitate the collection and reuse of XBRL data broadly (XBRL GL and other XBRL GL data), implementations of XBRL GL may include storage of the XBRL GL instances in their native form or importing/exporting XBRL GL from traditional relational databases.
With a long-stated goal that XBRL is being developed so a piece of business information, once entered into any computer, anywhere in the Business Reporting Supply Chain, the future will hold a single XBRL environment. In addition, as information becomes increasingly standardized and reusable, the internal reporting data of today will become the external reporting of tomorrow; in numerous circumstances today, the delineation between internal and external is already blurred.
The XBRL community is working to bring the Formula Specification from its current Public Working Draft status (see http://www.xbrl.org/SpecPWDs/) to RECOMMENDED status. The Formula Specification is not specific to any kind of XBRL. Therefore, it will have relevance to XBRL GL. Other specifications regarding formulas and business rules, such as Schematron (http://www.schematron.com) can also be relevant. It is important to recognize that the concepts in XBRL GL represent the data fields common to ERP systems and not distinct business concepts, and the kind of interrelationships common to end reporting (line 23 of the form should be greater than line 57, unless line 14 is -0-) do not generally apply to XBRL GL. A better fitting analogy for the kind of formulas that are relevant for XBRL GL is an SQL query on a relational database.
There is a document published with the XBRL GL files (http://www.xbrl.org/GLFiles) with instructions on how to customize XBRL GL; the document is the Global Ledger Framework Taxonomy Technical Architecture (http://www.xbrl.org/int/gl/2007-04-17/GLTFTA-REC-2007-04-17.rtf). However, changes to XBRL GL would mean that applications developed around the RECOMMENDED XBRL GL files would not necessarily be able to recognize these files. In addition, our experience is that many attempts to customize XBRL GL come from a lack of familiarity with XBRL GL rather than a lack of representational power. We would therefore encourage implementers to contact us (with whatever level of sensitivity necessary expressed) to both make sure that customization is indeed necessary and that feedback to the XBRL GL group in true needs for expansion is provided.
XBRL GL is a royalty-free, freely-licensed semantic model expressed in XBRL for which there is no charge. The costs would be limited to any additional software, training/consulting, or other systems costs necessary to implement it.
It is impossible to answer this question in general terms, since XBRL GL can be used for very different purposes, and this means that its implementations can be very different in nature, scope etc. Having said that, one of the most common XBRL GL implementations is data integration, and available comparative metrics show that the cost is a fraction of the cost of implementation of a single ERP system, with a significantly quicker time to completion. Compared to an implementation based on middleware, the cost is probably comparable, but the benefits in the medium/long term are much greater.
To optimize the use of XBRL GL, users must invest in understanding two things: the XBRL GL model and XML Schema/XBRL. XBRL GL provides a mature model for representing information through an ERP system. As such, it can facilitate todays integration by eliminating that design phase, but does require the implementer to understand the XBRL GL semantic model. XBRL GL works with standard XML Schema tooling, but provides additional information in the linkbases, so use of this optional information requires additional understanding of the XBRL Specification as well.
A flexible structure provides a much greater representational power compared to a more rigid, pre-determined structure, but it requires a different mindset in order to use it consistently. Best practice guidance on how to represent different types of data, transactions and documents is available from the XBRL GL Working Group at GaLaPaGoS Global Ledger Practices Guide for Study (http://gl.iphix.net), and the WG (xbrlgl@xbrl.org) is available to provide guidance on possible best practice approaches to represent data/documents that have not been published yet.
An XBRL GL based implementation does not require changes to existing software applications, since mapping capabilities to and from XBRL GL can be added externally plugging into the existing data repositories. Of course, modifying existing applications to build in native XBRL GL capabilities can provide superior outcomes in terms of integration and performances. Also, looking at the information system as a whole there is a change in terms of interjecting XBRL GL between two points where it was not interjected before. In general though it is safe to say that an XBRL GL based implementation preserves and optimizes the existing IT investments.
XBRL GL was initially developed with small businesses in mind and heart; moving data from external payroll services and Web merchant sites to accounting systems, and from the small business clients accounting system to their accountant, with tax preparation in mind. However, it has emerged as something useful for businesses of all sizes, as well as not-for-profit entities, governments, and anyone else that keeps business books and records.
We have heard it expressed that the logical progression is for companies to start with XBRL for external reporting, and then move to XBRL GL. Indeed, many companies will find they need to start with FR as a low impact/sneaky way to get XBRL into their organizations (no need to touch any systems), or as they react to a regulatory requirement or voluntary filing program. They can then move to XBRL GL as they progress on their learning curve on XBRL and its complete value proposition.
However, many companies can benefit from XBRL GL today without an immediate need to report with XBRL FR. If you are doing an integration project today, you need to represent your data against a model; rather than designing one from scratch or using a particular software products file format, you can use XBRL GL. Following this path of adoption the possibility of using XBRL for financial reporting comes as an additional plus.
[To be developed]
Find an integration/data archival need. Use 80/20 rule. Set up a conference room prototype.
[To be developed]
See separate document.
[To be developed]
Those who dont see internal data should still care about internal data. XBRL GL can facilitate the improvement of the quality of data being reported upon, whereas external reporting agreements primarily improve the data transfer of todays quality of data. In addition, todays internal data may be tomorrows external data.
[To be developed]
XBRL GL can be the lifeblood of the audit, one consistent, standardized and holistic format for audit-related data from first entry through to end reporting. XBRL GL has the potential to streamline and improve the communication between client and accountant, integrate audit workpaper/tax prep/write up work, and prove to be the standardized tool for proving that underlying data agrees with or is reconcilable with management representations.
[To be developed]
With an initial vision of the integration of the Business Reporting Supply Chain, it is intuitive that the development of the Global Ledger Framework is a necessary part of the development of XBRL as a whole. However, XBRL GL is different than end reporting, and in particular financial reporting. As such, the demands of XBRL GL are sometimes in conflict with optimizing XBRL around financial reporting. In addition, the human resources of XBRL International Inc. and time at XBRL conferences are limited, and some people whose priority is external facing reporting may feel that attention to XBRL GL takes away resources from the vitally important external reporting world. On the other hand, external reporting is only the tip of the iceberg of the business reporting supply chain, and as a consequence of the space of XBRL broadly considered. Huge benefits especially for companies who have been having difficulty seeing the value of XBRL external reporting for themselves are available through the development and adoption of XBRL GL, alone and in conjunction with XBRL FR.
The XBRL GL Philosophy is a series of goals and practices for the ongoing development of XBRL GL. When we consider expanding on XBRL GL, it provides a conceptual blueprint, a ruler against which we can lay up those additions. It is meant to be a living document, but changes should be seriously thought through.
See the appendix to this document for the philosophy statement.
Palettes are different ways to combine the modules of XBRL. The modular approach was adopted as some prospective regional users of XBRL GL felt that some of the data fields now found in the USK module would compromise acceptance of XBRL GL by their governments. The modular approach would allow those users to bring together the modules not including USK. Some users may wish to limit the available data fields used in their business reporting supply chain. A consumer of XBRL GL files would likely wish to understand the most comprehensive palette possible.
XBRL GL is designed so that operational and accounting data can be represented at the subsidiary (local) level of an organization. This means transactions occurring in local languages other than English can be represented in the metadata of XBRL GL and then presented to users in a language more familiar to them. Translations of the English labels and documentation in German, Polish, Portuguese, Canadian French, Japanese and Dutch, already available for previous versions of XBRL GL, are being updated to the Recommended release, and efforts are under way to complete the Spanish and Italian labels.
Country-specific accounting rules are essentially driven by specific transactions or journal entries being reported in different ways. Since XBRL GL allows for tagging single transactions or journal entry in multiple ways, it facilitates the rollup of detail information under different reporting standards.
Differences between IFRS and other standards such as US GAAP are driven in part by specific transactions or journal entries being reported in different ways. Since XBRL GL allows for tagging single transactions or journal entry in multiple ways, including multi-GAAP recording, it facilitates the rollup of detail information under different reporting standards, as well as providing the means to produce necessary reconciliations (see FAQ # 38 below).
XBRL GL can foster convergence of US GAAP and IFRS for
several reasons. The use of XBRL GL increases reporting transparency, provides
for greater participation and collaboration in standard setting, and provides more
exposure to business information, its underlying detail, and related standards.
Because it can track multi-GAAP transactions and can accumulate information as
it moves through a system, subsidiaries can continue to report using one
standard while the other reporting standard can be added in parallel later in
the consolidation process. Collectively, all of these benefits of XBRL GL
facilitate the convergence of accounting standards. More information about
using XBRL broadly for
XBRL GL is 100% XBRL and has been developed to seamlessly
integrate with other uses of XBRL. Also, special attention is being placed in
the link between XBRL GL and XBRL FR: this link is already built in the
RECOMMENDED modules, and the new Summary Reporting Contextual Data (SRCD)
module, currently in Public Working Draft status, is designed to make that link
even more evident and immediately usable, and to provide advanced linking
capabilities that include, among others, linking to dimensional taxonomies. The
GL/FR link allows to represent in a standardized, consistent and
application-independent way the link between detail data, from original
transaction up to the trial balance level, to multiple end reporting taxonomies
(
XBRL GL certainly facilitates financial statement preparation by representing accounting information at the detail or transactional level. This same representational activity allows a company to more easily produce internal operational reports, benchmarking metrics and scorecards. XBRL GL is a tool for both internal and external reporting.
XBRL taxonomies are currently being developed for reporting under sustainability standards such as the Global Reporting Initiative (GRI). XBRL GL can be of immediate benefit to companies who want to identify and compile data pertaining to environmental and other social-reporting metrics. By representing such data at the detail level, XBRL GL facilitates sustainability reporting at both local and global levels.
XBRL GL provides a single, generic, holistic way to represent business reporting detail, from first entry through end reporting. As such, XBRL GL can facilitate the use of existing fraud and forensics software and improve todays practices. XBRL GL does not make anything happen on its own; it only provides more transparency to business data, facilitates more information being seen more often.
Where the accounting system stores, we store. Where it is silent, we are silent.
XBRL GL represent the details found in a back-end accounting and operational systems that flow to the General Ledger (in the international sense of the word) and off to reporting. It provides the drill down details from XBRL Reporting.
XBRL GL represents the information found in the General Ledger of systems around the world; however, the General Ledger holds different types of information in different areas, and so holds much more than the GL in any one area.
Because XBRL GL is a representation of what is actually in the business system, some fields common to data exchange have not been designed into the taxonomy (to date).
Traditionally, calculated fields (hash totals, agings) were not included, as their definitions are situational, not always clear or agreed upon. See the section 11. Exceptions to the rule that prove the rule? for more information.
If it is something that appears in reports as calculated fields or only after data processing, it probably should not be represented in XBRL GL. It is here that XBRL View Reporting and XBRL GL can work in concert to meet the needs of the market.
We are trying to serve two masters, that of an audit (what is actually stored in the system) and that of interchange (creating files that can be more easily understood by a consuming application even if some nuance of meaning is lost).
·
Pulling
from systems a true representation of that systems content in order to serve
as an audit tool
·
Allowing
the export from a system of information in a format that is normalized or
regularized so another system can easily understand and import it.
This philosophy means we often have two fields to represent something - one for freeform data (what is in the system) and a matching one for enumerated data (a fixed set of choices so the incoming system knows what to expect).
That being said, some systems use the GL system and the structure of the <account> to represent not only traditional GL accounts, but also customers, vendors and other concepts, whilst other systems use a subledger tool, represented in XBRL GL by <identifierReference>.
For that reason, we often have two fields for vital information where one is enumerated (you must pick from one of the options given) and where the other is free-form (enter whatever is most meaningful for you).
For example, sourceJournal is enumerated, to facilitate the audit process, while sourceJournalDescription is free-form. Because of the enumeration, audit tools know what was supposedly part of Cash Receipts and help make assessments (such as Accumulated Amortization should NOT be affected by Cash Receipts.)
XBRL GL has been designed to allow modular representations of information (master files separate from transaction files) for more compact files that are point in time captures, while allowing monolithic representation (all of the information at the detail level) to be able to track any changes or variances of the master files at the point of transactions, although the files will be much bigger.
Based on the model of a sophisticated accounting systems General Ledger journal history file, into which all of the detail from all of the sub-ledgers may flow, XBRL GL is a generic representation of the documents, parties, resources, events and other detail that start at the transaction level and flow in full detail or summary to the Ledger.
Use generic, reusable structures within a framework as reusable building blocks. Grow carefully and selectively.
Use enumerations with the generic building blocks and compromise where possible rather than creating proprietary building blocks. Use enumerations to differentiate the usage of similar structures for different items. See the section 10. Use of enumerations for data transfer and free-form fields for audit for more information.
Key items may need their own representation as launching points for further development. Some countries report jobs as part of the account structure; however, job costing systems are also specialized systems separate from the account structure. The account structure can represent information also represented by other structures (identifier, measurable, jobInfo). However, this approach should only be used after careful consideration.
Document needs to be at the most detailed level and an entryDetail line can only be associated with more than one document by repetition of the entryDetail line with a different document.
An entryDetail line can only be associated with one primary amount. Needing to disclose more than one primary amount (not including multi-currency issues) will require more than one entryDetail line.
XBRL GL is not meant to be used as the actual payload to conduct a transaction, but is meant to be a generic representation of transactions.
XBRL GL is not being designed so companies can send invoices, purchase orders, or other trade documents to each other. XBRL GL is designed for seamless overlap with transactional standards, but should NOT be used for transactions themselves.
As a bridge between transactional standards and XBRL Reporting, XBRL GL will look and feel as much like transactional XML as possible.
In all but the narrowest case, where enumerations are provided, an other value should be provided as one of the enumerated values.
In general, wherever there is an enumeration, there should be a freeform field as well.
1. UK English or the language specific to a jurisdiction if in a jurisdictional taxonomy
2. Using lower case (?) when using UK English terms
3. Using recognizable whole words (?), or commonly understood abbreviations, not codes (GUID)
4. However, it should be remembered that enumerated values ARE just codes; it should not be required to provide different enumerations in each language. The human readable definition of the enumerations can be described in the definitions/annotation in different languages (using lang=).
Speaking of which, the meaning of enumerations should be well specified in the definition (label linkbase AND annotation section)
Total debits, Total credits, Amount remaining on invoice
originatingDocumentStructure
Why allowed? Strong demand from users.
What complications? Too many open questions on what they mean.
XBRL
GL represents (in the gl-cor) the primary monetary amount as a combination of
three fields: amount (a signed amount), signOfAmount (a
separate sign) and debitCreditCode (a separate indicator for specifically noting
something as a debit or credit). It does this because that is how
different accounting systems represent these numbers (XBRL GL as audit tool).
In addition, amountCurrency (gl-muc) further describes the monetary amount.
We
have been told that there is a huge difference between a negative Debit and a
Credit. A tax or forensic examiner wants to know that a company made two
entries of 1,000,000,000 DR and -999,999,999 DR, not just that there
was an accumulated 1 DR or entries of 1,000,000,000B DR and 999,999,999
CR.
When
populating totalDebit, which combination of signed, unsigned and dr/cr noted
items should go there? (The Conceptual Guide has a table for
interpreting all of the combinations.)
XBRL
GL is designed to do multicurrency. This means both entries where the basic
amount is in different currencies and multiple currencies for
each transaction at different times in the currency valuation cycle. Is ONE
totalDebit sufficient? Should there be totalDebit for each currency?
Is it just a hash and the currency is not even necessary?
We are adding these hashes to gl-bus. This
makes sense on the one hand because we have had more than one group request it.
It does, on the other hand, dilute our GL philosophy, and we discussed
previously that putting these in the TAF helped differentiate between the needs
that come in from a population as opposed to working in the general framework.
Will
totalDebit and totalCredit have meaning for documents other than journal
entries? For a trial balance, should it always add up to zero?
What is their relevance to an AR aging? Is there some other use of XBRL GL for
data exchange where we need to consider the use of these new fields?
And for balance left on a document,
(Cut-off
issues)
A field (enumerated) to indicate at what point this fact is determined(based on
the program that creates the field and the data maintained
within the accounting system - some systems that maintain a balance only update
it upon printing monthly statements, for example). Is the balance
presented
1) as of the files creationDate,
2) as of the periodCoveredEnd date,
3) as of the last month end
4) as of the last statements printed
5) as contained within the application creating it
6) as of a manually provided date (please provide)
6) some other option?
For example, if we create the file on
October 5 to transfer the information as of September 15, what balance goes
there? Some systems are able to do the cut-off, many are not.
(Practical
issues)
Would that outstanding balance only be populated on the originating document
(the invoice)?
What would it mean if it was also populated on a related payment, credit memo,
or debit memo? Should it be zero on a fully applied debit memo?
What would it mean if it was inconsistently placed on some documents and not
others?
If a check is only partially applied or given as a deposit (in advance of an
invoice), does the check as a document have an outstanding balance?
(Currency
issues)
XBRL GL has been designed to provide full multi-currency reporting. Is this Balance
left on a document the balance in the original currency, the home currency,
some other currency? Do we actually need to provide MULTIPLE Balance left on
document fields?
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 (www.xbrl.org/legal).
This document and the information contained herein is provided on an AS IS basis and XBRL INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 (www.xbrl.org/legal).
B. Document History (non-normative)
Date |
Editor |
Summary |
|
2007-08-01 |
Eric E. Cohen, Gianluca
Garbellotto |
Original Document. |
|
2007-08-22 |
Gianluca Garbellotto |
Editorial for Publication |
|