One or more sets of two general ledger account codes named in the creation of a transaction, which are debited and credited forming a balanced pairs of entries to the pairs of accounts.  Transactions requiring more than two rows are handled by creating additional pairs. Entries of 3,5,7 etc. lines are not allowed, and there is an expectation that GL pairs stand alone, logically. 

Example: 

Account		Debit	Credit
1010	Fund Balance with Treasury	1000000
1310	Accounts Receivable		1000000

These are apparently found in use almost exclusively in large governmental accounting environments.  They seem to be closely associated with software which implements "Transaction Codes".  A transaction code is an identifier for a pre-designed template of debits and credits to accomplish recurring entries in a controlled way.  Errors of course are minimized in all systems by various templates.  However, multiple sets of entries are common in governmental accounting, as entries are made simultaneously to actual accounts, and to reflect impacts on budget or commitment accounts for the same entry. 

It is reported by top federal accounting agencies that GL pairs are regarded as the most granular level of all accounting entries. While multi-line journaling is ubiquitous in private business, both ad-hoc and in templates, federal accountants regard them as amagams which could be further reduced to GL pairs. 

Today's federal systems reportedly use GL pairs universally. All GL entries consist of two and only two entries. In other words, CDEA (classic double entry accounting) of course requires GL entries of more than 2 rows at times, but federal accounting systems decompose those to sets of 1 or more GL pairs.

Any GL schema adopted by US government would reportedly be required to support GL pairs. It appears that GL pairs are not incompatible with existing GL schemas, or even software, in the marketplace, but are only a special constraint. They seem to be a special case of ordinary, multi-line CDEA methodology.

Collections of transactions (transaction sets) Transaction (Amount, date, documentation, etc.) DR Account code CR Account code Transaction (Amount, date, documentation, etc.) DR Account code CR Account code DR Account code CR Account code DR Account code CR Account code

The devils advocate will ask, are GL pairs representative of the real world, or are they a constraint adopted to reach other goals such as processing efficiency? 

One might speculate that historically, GL pairs were found to perform better on past hardware and software systems, with large numbers of transactions by large numbers of simultaneous users?? Considering the circumstances, any improvement, even on the order of 20%, in performance could have lead to both cost savings and improved productivity. And you save money because theres only one numeric amount on disk, supporting two account entries.

One might speculate the use of GL pairs is really pursuant to internal control or behavioral goals, reducing the open ended variety of accounting entries that might otherwise occur. 

Another reason one might imagine for GL pairs architecture is the capability to produce various cash flow or funds flow statements. It requires a lot more processing logic to create the cash flow statement from a ledger containing many different multiline journal entries, than one in which every entry to cash or cash equivalents is exactly matched with one and only one offsetting account.

It is not immediately clear that it is proper to decompose all multiline entries into GL pairs. For example, 3-line entries are ubiquitous in business. 

Account		Debit	Credit
12000	Accounts Receivable	108
40100	Sales		100
22400	Sales Tax Payable to State		8

In the above example, you could obviously break the Receivable into two entries of 100 and 8, within a GL pair system.   But there are plenty of cases where such breakdown would be rather artificial.  For example what if my customer didn't give me his debt but a pickup truck.  What if a farmer trades his cow for a pig and a goat?  Does he then say, I gave 1/3 of my cow for the goat?   Or consider a closing statement on a house, which has many items of consideration in both columns. 

A brief comparison of GL Schemas is found at http://www.arapxml.net/research.htm  Additional draft GL schemas are  found at http://www.xbrl.org/gl.htm and http://www.arapxml.net/specification.htm