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
• Payment method for receipts and payments
• 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
• Fee/surcharge 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:

• Created - The transaction has been partially recorded but has no effect on the balance of the accounts debited/credited.
• Requested - The transaction is ready to move to the next state:
  • 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.

Transactions are recorded in the Requested state unless otherwise specified.

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 is considered only half of an authority. In other words, if a transaction requires 1 authority, 2 members must co-authorise. If a transaction requires 2 authorities, 4 members must co-authorise (alternatively, 2 members can co-authorise and another member can provide full authority).
• Transactions may also require authorisation if they exceed a threshold amount.

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	Transfers the balance of each income/expense account (as at the end of financial year) to the Retained Earnings account. One transaction per financial year only.
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	Records a creditor invoice for deferred payment.
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

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. These "tax lines" are not normally shown, save for within the tax accounts themselves. The method by which they are 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 can 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).

The accounts debited/credited by the original line item determine whether sales tax is permitted, and whether the sales tax component is calculated automatically.

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

Fees/Surcharges

There are two main scenarios where transactions may include a fee/surcharge component:

• Receipts debiting a credit card merchant account (where the business does not absorb processing fees)
• Payments by credit card, to an international bank account or via escrow (e.g. PayPal, Square)

Receipts

In the case of receipts, the surcharge is calculated using the rate configured for the particular card type (Mastercard, Visa, etc) and is inclusive of the amount received. This ensures that sales tax (GST) is calculated on the surcharge¹. On debtor receipts, the surcharge reduces the amount of the transaction that can be allocated to invoices.

For debtor and trust/controlled money receipts, the surcharge is billed separately after the receipt has been processed, followed by either a debtor adjustment or trust-to-debtors transfer.

¹ Sales tax is only calculated on the surcharge if the sale is taxable.

Payments

In the case of payments, the fee is entered manually and is exclusive of the amount paid. Sales tax is not calculated on fees. If the fee is unknown when the transaction is recorded, it can be held for review; the transaction cannot be authorised/processed until the fee has been added.