Transaction

A transaction is the basic unit of the accounting functionality of ContactsLaw. It mirrors its namesake in traditional double-entry accounting, showing the accounts debited and credited by a particular amount, on a particular date, for some purpose.

A single transaction may affect the balance on multiple accounts (quantity not limited); alternatively, it may have no effect and simply re-allocate funds between ledgers on a single account.

Properties

Transactions have the following properties:

• Date shown on ledgers (additional dates may apply to some types of transactions)
• Code consisting of a unique, sequential number and a suffix indicating the type of transaction
• Receipt number, payment number or journal entry number for trust transactions
• Related contacts (e.g. the payee)
• Related documents (e.g. a trust authority)
• Reference for reconciliation purposes
• Group if part of a batch deposit or electronic funds transfer
• One or more line items

Each line item has the following properties:

• Account (and, optionally, ledger) debited
• Account (and, optionally, ledger) credited
• Description or purpose
• Amount
• Sales tax (GST) component, if applicable

Note: Some transaction types require all line items to debit/credit the same account (and/or ledger).

Dates

Transactions may have different dates depending on their type:

• Transaction date - This is the date when the accounts are debited/credited by the transaction, and hence when balances change. When processing or reconciling the transaction, this date may change as more accurate information becomes available.
• Entry date (aka issued date, payment date or journal transfer date) - This is the date when a receipt number, payment number or journal entry number is assigned to a trust transaction. This date cannot be changed once the transaction has been authorised. This is the date shown on most trust reports.
• Received date - Applies to receipts only. This is the date that the funds were received, if different to the transaction date.
• Cheque date - Applies to payments by cheque only. This is the date written on the cheque, if different to the transaction date.

States

Transactions can exist in the following states:

• Requested - The transaction has been recorded but has no effect on the balance of the accounts debited/credited.
  • Pending authorisation - The transaction requires authorisation (controlled by settings) before it can move to the next state.
  • Pending processing - The transaction has been authorised (or does not require authorisation) and can move to the next state.
• Processed - The transaction now affects the account balances and can be reconciled.
• Cancelled - The original transaction has been cancelled by recording an equal and opposite transaction on the date of cancellation.

Authorisation Criteria

It is possible to customise the authorisation criteria for each type of transaction (per-business):

• By default, transactions do not require authorisation (with some exceptions, in order to enforce Legal Profession Regulations).
• In the most common scenario, transactions require a member with the Authorise permission to give authority. This can be done on a per-transaction basis or in bulk. Less commonly, transactions may require multiple authorisations.
• An authority given by a member with the Co-authorise permission must be matched by an authority from another member. For example, if a transaction normally requires 1 authority, it will now require 2. If it normally requires 2 authorities, it will now require at least 3 (4 if all members co-authorise).
• Transactions may also require authorisation if they exceed a threshold amount.

Sales Tax (GST) Handling

In situations where a transaction increases or decreases the sales tax liability for the business (or anticipates this will occur), ContactsLaw provides functionality to handle the additional accounting required. Examples of such transactions include finalising invoices, receiving payments for services and recording business purchases.

Note: Trust/CMA transaction types do not handle sales tax.

If recorded explicitly, an additional line item would be needed to debit/credit the sales tax component to a liability account (either Sales Tax or Provision for Sales Tax). This amount would be deducted from the original line item (net amount), such that the total debit/credit (gross amount) stays the same.

While sales tax can be recorded manually, ContactsLaw discourages this and instead offers to record the additional line item(s) automatically. The method by which this is handled depends on the type of transaction, as well as whether the business uses cash or accrual accounting¹. For non-specific transaction types - or in exceptional circumstances - the user must choose from the following options:

Method	Debit	Credit	Typical Use
Deduct from total, credit provision	Gross amount (to original account)	Net amount (to original account) Tax component to Provision for Sales Tax	Finalising invoices (cash accounting).
Deduct from total, credit liability	Gross amount (to original account)	Net amount (to original account) Tax component to Sales Tax	Non-debtor receipts.
Deduct from total, debit provision	Net amount (to original account) Tax component to Provision for Sales Tax	Gross amount (to original account)	Creditor invoices (cash accounting).
Deduct from total, debit liability	Net amount (to original account) Tax component to Sales Tax	Gross amount (to original account)	Non-creditor payments.
Debit provision, credit liability	Gross amount (to original account) Tax component to Provision for Sales Tax	Gross amount (to original account) Tax component to Sales Tax	Debtor receipts (cash accounting).
Credit provision, debit liability	Gross amount (to original account) Tax component to Sales Tax	Gross amount (to original account) Tax component to Provision for Sales Tax	Creditor payments (cash accounting).

¹ ContactsLaw always uses accrual accounting for income/expense purposes. For sales tax purposes, you can configure cash or accrual accounting via settings.

Transaction Types

Suffix	Type	Remarks
GNR	General Receipt
GNP	General Payment
GNJ	General Journal
GNT	Business-to-Business Transfer	One of a pair of transactions that records a payment from one business to another (by Electronic Funds Transfer).
MEJ	Credit Card Merchant Journal	Records a lump-sum deposit from a credit card merchant, optionally including fees.
ROJ	End-Of-Year Rollover Journal
DRR	Debtor Receipt
DRJ	Debtor Invoice Journal	Recorded by the system when an invoice is finalised.
DRP	Debtor Refund Payment
DRT	Trust-to-Debtors Transfer	One of a pair of transactions that records a payment from a trust bank account to a general bank account (by Electronic Funds Transfer), for the purpose of paying invoices.
DRA	Debtor Adjustment	Adjusts the balance of the debtors ledger (for a one or more matters) up/down, optionally adjusting allocations.
DRW	Bad Debt Write-Off
DSP	Cash Disbursement Payment	Records a disbursement (affecting one or more matters) incurred on a cash basis.
DSJ	Non-Cash Disbursement Journal	Records a disbursement (affecting one or more matters) incurred on a non-cash basis, e.g. to a creditor or liability account.
DSW	Disbursement Write-Off
CRJ	Creditor Invoice Journal
CRP	Creditor Payment
CRW	Creditor Write-Off
CRA	Creditor Adjustment	Adjusts the balance of the creditors ledger (for one or more contacts) up/down, optionally adjusting allocations.
TRR	Trust Receipt
TRP	Trust Payment
TRJ	Trust Journal
TRT	Trust/CMA Transfer	One of a pair of transactions that records a payment from one trust bank account to another (by Electronic Funds Transfer).
CMR	Controlled Money Receipt
CMP	Controlled Money Payment