Accounts Receivable/Accounts Payable Facility
(  AR/AP Facility  ) 
Enterprise Viewpoint Draft - Part 1
 Netaccount AS  -  June 28, 2001
T. Boyle

PART 1:
1a.  Introduction

1. ISO RM-ODP viewpoint approach
2. Purpose of the AR/AP Facility
3. Scope - Five root ledger requirements
4. AR/AP environment and communities
5. Scope Limitations
6. AR/AP Facility Terminology

1b.  Functional domains (jobs) within accounting and AR/AP

1. Fiscal Control (Controller)
2. Cash Control / Cash Flow Management (Treasury)
3. Accounts Payable (Accounting)
4. Accounts Receivable (Accounting)
5. Transaction Taxes (Accounting)
6. Financial Reporting (Controller)

PART 2:
2a.  General Cases between internet BSP, trading partner, and AR/AP Facility

 

1a: Introduction

1a1.  ISO RM-ODP viewpoint approach

The AR/AP Facility is being developed in response to the Object Management Group (OMG) RFP for Accounts Receivable / Accounts Payable Facility.  The Facility is a component of the Corba Financials, a standardized suite of interfaces among accounting software objects. 

This Accounts Receivable/Accounts Payable Facility ("AR/AP Facility") Enterprise Viewpoint is written in accordance with ISO/IEC FCD-15414 and ISO 10746 draft 2000-09-09, "Open Distributed Processing - Reference Model - Enterprise Viewpoint" (ftp://ftp.omg.org/pub/docs/ISO-stds/01-01-01.pdf).  These are normative standards, as excerpted below.

The enterprise language provides the terms and structuring rules to specify the purpose, scope and policies for an ODP system in a manner that is meaningful for the stakeholders for that system, including the owners, the users and the developers. An enterprise specification describes the behavior of the system within the environment with which it interacts. Such an environment can be a technical environment (e.g., the software and hardware environment of a service component) or a social or business organisation (e.g., a group of co- operating companies, a particular service inside a company). 

The enterprise language defines the concepts necessary to represent the behavior expected of an ODP system. It defines structuring rules for using those concepts to produce an enterprise specification. An enterprise specification of an ODP system is an abstraction of the system and a larger environment in which the ODP system exists, describing those aspects that are relevant to specifying what the system is expected to do in the context of purpose, scope and policies of its environment (technical, organisational). It describes the behavior assumed by those who interact with the ODP system. It explicitly includes those aspects of the environment that influence the behavior of the ODP system – environmental constraints are captured as well as usage and management rules. 

An important objective of an enterprise specification is to support an agreement (for example, as part of the contract for the supply of a system) between the potential clients of an ODP system and the provider of that system. Both parties should be able to write, read and discuss such a specification, the clients to be sure of the expected behavior of the system that they will get, and the provider to be clear about the behavior to be realised by the system being provided. Thus, two types of presentation of the enterprise specification may need to be considered for the same system. One presentation may need to provide a view of the specification in terms that are understood by the clients. A second presentation may be needed to present the specification in terms that more directly relate to its realisation. Both types of presentation address enterprise considerations as they concern the system. 

OMG specifications must be expressed in RM/ODP viewpoint languages, UML, and MDA including IDL.  This document is the Enterprise Viewpoint section of the RM/ODP submission. It is not necessary that developers understand every detail of FCD 15414 to use this document, but it is useful to review some definitions from the enterprise language, because many of the terms with precise ODP definitions also have colloquial meanings that can obfuscate specifications.

Party: An enterprise object modeling a natural person or any other entity considered to have some of the rights, powers and duties of a natural person.  Examples of parties include enterprise objects representing natural persons, legal entities, governments and their parts, and other associations or groups of natural persons.  Parties are responsible for their actions and the actions of their agents. 

The Community is a configuration of objects formed to meet an objective.  The objective is expressed as a contract which specifies how the objective can be met. (ISO 10746 sec 5.1)  

A community is a configuration of enterprise objects modeling a collection of entities (e.g. human beings, information processing systems, resources of various kinds and collections of these) that are subject to some implicit or explicit contract governing their collective behavior. 

For a set of entities to be modeled as a community there must be some implicit or explicit agreement about the 
collection covering the reason for its existence, how it is organized and what it does, and what entities 
comprise its membership. This agreement is expressed as the contract for the community that 
-- states the objective for which the community exists, 
-- governs the structure, the behavior and the policies of the community, 
-- constrains the behavior of the members of the community, 
-- states the assignment of enterprise objects to roles. 

The contract can be formed either by a defined process carried out by some or all of the enterprise objects at the time of community establishment, or in an earlier epoch (for example, as a design decision). " (sec 7.3)  

Every community has exactly one objective. This objective is stated in its contract. An objective can be a composition of sub-objectives. (sec. 7.7)

The AR/AP specification focuses on actors within communities.  A party can be an actor.   An actor is a party or other enterprise object, performing a role. 

Role concepts - 6.2.1 Actor (with respect to an action): An enterprise object that participates in the action. 
NOTE... specify which of the actors involved initiates the action.  

6.2.4 Actor role (with respect to a community): A role in that community in which the enterprise object 
filling the role is involved in at least one action of the role as an actor. 

6.1.11 Owner (of an "X"): The party or one of several parties having the right to control the use and disposal 
of the "X". 
NOTES 
1 – Commonly, this is a party paying for the specification, construction, instantiation, or current operation of the "X". 
This party will typically grant authorisation to use the "X" to other parties or their agents. 
2 – Ownership is restricted to parties to enable assignment of responsibility for actions. 
Editor's Note - Part 2 uses ‘"X"’ in both subclause headings and in body text. Part 3 

7.8.2 Role rules - In the specification of a community, each role stands as a placeholder for some enterprise object that exhibits the behaviour identified by the role. An enterprise object may fulfil several roles in one community, and may fulfil roles in several communities. A role in a community may be filled by different objects at different times, but only by one enterprise object at any one time. 


The arapXML project anticipates the adoption of ebXML Core Components, Collaboration Protocol Profiles, and Business Process Specification Schema (BPSS) in the marketplace.   The BPSS is based on the UN/CEFACT Modeling Methodology (UMM).  The ebXML CPP and BPSS provide standard structure and grammar for defining business interactions over networks, i.e. choreography.  

Most GL and AR/AP transactions in business do not stand alone, and do not represent a completion of a contract.  Transactions come in sequences or patterns, at different points in time.  ebXML provides a collection of collaboration patterns for Order/Fulfillment/Settlement for goods or services, Offer/Acceptance, Payment Instruction/ Remittance Advice, etc. The association of PO, Invoice, and payment within a discrete transaction pattern is vitally required, and of course it is provided by all contemporary accounting software in some fashion.  The ebXML provides many more patterns, provides standard ways to define patterns, and addresses the requirements of synchronizing both parties' systems, rather than just the author's system.

Successful integration with ebXML collaboration managers is a business requirement for this AR/AP Facility because without them, small accounting systems cannot manage all of the exceptions cases efficiently.  When paper exceptions occurred, you had paper clues to read.  The internet is much less forgiving. 

Users need to associate the multiple messages and transactions of each deal, within their systems.  Users need the exception handling and rollback of half-completed transactions when they fail.  Users need the framework for legal enforceability.  Users need the signals that tell us whether a deal is finalized or not--signals for economic event recognition.  Therefore, developers are required to read the BPSS and definitions of BusinessTransaction, BusinessDocument, DocumentEnvelope, etc. to ensure the AR/AP Facility can take advantage of the process controls of ebXML BCMs, or behave natively as participants in ebXML business collaborations. 

1a2.  Purpose Of the AR/AP Facility

The purpose of the Facility is to enable interoperability between AR/AP systems and general ledgers, sales and purchasing systems, and other distributed objects and applications for accounting purposes.  The Facility is intended to be a universal general ledger as well as AR/AP ledger,  which meets three top-level, conceptual requirements:

- Internal integration with other business applications within the enterprise, including applications which maintain customer and product information as well as systems which create transactions,

- External integration with business service providers in an Internet environment in which transaction creation, management and settlement is 
delegated, and

- Communication with reciprocal parties by improving the automation of reconciliation and settlement of AR and AP entries.  Defining specific interfaces and describing the minimum obligations or conditions that must exist whenever unrelated parties decide to collaborate to improve efficiency of reconciliation and settlement.

An objective is handoff of administration and settlement aspects of external balances to a back office accounting function, timely and accurately, without impairing the operation of the business applications.  This is A2A (application-application) integration, not B2B integration.  

Sales and Purchases must run efficiently yet, whenever there is more than one selling and/or purchasing system, there must be centralization of AR/AP.  The facility is necessarily based on classic double-entry accounting (CDEA) to achieve the five ledger requirements below, as well as to  provide a traditional ledger interface to legacy applications.  CDEA semantics can coexist harmoniously alongside established systems permanently or  provide a path to incremental adoption.  The Facility modernizes CDEA by making it aware of reciprocal party books.

The key objective shared among unrelated reciprocal parties in AR and AP is to save time and money by automatically identifying the amounts and causes of any differences in mutual balances.  The data most often transmitted between debtors and creditors includes the amount, date/time, product/service descriptors, etc.  This is the same data found on invoices, orders, and statements.  This data is essential to automating the reconciliation and settlement of mutual balances.   

The Facility stores and manages information on behalf of users. The primary users of the Facility are adverse parties in business transactions (buyers and sellers, or their agents) having inherently opposing interests in much of the data stored and managed by the Facility.  Accordingly, the Facility explicitly describes some roles and responsibilities of the Operator of the Facility.  The operator will in most cases be one of the parties to trades, who then assumes any Operator roles.

1a3.  Scope - Five Root Ledger Requirements 

The AR/AP facility attempts to define the minimum necessary functionality for buying and selling on account and the management of resulting changes in cash, AR, and AP.   

An AR/AP facility cannot avoid including the cash account and other external balances within scope, because any software associated with  maintaining and settling of AR/AP, is intimately connected with maintaining cash balances.  Payments and receipts hit the cash account.  It is a minimum condition for operating a business to know the current cash position and near-term cash flow information associated with AR/AP information.  Accordingly, maintaining the cash account and its cash management reports is within scope of AR/AP Facility. 

Whenever there are two or more business systems capable of legally binding changes in payables, receivables, cash, etc. there is a requirement for consolidated view of the complete trial balance and the transactions within.  The trial balance is a listing of balance sheet and income statement accounts summing to zero, i.e. having debits equal credits.  This consolidated view is hereinafter called the root ledger. 

Whenever income or expenses are executed in more than one system (e.g. LANs or the Internet), these needs arise, which cannot be achieved by either of the separate systems in isolation.  Regardless of how excellent they may be, a solution of some sort is required.  ArapXML is designed for these five minimum requirements:

1. cash flow reports and cash management, 
2  payables and receivables management and settlement,
3. general fiscal control and internal control over the sub ledgers, 
4. tax reporting (income, sales, VAT, etc.), and
5. financial reporting / GAAP financial statements.

The five requirements above define the scope of arapXML.  Before any element or component goes into ArapXML, the question is asked, "Is this component really required to be within the boundary of the root ledger, whenever the owner of a company uses more than one business system?" If it is possible for a business function to be performed outside the consolidated root ledger, then it does not appear in this AR/AP facility. 

In conclusion, the AR/AP Facility is a root ledger, or master general ledger because you cannot get AR/AP integration without addressing cash and other current assets so fundamentally that there is little remaining in the GL.  So you might as well build the whole GL. 

1a4.  AR/AP environment and community

The definition of a "community" is above.  Communities are described within Use Cases beginning in Part 2 of this document.  The business entities that appear in the AR/AP environment are

Owners of the company whose economic acts or events are represented in AR/AP transactions, 
Trading Partners - reciprocal parties such as customers, suppliers, etc. named within the data, and 
Agents such as employees, outside business services providers (BSPs), etc. that have been delegated specific authority, responsibility or function by an Owner or Trading Partner.

These actors in the AR/AP community are a subset of the General Ledger communities of OMG's 1999 GL, concerned with passing GL transactions and entries between systems primarily for tax, reporting, and fiscal management.  You cannot be a member of a community dedicated to AR/AP without sharing, also, the objective of integrating business applications with your AR/AP Facility because an AR/AP facility has no native capability to create sales or purchases.  It is just a software object which maintains a ledger.

The functionality of AR/AP Facility is a superset of a GL Facility.  The AR/AP Facility necessarily includes GL integration and replaces a GL facility.  OMG General Ledger Facility is an example of a GL Facility.
Specification ftp://ftp.omg.org/pub/docs/formal/01-02-67.pdf, 
Computational Viewpoint ftp://ftp.omg.org/pub/docs/finance/99-03-05.pdf,
Enterprise viewpoint ftp://ftp.omg.org/pub/docs/finance/99-02-01.pdf  

Two broad types of communities may be observed in this environment: integration communities, and reconciliation communities.

a.  Integration communities consist of an AR/AP Facility and any other ODP system(s) such as internet BSPs or local applications outside the GL. This is a domain community controlled by an Owner. This community is bound by a contract that the dealings executed by system(s) are  replicated to the AR/AP Facility timely and accurately, and the AR/AP Facility responds to interrogations about the payables and receivables sufficiently that the other system(s) can operate without being impaired.  Following is an example of an AR/AP system, supporting multiple BSPs:

b.  The AR/AP reconciliation community includes the trading partner, in a broader contract to improve efficiency of administration and settlement of mutual balances.  This community is described in Section III below.

Note that CDEA is different from other document formats because the owner's viewpoint is embedded in  the values in the document, such as account codes.  The account classifications in a GL entry in a CDEA ledger encode economic events from the subject's viewpoint.  This syntax is only valid in 1st person singular.  Programmatic manipulation of CDEA information, such as transformations from the viewpoint of owner's ledger to reciprocal party's ledger is not impossible but is outside the scope of AR/AP Facility.  To the AR/AP Facility, all CDEA data is just content, and note carefully that the correctness of the content cannot be anybody's responsibility other than its authors. 

Ownership of course also determines the rights of the parties to record them in an AR/AP Facility.  The Facility is a service which maintains content, called CDEA data.  Specifications for CDEA data are found in example transaction patterns for detailed use cases below. 

Scope Limitations

This specification is minimal in one very important aspect: the complexity of business interaction prior to the execution of transactions is embedded within the semantic system of double-entry accounting. CDEA provides a comprehensive grammar for expressing every kind of transaction, within ledger rows. Defining transformations of non-CDEA data such as B2B invoices, into CDEA, or enforcement of the correctness of those transformations or mappings, is necessary for some usage scenarios for an AR/AP Facility. But it is outside the scope of this AR/AP specification.

Authentication and security mechanisms are also outside the scope of this Facility. It is essential that readers of this specification understand the consequences of this limitation in scope.

PARTIES - There is an inherent requirement that the parties named in the transactions in this Facility actually participated in the transactions, i.e. executed them, or authorized their execution. However, the mechanism of authentication, including mechanisms of delegation of authority, is outside the scope of this specification.  The AR/AP schema for transaction data is a document format.  The information contained in the document includes identifiers for party, product, etc. which are actually controlled and managed at a different level of the "protocol stack".  Developers should ensure that information contained in the document is consistent with the party authenticated at the messaging level, system login, the  business process level, etc.

PRODUCTS, etc. - AR/AP systems necessarily contain identifiers for products, services, locations, and other information. AR/AP systems necessarily contain the meanings of those identifiers either embedded within documents or in reference tables of some sort. There is an inherent requirement that product information stored in an AR/AP system is consistent with whatever the parties agreed to, when executing transactions. Developers should ensure that information within the AR/AP Facility is identical to data agreed by the parties at time of sale, purchase, payment, etc.  For example, if RFC 2396 URI references are used as identifiers of party lists, product lists, etc. within a transaction, then the developer must ensure the reliability and security of whatever mechanism associates those identifiers with their underlying meanings.

1a6.  AR/AP Facility Terminology 

An "AR/AP facility" maintains records of the monetary values and terms agreed to by parties in economic exchanges.  All enterprises have external balances.  External balances include accounts payable and receivable, cash and other forms of monetary assets and liabilities, both short term and long term.  External balances are composed of discrete amounts hereinafter referred to as ledger entries.  

An entry is a monetary value assigned to a specific economic resource, in an arms-length exchange between two or more parties.  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 AR/AP facility supports classic double entry accounting (CDEA) methodology, which records both sides of economic exchanges.  Both movements in resources are recorded.  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.) 

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.  http://www.omg.org/cgi-bin/doc?formal/01-02-67.pdf   A great variety of other semantic rules dictate the pattern of representing purchases, sales, and other transactions but those are not enforceable by an AR/AP facility.  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 maintained separately, usually by separate software and/or physically separate locations or devices.
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 replicating transactions which exist in the subledger, into the master ledger 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 maintain dedicated application logic to the account(s) associated with subledgers, which are then called "control accounts" for the subledger. 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 Owner (business entity) may be a corporation, partnership, or collection of parties within a joint venture.   (The attributes or characteristics surrounding the Owner other than its financial assets and liabilities is a question that is independent of the owner's GL.)

The GL is an information model which represents the financial position and results of operations of the Owner.  The determination of timing and amounts of entries is not discretionary: amounts, timing and classification of entries is required to be done in accordance with generally  accepted accounting principles or other comprehensive basis of accounting.   A transaction within a ledger is relatively meaningless, unless its entries correspond very substantially with legal titles and obligations.  For example, a sale is booked when substantial performance such as shipping the goods has occurred.  The precise specification of points within transaction patterns when accounting recognition (posting a ledger) is required by the parties to an economic exchange is within the scope of business process models discussed below.

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 ArapXML project.

1b.  FUNCTIONAL DOMAINS WITHIN ACCOUNTING AND AR/AP

The five domains below provide developers with basic introduction to the jobs in finance and accounting.  The owner of a small or medium enterprise (SME) often performs all of these jobs, himself/herself.  

These functional domains are presented as human actors.  However, these are deterministic and mechanical processes coming after a decision to buy or sell.  In principle, they should be totally automated.  Humans should only participate in the initial creation of transactions.

The accounting domain, today, is fairly deep and complex.  This is an artificial condition caused by errors, ambiguous contracts, noncompliance with contracts, etc. and willful adverse behaviors. 

1b1.  Fiscal control (Controller)

The functional domain of bookkeeping and accounting within any community (company) has a single, unifying theme: 

  Assets Liabilities
The real thing tends to vanish tends to grow
The book value of the thing tends to inflate (overstate) tends to vanish (omit/understate)
Taking credit for recording the thing has many volunteers everybody avoids
Desires to record the thing anonymously nobody everybody
Authentication requirement lower higher

Real assets always try to disappear.  Real liabilities try to creep in without being detected in the accounting system, e.g. employees making unrecorded commitments in the process of acquiring resources.  Bad assets which cannot be collected always masquerade as good assets.  Sales numbers always try to creep higher without being realized as cash, and expenses always try to consume cash without getting reported as expenses.  Everybody wants to authorize and be associated with increases in Assets or sales. Everybody avoids authorizing or being associated with costs and expenses.  

In general, creditors want the monetary values higher and the quantities and quality to be smaller.  Debtors want the monetary values lower and the seller bound to terms for higher quantities and quality.  The opposition between purchasing agent and salesman is outside the scope of this discussion.  The point of this discussion is that regardless of the contract actually agreed by the parties, the motives for changing its representation in the accounting system has a similar opposition.

In the aggregate, the determination, intelligence, and will of both outsiders and employees is much smarter and more powerful than the company, unless the company is very smart indeed.  The accountant today is a fulltime job requiring a high level of concentration and method.  The types of business transactions represented in an AR/AP system have an endless diversity, and new types, actors and contracts cannot be constrained.  The accounting domain is the steward and custodian of systems of internal control, i.e. basic frameworks for approaching all risks.

Double entry accounting has been used for 500 years partly because it is accurate, i.e. the economic model of business involves exchanges with external parties which are reciprocated.  However, its byproducts are also quite useful in bookkeeping and in system design: whichever side of an exchange the bookkeeper may discover first, CDEA provides a methodology for discovering the other part of the exchange, which is usually that side which tends to vanish in the table above.  CDEA inherently reduces incentives for overstating the fun half of any transaction, by always requiring the bad side of the transaction contemporaneously.  This is one of the key motivations why accountants transform things which are not CDEA, into CDEA notation. 

Software developers will focus on solving the underlying problem of this game, while automating particular types of transactions.  The underlying requirement inside the company is a comprehensive authentication of transactions by the appropriate levels of people, before booking them (and the tools for monitoring results).  The requirement between 3rd parties is a comprehensive nonrepudiability between buyers and sellers.  Nothing focuses the mind like accountability and nonrepudiability.  When the actors are accountable, the data will suddenly get better.  The ambiguity, error and losses which today are prevented only by millions of accountants, will be prevented by responsible behavior by actors themselves.  

To the extent a transaction is truly, rigorously connected to the offsetting entry in Trading Partners' books, it requires less internal control within the enterprise.  In other words, if sales, cash, receivables and payables cannot be falsified without also manipulating the trading partners books, perpetrators of fraud will be less able to conceal either paper fraud or physical theft.  Comprehensive AR/AP integration, in principle, allow lower expenditure on systems of internal control (separation of duties) within the enterprise.

In conclusion, the game is not about XML vocabulary itself.  It is the underlying chicanery and thievery. An exhaustive treatment of all the hundreds of tricks in the accounting domains must remain outside the scope of this small document.   

1b2.  Cash control / cash flow management (Treasury)

The business which does not know its cash position will lose money as a result.  If the balance in demand deposits is too high, the company misses opportunities to carry more inventory, get better discounts, get interest income, etc.  If the balance is too low, the company incurs fees and losses of credit by issuing overdrafts.  

Knowing the cash balance immediately, is not mandatory but perfect accuracy is mandatory.  Many SMEs hold higher than necessary cash in banks because it is too expensive, in manual bookkeeping systems, to process all cash receipt and expenditure events immediately.  Avoiding overdrafts is fairly mandatory however, and accordingly, accurate bookkeeping for cash balances is mandatory.

Businesses must furthermore know the immediate future cash flows from cash sales and collections of receivables net of paying payables to make a variety of purchasing decisions.  Overly optimistic commitments by executives are the most frequent result of poor cash projections.  Cash projections include resources such as borrowings and available capital from additional equity.  Software developers must be aware that there are an unconstrained variety of "other external balances" outside the AR/AP domain, which impact on the accuracy of cash balances and cash flow projections.

Finally, developers must understand the Cash Flow Statement.  GAAP (generally accepted accounting principles) require the Cash Flow Statement in addition to the Balance Sheet and Income Statement in most countries, and it is supported in most accounting software packages, and produced by most businesses.  This report is anyways required in some form or another by Treasury and the GAAP form of the report is regarded by many as a best-practices format.  The cash flow statement is accordingly a requirement, and within the scope, of the AR/AP facility.  For further understanding, search Google for the term, cash flow statement.

1b3.  Accounts payable (Accounting)

The job of the accounts payable department is to ensure that no bill is ever overpaid, or double-paid, or paid a moment too soon or too late.  No bill should be paid for items not received or items defective.  Credits for returns and other adjustments must be communicated effectively and recovered from vendors.  No bill may be paid  unless within the "rules" established by the company, and/or authorized by the proper person within the company.  

Many companies issue purchase orders to document exactly what's being purchased; in that case the A/P department must often compare internal POs with bills from vendors. This verification is required regardless of differences in the  level of aggregation between buyer's order  and seller's invoice. 

AP departments' requirements are independent of the company's operational needs. For example, the entry of liabilities into AP may be done at time of PO, at time of receiving goods or services, or at time of receiving bills or other times. These original entries may be done by a variety of actors, using a variety of tools such as barcode scanners, or credit cards at purchasing websites, etc.

Many companies' sales staff create incomplete or ambiguous contracts with 3rd parties causing the invoices to be controversial later.  AP departments often end up coordinating the negotiations among management and counterparts in AR, in the other company to resolve payable amounts.  

Adjustments in AP often require adjustments in unit cost, sales pricing and quantities within the inventory system of the company.  Users of accounting systems have high expectations of functionality.  For example, the leading desktop software packages in the US will roll forward changes in average cost or FIFO cost of goods sold, across many layers of inventory, when the user edits a cost layer in past periods. 

Developers must understand that the environment of A/P is sometimes highly adverse, resembling a battlefield. Vendors often overbill and keep the difference.  Customers remain silent to underbillings, keeping the winnings.  The big 5 firms have found in research that most global companies retain overpayments from customers without notification.  Vendors and Customers sometimes generate low quality billing and settlement documents, which lead to a certain level of chaos in books.  Chaos is a game, which enables a ratchet effect, which 3rd parties can always win.  They keep the errors in their favor while rectifying unfavorable errors.  Chaos also enables them to delay payments while accelerating collection of receivables. 

In any case the AR and AP are always regarded as an essential source of operating cash; by paying slow and collecting aggressively, cash is generated. 

AP departments make optimal payment decisions based on vendor terms for discounts and interest. For example, some invoices offer 2% discount expiring in 10 days with 1%/month after 30 days, etc. requiring the AP department to translate to calendar due dates based on factors such as invoice date and date of receipt of goods.  

AP departments know their available cash and apply it to bills without going into overdraft. AP departments assist treasurer or controller in projecting cash requirements, to ensure cash is available at batch dates such as end of month.  If cash is short, controller borrows on lines of credit to pay some bills but not others depending on applicable interest rates. 

AP departments review and adjust the transaction taxes charged in the bills, in some companies.

AP departments spend 90% of their time in 10% of the vendors issues and problems such as recovering overpayments, rectifying the other party's billing errors or reconciliation failures, etc.  AP departments ensure an accurate and effective list accompanies their payments, because if the vendor does not understand which items are being paid, excessive time will be wasted later.  ArapXML provides unambiguous vocabulary for communicating the amounts, quantities, and items when requesting credit and debit adjustments.  A double-entry GL model provides a sequential log of all original and correction entries comprising balances.

The full scope of the AP profession is beyond the scope of this document; any serious developer of AP software will spend a few person-days reading textbooks, reviewing numerous lists such as the IMA list archives, and topical research in search engines. 

1b4.  Accounts receivable (Accounting)

The job of the accounts receivable department is almost a mirror image of AP.  The AR department ensures that no invoice is ever collected late,  or at less than 100% of its face value.  All remittances received in cash or bank should be attributed to the correct customer, and further, to the correct statement, invoice, or items being paid for.  No material short payment should be conceded.  Statements should communicate richly and timely to customers, the status of unpaid items.  No claim should be accepted from customers for items not received or items defective without review.  Credits for returns and other adjustments should be handled according to rules, usually involving approval of credits by sales or management.   A collections policy for late receivables should be implemented and followed.  Skilled AR staff sometimes collect late payments more successfully left to their own methods.  Inexperienced AR staff usually underperform in collections compared with outside agencies. 

Accounts receivable departments are the primary stewards of credit limit information of customers.  When customers reach their limit, losses result from overextending credit.  Loss of sales results if credit is needlessly denied.  It is essential in most companies that AR be kept highly current for this reason and in connection with maintaining control over cash deposits and bank balances. 

Numerous rules exist for particular companies and industries.  For example in retail, returns for defects may need to be charged back to the original supplier.  In many industries, accounts receivable are due from insurers or other intermediaries, requiring stewardship of data to support claims.  It is not unusual for AR manuals, like AP manuals, to run fifty to 100 pages or more.   

Developers of AR systems focus on ease and speed of use, in identifying the customer with which incoming remittances are connected, and the items the customer is intending to pay with the payment.   There is a natural workflow in manually receiving payments, looking up customers' accounts and then a variety of search techniques to identify items and mark them as paid.  

When AR support exogenous business systems, whether they are paper, LAN based or on the internet, the exogenous processes are regarded as adverse, sovereign operations which are accountable.  The AR clerk does not accept responsibility for collecting any exogenous accounts receivable, lightly.  It must be in apparently reasonable form to be collected, its entries sufficiently clear to enable efficient matching with incoming payments, and the credit side of the AR (such as sales, etc.) must be documented.  The AR department is usually one of the primary  points of control to ensure that amounts getting into AR are not less than the "cash register tape" or its many equivalents in exogenous sales systems.  

The basic queries and account listings required for AR are very similar to cash and payables, but AR requires a number of reports such as aging of receivables.  Aging reports display totals by customer, sometimes in loving detail, spread into multiple columns such as current month, and 30, 60, 90 and over 90 days.   Collection reports provide fullscreen information or printouts to support telephone dunning.  Again, an exhaustive treatment of AR must remain outside the scope of this small document.


1b5.  Transaction taxes (Accounting)

Transaction taxes include a wide variety of VAT, sales and excise taxes, consumption taxes, use taxes and other taxes in numerous jurisdictions.  Taxes have the following broad problem domains which are independent of each other.

This is by no means an exhaustive list; in the U.S. for example, many states provide a framework for establishing public taxing districts at local and regional levels unrelated to boundaries of cities and towns.  Thus, companies may maintain dozens of separate sales tax accounts payable, each driven by different rules implied above, usually associated with geographic boundaries.  

Most SMEs configure their software to provide choices in data entry for most rates they commonly see, and configure at least one default set of tax rates.  Most SME software has some capability to automatically select and apply different rates based on city or postal codes in addresses, or less commonly, based on setup of customer or product records.  In most cases, the user who creates sales is responsible to review the taxes they are charging customers for correctness. 

The automation of the tax reporting and payment cycle within an AR/AP or GL system is less critical than features which help users create transactions having correct tax charges.  In most jurisdictions, reporting and payment of transaction taxes is simple and infrequent enough that such accounts may be manageable within the system for trade accounts payable.


1b6.  Financial reporting (Controller)

Financial reporting includes the four financial statements required by GAAP (Income statement, balance sheet, cash flow statement and statement of equity).  It also includes the trial balance and associated transaction listings (by account and period) supporting each quantity on the trial balance.  

A trial balance is the listing of all the accounts in a GL.  This report is the foundation of the GAAP financial statements and has the following  peculiar structure. 

Income and expense accounts begin with zero each fiscal year.  Net income of prior years is summed in the equity account, usually named "retained earnings".  

Accounts within a GL facility which automates the CDEA methodology even minimally, cannot have fewer than approximately ten intrinsic types.  Assets, Liabilities, Equity, Income, and Expense, and certain items within these major types.  Minimal automation support for CDEA includes maintenance of relationships within the data itself, such as 

In addition to the logical relations above, most of today's accounting software requires the user to apply a limited choice of fixed account types  to every account at setup time.  These account types include major categories within the assets, liabilities, equity, and income statement  just because they are required to be reported separately by both taxing regimes and GAAP.  The sub-types of account types may include distinguishing current from noncurrent assets and liabilities, as well as specifically typing the accounts as cash, cash equivalents, trade receivables, investments, intercompany accounts, other assets, trade payables, other liabilities, cost of goods sold, non-operating income, and extraordinary items.

Financial reports include a number of reports not required by GAAP but which are in the nature of accountability reports or financial management reports. These include reports of return on assets, liquidity and ratio measurements, and actual, budget, and forecast reports for the entity and its line reporting units where applicable.  Many companies maintain quite a traditional regime of accountability for profitability by department, or location or other segmentation scheme associated with a management structure.  This can be an independent structure to its operational management, geopolitical country or regions etc. 

Reports not in the nature of accountability reports are typically not the responsibility of controllers, but since they require equality with the  accounting system they often come from the GL or data warehouses derived from the GL anyway.  These include a very wide variety of sales, turnover, profitability and other statistics reports, joins and cross tabulations by customer, by product, by project or activity, by salesman, region, time periods, etc.

PART 2:  USE CASES  (see next page)