Import Transactions: Difference between revisions
No edit summary |
|||
(2 intermediate revisions by the same user not shown) | |||
Line 44: | Line 44: | ||
Loading external data populates the list of imported items, using the information from the transaction source. | Loading external data populates the list of imported items, using the information from the transaction source. | ||
ContactsLaw makes the following inferences about each item: | |||
* '''Type''' - If the item credits the account, it is assumed to be a payment; otherwise, a receipt. | * '''Type''' - If the item credits the account, it is assumed to be a payment; otherwise, a receipt. | ||
Line 72: | Line 72: | ||
Any imported items which remain unlinked can then be created in ContactsLaw, once the correct transaction type has been chosen. The importer will pre-fill some of the particulars of each transaction, with the user providing the rest. | Any imported items which remain unlinked can then be created in ContactsLaw, once the correct transaction type has been chosen. The importer will pre-fill some of the particulars of each transaction, with the user providing the rest. | ||
[[Category: Accounting]] |
Latest revision as of 17:45, 22 September 2025
ContactsLaw can import transactions from an external data source, such as a CSV file from a bank.
This is typically performed on accounts that mirror those held by a bank or other financial institution. It is likely that transactions will occur on these accounts which were not initiated by the business; for example, deposits made by external parties or payments by direct debit.
In order to exclude transactions initiated by the business (and hence already recorded), the importer needs to compare the two sets, requiring the user to resolve any ambiguities.
In addition, the user must also enter any remaining particulars for each transaction (where the external data is incomplete). The importer can use these to make suggestions about future transactions.
Transaction Sources
There are no standards that govern the format in which transactions are exported from banks or other financial institutions; therefore, before you can import transactions from a new source, you need to create a transaction source that reflects your particular data.
Transaction sources have the following properties:
- Description (to differentiate from other sources)
- Format - currently only Comma Separated Values (
.csv
) is supported - Whether to use commas, tabs or fixed widths as delimiters between columns
- Whether the data includes column headings
- Whether line-breaks are permitted inside cells
Once these have been appropriately configured, you then need to identify the purpose of each column in the data source:
- Date
- Bank description - typically incorporating a unique reference number
- Cheque #
- Debit
- Credit
- Amount - where debits and credits appear in the same column
Amounts can be further processed by reversing the sign (+/-) or dividing by 100 (where figures are expressed in cents).
The importer will ignore any additional columns.
In cases where multiple transaction sources are defined for the same format, you can specify which source should be used by default.
Properties
The behaviour of the transaction importer varies according to the following properties:
- Account - The bank, credit card or escrow account into which the transactions are imported.
- Period - The start and end of the date range over which the imported transactions span.
Imported Items
Loading external data populates the list of imported items, using the information from the transaction source.
ContactsLaw makes the following inferences about each item:
- Type - If the item credits the account, it is assumed to be a payment; otherwise, a receipt.
- Payment method - If the item credits the account, it is assumed to be via Electronic Funds Transfer (EFT) - unless there is a cheque number, in which case it is by cheque; otherwise, by bank deposit.
- Reference - The longest alphanumeric sequence in the bank description.
However, the importer can draw upon historical decisions to make other inferences, provided that the item matches certain criteria.
Existing Items
The list of existing items is taken from ContactsLaw, and is equivalent to what is shown when reconciling the account.
Each item may be either an individual transaction or a transaction group.
Linking Imported Items to Existing Items
The importer will attempt to link imported items to the equivalent existing items, thus moving them from one list to the other. This is achieved by calculating a score for each pair of items and selecting the best match. If the confidence is 50% or less, the items will not be linked.
The score compares the following properties (in order of importance):
- Reference and description (most important)
- Date
- Amount (+/-)
- Type and payment method (least important)
Items can be manually linked when reviewing the results. The user can also unlink and reassign items in case of ambiguity or error.
The importer will highlight any differences between the existing and imported items; typically, these differences are resolved by updating the existing transaction/group.
Any imported items which remain unlinked can then be created in ContactsLaw, once the correct transaction type has been chosen. The importer will pre-fill some of the particulars of each transaction, with the user providing the rest.