Nominal Transactions

In an earlier post, I showed you how a dummy transaction would affect the balance of 2 Nominal Accounts and thus the totals of the Debit and Credit columns while still maintaining a balanced Nominal Ledger.

So can you now envisage how the structure for a nominal transaction may appear?

You may think to have 1 value with 2 nominal accounts so that 1 account is "Debited" with the value and the other is "Credited". That would work with our last example but check this one out. Would it work here?

You are VAT registered. The Widget sells for £10 + VAT = £11.75 (£1.75 VAT). Now we would have a "Sales Widgets" Account balance of £10 Credit, a Sales VAT Account balance of £1.75 Credit and a Bank balance of £11.75 Debit.

You now have more than 1 value to deal with and more than 2 Nominal Accounts. Some applications have dealt with this by adding another column to the transaction specifically for VAT purposes. It works, but not all transactions have a VAT element to them (cash to bank etc.). A nominal ledger will have a dedicated Nominal Account for Sales VAT so why not just treat the VAT as another part of the transaction. In other words, each transaction line consists of a date, a value, and 2 Nominal Accounts, Where more than 2 accounts are needed, the transaction simply has more lines added to deal with them.

For Example

Date    | Value | D A/c | C A/c | Notes

===================================================

1-1-09  | 10.00 | 9999  | 4000  | Sales A/c [Cr]

1-1-09  |  1.75 | 9999  | 4999  | Sales VAT [Cr]

1-1-09  | 11.75 | 1000  | 9999  | Bank Account [Db]

===================================================

Ok, so now we have dealt with all 3 Nominal Accounts by giving each its own line and using a holding dummy code (9999) to check the arithmetic before the transaction is posted (it has to balance before it can be posted in order to keep the Ledger balanced).  The [Cr] accounts add up to 11.75 and the [Db] accounts add up to 11.75 so the transaction balances! Got it?

NB: Ideally the lines belonging to each transaction would be identifiable by a transaction id on each line. Then common data such as the date can be held in a header row just once rather than on each line (normalisation kicking in :) )