Todd Boyle (mailto:tboyle@rosehill.net
)
Morten Jacobsen (mailto:morten@netaccount.com
)
Copyright © 2002 Netaccount AS
This is a working draft produced by Netaccount, AS and SINTEF as a proposal to developers. This draft is still under development, and may be updated, replaced or made obsolete by other documents at any time. Any final requirements document will be a contract among some community of developers.
These requirements are to guide developers of a library of General Ledger Information Entities (GLIEs). The GLIE library will consist of information entities such as dates, times, parties and products (data elements) suitable for registration in an ISO 11179 metadata registry or ebXML registry/repository, or as a native application interface.
The library will specifically support the payloads passed between General Ledgers, Accounts Receivable/Accounts Payable (AR/AP) systems, and ebXML business collaboration software.
The library elements will represent any discrete economic resource flow or commitment that can be quantified in money or unit measures, as well as the adjustments and summarized totals which are found in ledgers and other systems. The library will provide a UML models which describe use cases for passing transaction data between a variety of business objects such as web services, legacy accounting ledgers and business applications.
The library will consist of Core Components
(CCs) and Business Information Entities
(BIEs) compliant with the UN/CEFACT Core Components Technical
Specification, UML
models, and XML schemas for
each usage scenario generated from the UML models.
GL entries will express transactions from the viewpoint of an Owner similar to
double-entry general ledgers; i.e., positive amounts are increases in assets of an
Owner, and the sum of a bunch of entries expresses the total balance of a
resource at an instant in time.
By adopting the GLIE library and ebXML registry/repository, business may align the semantic content and grain of their internal metadata with globally standard data element names and definitions (ebXML Core Components) used in external transactions with trading partners.
Design goals are conceptual rather than concrete, and concern the entire architecture rather than a specific part of it.
GLIEs should be sufficiently expressive to describe the business state of economic resources, and the economic events causing transitions in state, for businesses of all size, with consistent grain and semantic depth.
GLIEs should be straightforwardly usable by business software developers.
The number of optional interpretations of a GLIE is to be minimal, ideally zero.
GLIEs should adopt existing, global mechanisms for resolving codes and identifiers into their meanings (parties, products, etc.)
Ontological approach: GLIEs should represent economic substance (native character of economic events), rather than system or workflow artifacts.
The GLIEs design should be prepared quickly.
The scope of information represented by the GLIE library MUST NOT be arbitrary or unconstrained. Designers MUST articulate and and conform with a definition of scope.
Decisions to include a particular semantic entity in the library SHOULD be determined by its necessity in achieving specific business requirements of the Owner, whenever changes in assets or liabilities are executed in more than one system. Following are examples of business requirements that MAY be impossible for Owners to achieve without a consolidated view, if they are running multiple systems:
1. financial reporting (including financial statements under GAAP)
2. tax reporting (measurement of taxable income, sales subject to VAT, etc.)
3. cash flow reports and management, including basic optimization of interest yields/costs.
4. fiscal control and internal control over resources, e.g. assets managed by subledgers, hosted services, etc.
5. payables and receivables management and settlement,
6. management of inventory and other non-monetary resources.
7. fiscal control and oversight over multiple applications,
8. foreign currency translations, and
9. consolidation and elimination for reports of multiple business entities.
Owners MAY require a summarized, consolidated view of transactions for at least these nine objectives. For example, you cannot manage cash or inventory if you have two unconnected systems with partial data. The nine requirements above are the primary scope of the GLIE library.
Since companies often maintain integrated business systems, new applications sometimes cannot succeed unless it integrates with those applications to form a summarized, consolidated view for additional, high-level purposes which may include the following. Developers SHOULD consider these in designing the entities within the GLIE library only to the extent they do not detract from the primary scope.
- management of customers, sales relationships, etc. (CRM)
- management of projects and collaborations, both internal and external
- management of supplier relationships
- management of employees productive outputs and their payroll and HR inputs, etc.
- management of programs and funds (within governments and not-for-profit)
The following usage scenarios are representative of the problem space that must be served by the library.
For purposes of this section, a General Ledger is a collection of the historical transactions of a business, such as purchases, sales, payments, etc. These may have originated in different software modules. A GL may be either a single physical table, or a view or a replica of one or more other tables. It may contain summary entries as well as individual transactions. Not all companies have GL's. Every deliverable of a GL can be produced by reporting software, directly from multiple, diverse data stores without any intermediate, consolidated view called a GL.
A subledger is a role, within a set of behaviors in which the transaction history in a ledger or other business system is posted into its parent ledger.
Regardless of whether a company has a GL or non-GL architecture, batches of transactions have, for many years, been transported between disparate systems in classic, double entry accounting CDEA format, using a very simple choreography called "posting". (See appendix B, for discussion of posting from subledgers to ledgers. ) The CDEA accounting format is a static, self-evident representation of past events. (See appendix C, example GL data.) Posting from a subledger to a ledger is just appending records, with various controls. Most GLs require that the account classifications on each entry are valid, and debits equal credits, etc.
Following is a generalized use case of any software application submitting a
set of GL transactions to a general ledger.
Actors: Software Application (APP),
Owner's general ledger (GL).
Goal/Postcondition: The essential facts of purchases, sales,
fulfillments, payments, etc. originally created in the APP have been successfully submitted by the
APP to
the GL, and the GL has imported or included them, correctly.
Roles: APP as subledger submitting transactions,
GL as destination or master GL.
Preconditions:
- The transactions being submitted by the APP are transactions of this Owner
and no other party.
- The GL or the user of the GL, has a method of detecting omitted GL entries
or repeated duplicates of the same entry(ies).
- Owner has used APP (or, delegated authority to agents or employees to use
the APP) to record sales,
purchases, etc. with Trading Partners.
- The APP is smart enough to capture dates, amounts, and other details
sufficient for the 9 objectives in section 2
(Scope).
- The APP has either mapped its GL interface to GLIE library, or uses GLIE
schemas
as its native document format for exporting views or replicating data to
general ledgers.
- Similarly, the GL has either mapped its GL interface to GLIE library, or
uses GLIEs as its native import format.
Steps:
1. The APP receives a request through one of its interfaces,
requesting the export of transaction data meeting certain criteria such as
time interval, transaction type, etc. (this is a
"pull" model; "push" models are also possible.)
2. The APP parses the request and finds every economic event or
commitment entry within its storage or history, meeting the criteria.
3. The APP creates a document or stream containing valid representations
of one or more economic events or commitments. The XML instance conforms with the
GLIE XML schema,
by putting dates, amounts, and other facts between the appropriate tags.
4. (optional step) If necessary, a script or helper application
transforms the transactions from the native interface format of the APP,
into a GLIE XML instance. For any given application, only one GLIE interface
mapping or helper application is required.)
5. The APP sends the XML instance to the GL using any appropriate message
service, asynchronous process, or invoking or responding to whatever software interface
is provided on the GL for this purpose. (Note; any of a large number
of intermediary applications such as XML transformation may be inserted
between APP and GL, if GL does not understand GLIEs.)
6. (optional step) If necessary, a script or helper application
transforms the GLIE XML instance into the native interface format of the
GL. For any given application, only one GLIE interface mapping or
helper application is required.)
7. The GL begins parsing and validating the XML instance, and
executing its particular import processes to include, or append, the
economic events or commitments from the XML instance in its information
set.
8. The GL applies controls to prevent omissions, duplications, or
other errors.
Trigger:
A human or machine initiates a request to the APP. to hand over some
data.
Main Success Scenario:
1. The GL sees and manages, data from the APP as being just like any other subledger.
2. Whatever diverse economic events or commitments were stored in the APP
have now been accurately replicated within the master general ledger.
3. The humans using the GL see the APP as just like any other
subledger, requiring no training.
4. No modification or disabling of features was required by the APP, as a result of
using the GLIE library.
5. The GLIE library was expressive enough to carry the particular
details required by the GL to validate all entries.
6. The GLIE library also was sufficiently expressive to allow the GL
to detect omission, duplication or other control errors among the stream or
sequence of entries from APP.
(Note 1: this usage scenario is required in both directions; i.e. the GL notifies an APP of commitments and movements that may have taken place in the environment such as changes in cash or available inventory.)
The term xSP encompasses ASPs (application service
providers), web service providers, business service providers, etc. When a company or Owner delegates business processes to an
xSP, while continuing to maintain his own GL, an integration or
replication solution is required. The interfaces provided by the xSP
may be single-entry event messages, or CDEA.
Following is a generalized case of any Agent, ASP,
host or a web storefront executing a transaction with a Trading Partner
(TP) on behalf of the Company (Owner).
Actors: Trading Partner (TP), Service Provider (xSP),
Owner's general ledger (GL)
Goal/Postcondition:
A purchase, sale, fulfillment, payment, etc. has been successfully concluded between xSP acting on behalf of
Owner, and the Owner's TP, and, Owner's GL has been correctly posted.
Roles: xSP as executor of a transaction, TP as executor of a transaction
Preconditions:
- Owner has a contract with an xSP delegating authority to conclude sales,
purchases, etc. with Trading Partners.
- Owner has defined policies or specific terms to the xSP including prices and the manner and timing of buying, selling, etc.
- Owner has instructed xSP to submit all sales orders, purchases,
commitments, fulfillments, etc. to Owner's GL
- The xSP either A) knows the account codes of the GL and produces valid and
balanced CDEA, or, B) the xSP and GL have developed a
custom integration, scripts, etc. to transform the xSP's event messages into
CDEA format required by GLs.
- Similarly, either A) the GL understands the GLIE XML schema and its
components natively, or, B) the GL's interface has been mapped to the elements
of the GLIE XML messages, or, C) a helper application or script has been
prepared to transform the GLIE XML messages to and from the interface of the
GL application.
- A TP has completed his search and decision process, to conclude a purchase, sale etc.
Steps:
1. TP initiates communication with the xSP, (or, at instruction of
the Owner, the xSP initiates communication with the
TP.)
2. A valid contract is composed by one actor or the other
(consideration/monetary amount, time and place, etc.)
3. The terms of the contract become available to both parties.
4. A computer record is captured by xSP of the facts of whatever was committed
and/or transferred by each party.
5. The xSP composes an XML instance conforming with the GLIE XML schema,
with those facts arranged in the appropriate tags.
6. (optional step) If necessary, a script or helper application
transforms the transactions from the native interface format of the xSP,
into a GLIE XML instance. For any given xSP, only one GLIE interface mapping
or helper application would be required for all its users.)
7. The xSP sends the XML instance to the Owner, using the message
service and invoking whatever software interface, was agreed upon
between Owner and xSP.
8. (optional step) If necessary, a script or helper application
transforms the GLIE XML instance into the native interface format of the
GL. For any given application, only one GLIE interface mapping or
helper application is required.)
8. The GL begins parsing and validating the XML instance, and
executing its particular import processes to include, or append, the
economic events or commitments from the XML instance in its information
set.
9. The GL applies controls to prevent omissions, duplications, or
other errors.
Trigger:
A TP and the xSP acting as the Owner's agent, among all their
diverse activities, got to the point in their interaction where a purchase, sale or other
commitment
or resource flow is recognized by the xSP under Owner's criteria,
e.g. laws governing recognition of a sale or purchase.
Main Success Scenario:
1. TP and the Owner thru its xSP, were able to conclude a contract, commitment or transaction for a monetary amount, product or service.
2. The xSP was able to capture all of the sorts of information
necessary for the 9 objectives in section 2
(Scope).
3. The xSP was able to correctly transform that information from its
indigenous form, into a GLIE XML instance.
4. The general ledger entry(ies) sent by the xSP were a
self-evident and unambigous representation of the business event.
5. The Owner's GL software was able to post the GL entries within a
balanced, valid GL transaction.
6. The Owner was completely informed
of every movement in his cash, inventory, payables, receivables,
etc. If Owner has multi-location sales and inventory software, the
information in the GLIE XML instance is sufficient for basic integration
with Owner's software.
Note to developer: this usage scenario is required in both directions; i.e. the Owner notifies an xSP of commitments and movements.
It is a priority of the GLIE library to provide a document model for the information content of Accounts Receivable and Accounts Payable (AR/AP) records.
The goals, and scope of information content, in exchanges between human or automated business processes of debtors and creditors are described in the AR/AP submission. The functions of AR/AP software, and patterns of multi-document exchanges, are outside the scope of the GLIE library.
AR/AP records include the whole universe of orders, invoices, and payments, and are necessarily more detailed than most other GL entries. AR and AP clerks cannot otherwise resolve differences or administer settlements.
Following is a generalized use case of any software application submitting a
set of AR or AP transactions to a trading partner.
Actors: Any application or GL of Owner holding an Accounts Receivable
entry (Creditor), and any app or GL of trading partner, holding the
associated Account Payable entry (Debtor)
Goal/Postcondition: The essential facts of some past sale by
Owner exists in his App or GL, and the GL has imported or included them, correctly.
Roles: CREDITOR (receivable) GL, submitting transactions,
and
DEBTOR (payable) GL, receiving transactions.
Preconditions:
-The essential facts of one or more past sale(e) entries (as minimum, an
amount, date/time of sale, and product or service identifier and
quantity/measure) have been stored in CREDITOR GL by its owner.
-Those transactions are transactions between CREDITOR GL and the business
entity who owns DEBTOR GL.
-The DEBTOR GL has methods of detecting technical failures in the sequence
of AR/AP documents, such as omitted entry(ies) or repeated duplicates of the same entry(ies).
- The DEBTOR GL has methods of evaluating the business correctness within
the AR/AP document payload, such as over/under billings due to pricing, due
to quantity, due to previously settled or not yet due, etc.
- The DEBTOR GL has a facility for receiving incoming GLIE transactions from
CREDITORS and DEBTORS which stores them reliably for inspection and
approval, without automatically posting them.
- The facility, script, method etc. employed for incoming GLIE transactions
from reciprocal parties is capable of transforming them into Owner's context
(flipping any notation such as "Receivable" to
"Payable", changing the sign of Amount and Quantity, etc.)
- Both DEBTOR GL and CREDITOR GL have either mapped their GL interfaces to GLIE
library, or
use GLIEs
as their native document format for exporting views or replicating data to
general ledgers.
Steps:
1. The CREDITOR GL receives a request through one of its interfaces,
requesting the export of transaction data for a particular DEBTOR meeting certain criteria such as
time interval, transaction type, etc. in GLIE format. (this is a
"pull" model; "push" models are also entirely possible.)
2. The CREDITOR GL parses the request and finds every economic event or
commitment entry within its storage or history, meeting the criteria.
3. The CREDITOR GL creates an XML instance containing valid GLIE representations
of one or more economic events or commitments, or sequences of economic
events or commitments, resulting in a receivable entry due from DEBTOR GL.
4. The XML instance conforms with the GLIE XML schema,
with those facts arranged in the appropriate tags.
5. The CREDITOR GL sends the XML instance to the DEBTOR GL using any appropriate message
service, asynchronous process, or invoking or responding to whatever software interface
is provided on the DEBTOR GL for this purpose. (Note; any of a large number
of intermediary applications such as XML transformation may be inserted
between CREDITOR GL and DEBTOR GL, if eitehr GL does not natively understand
documents from reciprocal parties composed of GLIEs.)
6. The DEBTOR GL begins parsing and validating the XML instance, and
executing its particular import processes to include, or append, the
economic events or commitments from the XML instance in its information set
as unposted/unapproved entries. (GL interfaces in internal integration
sometimes, similarly, do not delegate posting authority to subledgers.
However, GL interfaces never delegate posting authority to trading partners.
)
7. The DEBTOR GL applies technical controls to prevent omissions, duplications, or
other errors in sequence or control.
8. The DEBTOR GL applies business controls to prevent over/under
statements of liability, quantity, or
other business errors. These may be as simple as (cryptographic
hash signature on entry(ies) retained by the DEBTOR GL during the course of
business transactions conducted earlier in some real time processs such as a
supply chain interaction.)
Trigger:
A human or machine initiates a request to the CREDITOR GL. to hand over some
data to the DEBTOR GL (for example, a clerk in the accounts receivable
department sending dunning notices, or routine monthly statements or any of
a large variety of near-realtime notifications.)
Main Success Scenario:
1. DEBTOR GL has an unambiguous electronic representation from
CREDITOR GL without having to learn numerous Invoice, Order, Payment, etc.
schemas.
2. The DEBTOR GL has the necessary line-item detail to automatically
compare its existing liabilities with the CREDITOR GLs statement of account,
automatically matching every type of diverse economic events or commitments
that agree, and identifying every item that does not agree.
3. The clerk using DEBTOR GL spends 100% of their time on high level
issues rather than mechanical comparison and reconciliation processes.
4. The entries sourced within CREDITOR GL begin to appears to the GL just like any other
subledger. Accountants can navigate it with their tools of choice, and
it flows into data warehouse and other tools seamlessly.
(Note 1: requirements for GLIE library are to support this usage scenario in both directions; i.e. the DEBTOR provides account detail to CREDITOR, for example, to assist in reconciliation.)
Organizations can improve efficiency in business processes, particularly at fulfillment and settlement stages, by sharing transaction data. Sharing encompasses transmitting copies of business transactions like invoices, orders and remittance advices (replication), as well as operating from single data repository such as an exchange. In other words, shared transaction behaviors may be implemented in Peer to Peer models or in shared, hosted models.
The P2P models of sharing transactions are implemented unilaterally by a party, offering to send documents such as orders or invoices, offering such inducements as standard XML vocabularies that can reduce the data entry costs of recipient, or digital signatures, or UIDs or keys by which copies of transactions may be requested by trading partners later.
For example, since Owners of applications usually record all sales and purchases in their own systems, they might at very little extra cost, digitally sign whatever document (invoice, purchase order, etc) they have created in their accounting systems. They might send to their trading partner an email, with a link to the document, and put the compressed, encrypted document on their website. This enables the trading partner to retrieve the document, reducing his data entry and bookkeeping errors, without imposing any constraint or dependency on either party.
The hosted models of shared transaction choreography are provided by various commercial repositories, escrow services etc. Some of the services are mere archives which maintain any digital content with timestamps, signatures, etc. without business logic. There are also various exchanges, hubs, hosts, etc. through which parties actually execute trades. Stock exchanges and banks are classic examples. The logical minimum behavior of a shared transaction choreography is to enable one party to compose a document, naming a reciprocal party, reliably transmits that payload to the hub or host, sometimes obtaining responses such as agreement or rejection by the reciprocal party, and reliably storing each message of the conversation on the hub. In the case of a bank, the bank maintains cumulative, inter-party balances for everyone's convenience.
Any system which has, as its end state, a single accountable copy of the transaction visible to both parties, is a Shared Transaction Repository. The GLIE library or other common, horizontal vocabulary will support the essential minimum information content required for both P2P and hosted models of shared transactions. Because this data is as diverse as the economy itself, it requires a document model similar to a general ledger.
It is a goal of the GLIE library to serve the needs of ebXML runtime collaboration managers for bi-directional notification of changes in monetary and inventory assets (resources) caused by transactions on disparate systems.
1. The GLIE library must be capable of communicating any changes in commitments, location, ownership, possession, etc. caused by ebXML interactions managed by the BCM or caused by any other system of the company. Obviously, the disparate systems cannot be effective with outdated inventory counts.
2. The GLIE library must be expressive enough to communicate changes in accounts payable, accounts receivable, cash and any other monetary asset or liability, FROM any local accounting or business system TO the BCM, and vice versa.
It is a goal of the GLIE library to provide the minimum necessary content model for both of the above (monetary and nonmonetary resource changes) together with sufficient details to meet the 9 objectives in section 2 (Scope). These details would include dates/times, and details of how and by whom, the transition into this economic state was caused to happen. (The technical use cases for this scenario MAY be the same as ledger-subledger relations expressed in 3.1 or GL-xSP relations in 3.2, but this cannot be determined until the design of the BPSS and example collaborations is more complete.)
It is a goal of the GLIE library to represent any arbitrary listing of detail or aggregate quantities contained in any transaction repository such as a General Ledger, together with their accounting classifications, and identifiers for party, product, location and other attributes.
Computerized accounting systems have been designed, for at least 25 years, to return either detail rows or aggregates interchangeably. Accountants and clerks manage them in 2-dimensional spreadsheets. The SQL language was in large part designed for managing row data. For example "SELECT * FROM myGLtable GROUP BY account" is often used to produce the trial balance from a GL table.
Accordingly, it is a requirement of the GLIE library to serve as a container for reporting purposes, along the Account dimension, or by XBRL types, or by other objective transaction attributes such as product, party or location.
The following key words are used throughout the document to specify the extent to which an item is a requirement:
This word means that the item is an absolute requirement.
This word means that there may exist valid reasons not to treat this item as a requirement, but the full implications should be understood and the case carefully weighed before discarding this item.
This word means that an item deserves attention, but further study is needed to determine whether the item should be treated as a requirement.
When the words MUST, SHOULD, or MAY are used in this technical sense, they occur as a hyperlink to these definitions. These words will also be used with their conventional English meaning, in which case there is no hyperlink. For instance, the phrase "the full implications should be understood" uses the word "should" in its conventional English sense, and therefore occurs without the hyperlink.
Definitions of data elements and XML schemas in the library should be formal and concise. This presents a very difficult challenge, because the semantic entities in the library MUST be sufficiently exact to be usable for the legal and accounting purposes in section 2 (Scope). At the same time, the primary user of the GLIE library will be developers and systems integrators, who must evaluate the appropriateness of various GLIE semantic entities as buckets for whatever labeled elements exist in their systems. Therefore, the definitions must be reasonably brief and readable.
In principle, every GLIE SHOULD be adopted or derived from an authoritative vocabulary, from a specific domain context.
For example, semantic entities which are simple business types (amounts, dates, classifications, etc.) SHOULD be adopted or derived from definitions in EDI, or ebXML Core Component specification or catalog. References to business process requirements or economic modeling abstractions MAY use the terminology of the UMM metamodel, chapter 8, the ebXML BPSS, or other normative choreography. References to system behaviors MAY use the RM/ODP Enterprise Language. Other terminology SHOULD be adopted from authoritative sources in domains such as accounting or contract law.
Althought the GLIEs themselves are definitions, additional documentation MUST accompany the library. Documentation MUST include guidance for users, and a glossary of terms and their sources. The three audiences are software developers building systems which deliver or receive GLIE content, integrators connecting two or more disparate systems with GLIEs content, and accountants, auditors, and managers who have a need to read or understand GLIE instances. Documentation SHOULD be minimal and terse.
The library MUST be defined in a way that is independent of any syntax or protocols with which it is used. The library MUST neither favor, nor impede, the use of any computer language or architecture.
Wherever possible, the semantic entities in the library SHOULD be strive to satisfy the requirements of all contexts. In Goals, #5, GLIEs should represent economic substance (native character of economic events), rather than system or workflow artifacts. It follows that GLIEs will be predominantly, horizontal and will apply across multiple contexts.
The CCs and BIEs included in the GLIE library MUST be compliant with the ebXML naming conventions and other requirements contained in ebXML Core Components Technical Specification sufficiently for inclusion in an ebXML RegRep.
The GLIE library MUST include at least one example XML schema for each usage scenario, capable of being inserted into the ebXML RegRep as an assembly document. Each XML schema MUST be generated from a UML model which documents one or more abstract business process model(s) within which the entries are meaningful.
The ebXML Core Components Technical Specification provides specifications by which the definitions of documents (such as GLIE XML instances) may be stored in the ebXML RegRep. Documents or schemas may then be generated which use Core Components and BIEs in various combinations.
Historically, no common data dictionary, schema or library, has ever achieved wide adoption in internal application integration (EAI), for a very critical reason: most internal integrations are done only once. The integrator has two applications, and his easiest solution is to directly map the two interfaces (A to B). There is no payoff for performing two mappings, (A to Standard, and B to Standard) unless the developer is planning on integrating these products on other sites. Large integrators for whom this may be true, see economic disincentives to contributing their integration solutions as public standards.
However, when GL components and documents exist in registries, users can quickly search and locate document formats for their particular purposes. This Requirements Document calls for example GL schemas for each of its usage scenarios. This provides a higher likelihood, over time, that the particular mappings for popular accounting products to the GLIE library . It also provides high likelihood that some pre-existing transformations directly from B2B documents such as invoices, into GLIE schemas may be found in the registry. For the first time, VARs and integrators may have an incentive to standardize GL interfaces.
Semantic entities in the library MUST unambiguously represent the business state of resources, as they exist statically, as a result of economic events, resource flows, or commitments events.
a. The library MUST support every category of business transaction or resource flow or commitment that is reportable under GAAP. (This requirement does not imply the GLIE 1.0 library must articulate every criteria necessary for classification in GAAP reporting, or provide automatic classification formulas. Rather, the library must be capable of expressing every type and category of economic event and economic resource that triggers recognition under GAAP.)
b. The library SHOULD further support the semantic entities within the OAGIS Post Journal, the EDIFACT ENTREC and LEDGER messages, the XEGL taxonomy, and economic event notifications of UN/CEFACT's TMWG meta model which represent economic substance.
Note that it is not a goal of the library to represent all of the semantic richness and depth, of all transaction data. The overriding goal is to achieve a consistent grain and depth of information which is as deep as reasonably possible, within cost constraints acceptable to developers and companies in e-business, particularly SMEs.
4.2.9 Classic Double Entry Accounting methodology
GLIEs MUST (among other things) fully support CDEA methodology. As such, GLIEs must be fully capable of representing historical transactions as balanced sets of debit and credit values together with dates, account classifications, and other elements.
4.2.10 Commitments and In-process information
GLIEs MUST, furthermore, include representations of the business state of transactions prior to completion, beginning at the point in time when commitments (e.g. orders) exist. GLIEs must include Unposted as well as Posted information. Unposted information is subject to fewer constraints, and may include any valid business information about a resource flow or commitment, formatted as a GL entry or entries, even if lacking Account classifications. Posted information however, is fully compliant traditional double entry GL data with account classifications.
4.2.11 Constraints
The CDEA methodology, as well as other methodologies using the GLIE library, apply constraints or models involving the relationships between the discrete entries (the atomic economic movements of monetary amounts or unit quantities). The relationships among entries enforced by applications may include that entries balance, economic flows are reciprocated, duality relations tracked, transactions are consistent with expected choreography or collaboration patterns, etc.
In principle, constraints affecting relationships between amounts are outside the technical scope of the GLIE library. The library represents the business state of individual resources, and individual business events that affect those states. Constraints and validation rules SHOULD be specified only at the level of individual semantic entities, within the GLIE library.
Version 1.0 of the library MUST not preclude the ability to add update capabilities in future versions.
The following references are some of the works relevant to this requirements document.
The consensus among all users of general ledgers, upon either their semantics or underlying business rules, is not perfect. The following is non-normative, background discussion for purposes of this Requirements document.
All enterprises have economic resources. Economic resources include monetary assets such as cash and receivables, and non-monetary assets such as inventory. A negative economic resource (a liability) is an obligation to pay resources.
The life of an enterprise begins when it transfers economic resources in or out. The log or history of these transfers is called a ledger, and its discrete amounts hereinafter referred to as ledger entries. The names of various resources are called accounts, and cumulative totals of entries for a particular resource are called balances.
Under GAAP, all non-monetary resources are of course, valued in monetary terms. For example, inventory may be valued at lower of historical cost or market. However, a GL entry may also consist of a quantity of inventory or other resource, without monetary valuation, for example at points in the transaction lifecycle before its value is practical to determine. An example is a stock flow entry generated by an operation in manufacturing, or movement in/out of a warehouse. The goal of these workstation and barcode systems does not always include statutory-grade, financial accounting in real time. (Accountants regard such GL entries as suspense or unposted entries.)
The monetary amounts and non-monetary quantities contained in a GL are determined by the values and terms agreed to by parties in external economic exchanges. All enterprises relevant for this document, have external balances. External balances include cash, accounts payable and receivable, and other forms of monetary assets and liabilities, both short term and long term. You will notice at this point, that all assets, other than non-monetary assets like inventory, are external balances.
A conventional GL entry is an amount (a monetary value assigned to a specific economic resource, in an arms-length exchange between the owner and unrelated party or parties.) A GL entry for purposes of this document should also include the quantity of economic resources such as inventory, in addition to the monetary value assigned to it (usually cost).
Business transactions generally involve reciprocal exchanges. Classic double entry accounting (CDEA) methodology tries to record both movements in resources of economic exchanges. For example, in a sale, the seller records both the monetary amount received, and the quantities and descriptions of what was surrendered. The buyer records both of his movements (cash out, inventory in.) This is called a duality relation, in the REA ontology.
AR/AP Entries are intrinsically objective, not subjective. Their monetary amounts and other attributes are determined within arms length exchanges with 3rd parties. The use of estimates within manually prepared accounting entries is required in some circumstances but is always pursuant to expected future cash flows and estimates are always resolved, sooner or later against real cash flows versus 3rd parties outside the entity. Thus you might say, every entry in an accounting system has (at least) two sovereign participants having adverse interests, agreeing upon a strike price.
For purposes of this document, entries are the debit and credit records which form balanced sets called transactions. Whenever the word "transaction" is used for some other purpose such as to denote a 3rd party interaction not having any associated ledger entries, the usage will be conditioned.
A transaction is composed of a balanced set of 2 or more ledger entries, plus an associated set of information which applies to all entries in the transaction. An entry is often viewed by accountants as one line of a report or listing, and a transaction as a set of rows summing to zero. Credits and Debits are often associated with negative and positive signed decimal values respectively, since this notation facilitates enforcement of the accounting equation in excel spreadsheets and other tools.
A transaction set is a collection of one or more transactions.
An "AR/AP facility" is a special case of a general ledger. A "General Ledger Facility" is a neutral piece of software which is maintains one or more transaction sets, for one or more owners, in accordance with the mechanical rules of classic double entry accounting (CDEA). The mechanical rules include such rules as debits equaling credits, and the annual closing of net income into retained earnings. A great variety of other semantic rules dictate the patterns of representing purchases, sales, and other transactions but those are not enforceable by software. Some of the structural rules enforceable by a GL are cited below.
A transaction set is synonymous with a ledger, and for purposes of this document, specialized transaction journals such as sales journals, payroll journals, etc. are synonymous with the term ledger as long as they contain sufficient information, interfaces, etc. to behave like a historical list of balanced transaction entries.
The Owner of a transaction set is a special actor whose financial position and/or results of operations are modeled by the transactions within a transaction set. In other words, a transaction set in CDEA can only reflect entries to the assets, liabilities, income, etc. of an Owner. There is no such thing as a CDEA transaction set without an Owner, or having two Owners, because the names of the accounts and their relationship as debits and credits reflect one party to the transaction asymmetrically.
The terms "master ledger" and "subledger" denote a relationship between two transaction sets (i.e. two ledgers) as follows:
1. the ledgers are separate and
distinct at the level of users' views. They are often maintained by separate software and/or
in physically separate
locations or computers. They may also be maintained in a highly
consistent state, in an entirely integrated system, while presenting ledger-subledger
views for reasons of performance, security, accounting reporting, etc.
2. a master ledger may have more than one subledger, but a subledger
can only belong to one master ledger.
3. a master ledger may technically be a subledger in relation to yet
another master ledger.
4. transactions are never entered into the subledger at a point in
time later than the master ledger. Generally, transactions are posted
to the subledger at points in time substantially earlier than the master
ledger, and managed by applications different from the master ledger.
5. a master ledger is often in an inconsistent state in relation to
its subledger, i.e. the master ledger often does not reflect the most recent
entries in a subledger.
6. there is a scheme of updating the view or replicating transactions which exist in the
subledger, into the master ledger. This may be either in complete detail, partially
aggregated amounts, or totally summarized form. The highest level of
summarization possible in a subledger is usually amounts by period such as
months, by account.
7. master ledgers often apply dedicated business logic to a particular
account(s) associated with a particular subledger(s), which are then called "control
accounts" for the subledgers. For example, a sales journal or accounts
receivable subledger might be associated with a control account called
Accounts Receivable in the master ledger; this control account would be
dedicated exclusively to reflecting the total value of AR assets managed by
the subledger.
The transactions (and their entries) within any transaction set may be combined, i.e. appended, to form a consolidated ledger. A consolidated ledger (before eliminations) is defined as the simple appending of the transactions of two or more ledgers into a single list. "Eliminations" are adjusting transactions composed by the accountant or by the system, or other technical mechanisms, to reverse the financial effects of sales, purchases and other transactions between the subledgers of the same Owner (i.e. to avoid counting self-dealing as if it were business conducted with outsiders.) Eliminations are one of the fundamental accounting processes in any consolidated corporate group.
The term "root ledger" is used in this document as the comprehensive model of all transactions (the complete information model representing financial position and results of operations) of an Owner. (the term master general ledger is sometimes used for this meaning.)
The Owner (business entity) may be a corporation, partnership, or collection of parties within a joint venture. (The attributes or characteristics surrounding the Owner such as its legal form, is a question that appears to be completely independent of the architecture of general ledgers, or the CDEA methodology.)
The GL is an information model which represents the financial position and results of operations of the Owner. The timing and amounts of entries is not at the discretion of users or system developers. Amounts, timing and classification of entries is usually required to be done in accordance with generally accepted accounting principles or other comprehensive basis of accounting imposed by Owner. Entries of sales, purchases, and payments within a ledger are anyways, rather meaningless unless they correspond very substantially with legal titles and obligations. For example, a sale is booked when substantial performance such as shipping the goods has occurred.
GAAP results, generally, in symmetric recognition of economic events by both parties in exchanges. The customer records accounts payable at the same time as a seller records accounts receivable. Thus, as intimated above, there is considerable potential for a global synchronization of amounts and timing of the offsetting entries in the books of reciprocal parties to transactions. That potential is a key motivator for the GLIE library and AR/AP project.
General Ledger data comes in quite diverse formats; this is only an example of a small business GL. In this case, having a completely flat structure. Note that each row has a date, amount, total debits equal to credits, and each row has an account classification.
The table displayed to the accountant (below) could be an integrated system that actually has only one transaction table, or it might be a replica, or a view or join of several tables (sales journal, etc.).
Note transaction 25493. Arturo created a cash sale, without capturing sales tax or cost of sales. Perhaps Arturo has sold nontaxable services, or, perhaps the work process and/or data entry process, is not complete. Or, perhaps the missing entries are somewhere else in the table. Arturo's example is chosen to illustrate the points that 1) GL entries cannot, individually, reflect the entire transaction lifecycle from order through shipment and settlement if those happen on different dates, and anyway, 2) GL data is not always complete, at a point in time. Reporting at measurement dates usually requires extra effort.
| transaction Id |
entryId | entryDate | Salesman | JournalType | Account | Dr/Cr | Amount | Party | Product Or Service |
Quantity | product Measure |
settlement method |
terms | tax type |
| 25492 | 01 | 2002/01/21 | Janet | SalesJournal | Sales | C | -1000 | CustomerCo | Widgets | 5 | each | #235 | ||
| 25492 | 02 | 2002/01/21 | SalesJournal | TaxPayable | C | -82 | taxAgency3 | #235 | ||||||
| 25492 | 03 | 2002/01/21 | SalesJournal | Receivable | D | 1082 | CustomerCo | Open | 30days | |||||
| 25492 | 04 | 2002/01/21 | SalesJournal | COGS | D | 670 | ||||||||
| 25492 | 05 | 2002/01/21 | SalesJournal | inventory | C | -670 | Widgets | 5 | each | |||||
| 25493 | 01 | 2002/01/21 | Arturo | CashRecpt | Cash | D | 400 | |||||||
| 25493 | 02 | 2002/01/21 | CashRecpt | Sales | C | 400 |