Composite Transactions

When accounting was first invented, each account was a page in a book (or a set of pages) on which the accountant would record the transaction that changed the account. Each transaction became a line on the page. In DoubleEntryBookkeeping, each transaction is written on two accounts to help detect arithmetic errors and to help prevent fraud. But any bookkeeping system will sometimes require posting a transaction to several accounts. For example, a sales transaction might involve several kinds of inventory, so it would require changing several inventory accounts.

Therefore: some transactions are composite transactions, and they can be posted to many accounts simultaneously.

A sales transaction might need to be posted to both a sales system and to an inventory system, or even an accounts receivable system. Furthermore, it might involve many kinds of inventory and so need to be posted to more than one inventory system.

Most transactions in the UK will have Sales Tax associated with them which results in triple entries being made to the accounts:

Dr Sales Ledger 117.50

Cr Stock 100.00

Cr VAT 17.50

Composite transactions

I find myself moving away from composite transactions because it is difficult to maintain data integrity due to hardware and operator malfunctions, especially with distributed databases. If any of the composite postings did not complete or only partially completed it is hard to trace and correct. I developed a transaction model using a single record which contains identifying data to establish its place in the schema and force the split into composites to become individual main records. For example : An invoice is posted to the creditor ledger, to a job as a cost and to the General ledger. Instead of 3 records I only have one. The record has a creditor code, a job code and both general ledger account codes for the double entry. The system must balance as there is only a single amount field that serves all parts of the transaction. I also have logical identifiers to mark the record as a job cost, a creditor entry and a journal. This enables the job to be completed and removed from the system as the record has its job cost logical identifier removed but is still functioning as a creditor and GL transaction and still maintains a memory of the removed job via the existing job code field. Transactions constructed in this way can be modified or removed and reposted secure in the knowledge that every all effected sub accounts will also be adjusted during normal checking and balancing routines.