Automated Transaction Matching Process

 

The Automated Transaction Matching (ATM) Process is one of the core modules of the Bank Reconciliation.com product line.  The ATM consists of a series of processes/routines which match your transactions.  The basic routines are discussed below.

In addition, your company may have requested custom routines to help increase your automated match percentage when a situation/environment is unique.  This would be indicated by your custom code number ('File', 'Options', 'General', 'Custom Code' tab) and related documentation.

All routines can be activated/deactivated and their related triggers can be set from the main menu at 'File', 'Options', 'General', 'Match' tab.

Notes:
--Unmatched Records are automatically 'rolled forward' to subsequent periods until matched.
--Records can be matched within or across periods.
--The matching routines below apply to unmatched records.

 

Matching Routines
1. Check to Check
- Attempts to match each cleared check from the bank with an issued check from the General Ledger.  For a match to be successful, both records must have the same check number and amount.

Note: The sign of the amounts must both be the same, in that they must indicate a reduction of funds.  For example, a cleared check from the bank would not match with a voided check with the same check number and amount.

Upon a successful match, each record in the match will receive a 'match' audit trail number.  This enables users to quickly identify all records involved in a match.

Unsuccessful matches - Our software is unique in that it does not simply provide lists of matched and unmatched records, but it provides a reason as to why the records did not match.  This:
--saves your staff time
--enables them to rank the records according to their risk/exposure

If a cleared check on the bank side does not have a corresponding G/L issuance, the bank record is marked with the exception code 'Check Cleared bank, no G/L record (#310).

If a cleared check on the bank side has already matched against the G/L (regardless of the amount), it is considered a duplicate clearing check, 'Check cleared more than once' (#115).

If a cleared check on the bank side has a corresponding G/L issuance, but the amounts differ, the bank record is marked with the exception code 'Bank amount differs from G/L amount' (#110), and the G/L is marked 'G/L amount differs from Bank amount' (#210).

All remaining G/L issued checks are marked as Outstanding Checks (#498).  

Notes:
--Outstanding checks may be matched during the following Void to Issuance matching routine.
--All unsuccessful matches, with the exception of outstanding checks, are considered to be high risk exceptions.



2. Void Check to Issue Check
- Attempts to match each voided check on the General Ledger to a previously issued check on the General Ledger.  It does not involve any bank data.

For a match to be successful, both records must have the same check number, and equal but offsetting amounts (opposite signs).

Upon a successful match, each record in the match will receive a 'match' audit trail number.

Unsuccessful matches:
If a Voided check does not have a corresponding Issuance, the voided record is marked with the exception code 'Voided check, no record of issuance' (#410).

If a Voided check has a corresponding Issuance, but the Issuance record has already been matched (either to a cleared check or a previously voided check), the Voided record is marked with the exception code 'Voided check duplicate' (#415).

If a Voided check has a corresponding Issuance, but the amounts differ, the records are marked with the exception code 'Amount on issued check differs from amount voided (#420/425).

All unsuccessful void to issuance matches are considered to be high risk exceptions.
 

3. Deposit and non-check withdrawals matching (excluding credit cards) -
Attempts to match transactions from the Bank with a similar transaction from the General Ledger.  For a match to be successful, both records must have the same amount, site number, and within the stated date range.

Transactions are grouped on the Bank and G/L by site.  If site is not used, all sites are grouped into the default site group (0).  The following steps all relate to transactions in the same site (default or otherwise).

For each Bank record, the system looks for an equal amount on the G/L side.  It then qualifies the record(s) by examining the business days (weekdays) between the two dates. The date range can be can be set at 'Options', 'Matching' tab, 'Earliest # of days Match' and 'Latest # of days Match'.

If multiple Bank transactions satisfy multiple G/L transactions, both sides are matched sequentially in ascending date order.

Note:
--Without a unique transaction identifier (such as a check number), there is the possibility of a 'False' positive match - one in which the system matches records, which is not necessarily true.  
--All matching rules can be activated/deactivated from the 'Options' window, 'Matching' tab.
--Records can be unmatched when viewed in a record listing.


Example of False Positives: Two deposits are made on the same day, one in the morning, one in the afternoon, each for $100.  The bank clears one deposit (made in the morning) the next day, while the afternoon deposit clears two days later.  The Bank Reconciliation.com system may cross match the deposits, as the G/L deposit date was the same.

However, if the bank deposits were on sequential days the system would not cross match the records as the system would work with records in an ascending date order on both sets of data.

Upon a successful match, each record in the match will receive a 'match' audit trail number.  

Unmatched Bank records are categorized as either 'unrecorded bank deposits' (#335) or 'unrecorded bank withdrawals' (#340).

Unmatched G/L records which reduce the account balance are simply categorized as 'G/L reduced, no bank entry' (#230).

Unmatched G/L records which increase the account balance are categorized either as a 'Deposits in Transit (DIT)' (#240) or a 'Missing Deposit' (#220) - based on the number of days set in the 'Options', 'Match' tab.

 

4. Alphanumeric Matching (deposits and other non-checks)
One method to eliminate the possibility of False Positives with deposits, is to use a unique reference code with each transaction.  This reference code is mapped to our 'Matching Field', and can be up to 255 characters (alphanumeric).

In Alphanumeric Matching, the system attempts to match each non-check transaction on the Bank to a similar record on the General Ledger.  

For a match to be successful, both records must have the same reference code and contain equal amounts.  Both amounts can be either positive or negative.  In addition, the records may not contain a check number, and the reference field should be at least one character long.  

Records with a check number will not be matched by this routine (by design).  They will be automatically matched with the Check to Check and Void to Issue routines.

Records without an entry in the reference field will not be matched by this routine (by design).  They will be automatically matched, if you choose, by utilizing the preceding the matching routine (Routine #3).

Upon a successful match, each record in the match will receive a 'match' audit trail number.


When matching on alphanumeric text to alphanumeric text (in previous versions referred to as 'Text1' matching), set the following option switches ('File', 'General', 'Options', 'Match' tab):
--Match: Alphanumeric Matching Field - ON
--Match: Non-Checks - OFF

When importing your Bank and G/L files, make sure that you have mapped a field as 'Matching Field' (this is an update from mapping as 'Text1').
 

Why turn 'Off' non-Check matching?
If left on, this would circumvent your efforts to match based on Matching Field.  Non-check matching does not use this field.


5. Many to Many Matching

In addition to one to one matching, we offer a one to many, many to one and many to many (for brevity - 'many to many') matching process for both the Check Number and Match fields.

Check Number:
The system will group and compute a subtotal for unmatched Bank records based on Check Number.  It will then perform the same process on unmatched G/L records.  If there is a match with Check Number and subtotal amounts, each individual record with that Check Number, on both the Bank and G/L data sets, will be marked as matched (with audit trail, etc...).

Records without check numbers (or zero) will not be processed by this routine, by design.

Match Field:
The process is identical to the check number above, with the exception that it is based on the 'Match Field' rather than 'Check_Number'.

Records without an entry in the 'Match Field' will not be processed by this routine, by design (if based on Matching Field).

When importing your Bank and G/L files, make sure that you have mapped a field as 'Matching Field' - this is an update from mapping as 'Text1'  (if based on Matching Field).


When matching on alphanumeric text to alphanumeric text (in previous versions referred to as 'Text1' matching), set the following option switches ('File', 'General', 'Options', 'Match' tab):
--Match: Alphanumeric Matching Field - ON
--Match: Non-Checks - OFF
--Match: Many to Many - Based on Matching Field, OR
--Match: Many to Many - Based on Check Number


Why turn 'Off' non-Check matching?

If left on, this would circumvent your efforts to match based on Matching Field.  Non-check matching does not use this field.



Notes:
--Each matching rule can be individually activated/deactivated.
--The matching rules have been presented in an order to ease a narrative presentation.  In the system, the routine for Alphanumeric Matching (#4 and #5) with reference code, are run prior to the simple routine for non-checks (#3).  All other routines are in their system sequence.
--These are the basic matching routines included with all versions of Bank Reconciliation.com.  
--Credit card routines are available with an optional license.
--Additional routines can be provided using custom codes.
 

Knowledge Base Article: KB2250
Treasury Software Corp. 1999 - 2005.  All rights reserved.
Can't find what you need? Contact us