|
Automated Transaction Matching™ (ATM)
At the core of our Bank Reconciliation calculations - is our matching
engine. The matching engine is responsible for matching the bank
statement with the general ledger records based on user defined
rules.
The engine is designed to match any two sets of data, whether cash
accounts, general ledger accounts, CUSIP, inventory - or even non-financial
data.
In the simplest matching rule, we match cleared checks from the
bank statement against checks issued from the general ledger data.
In the check to check matching rule we use two attributes:
· Check number
· Amount
 |
If both attributes match, we mark both records as 'matched' and
assign them a match audit trail number which links them together.
What happens if there's not a match?
Not all records will match, in fact this is to be expected.
General ledger checks issued but not yet cleared, will be flagged
as Outstanding Checks - and will remain as an outstanding check
- until they clear the bank (or are voided). Also, there may be
other items on your general ledger which remain unmatched, such
as Deposits In Transit.
In addition, there may be bank or general ledger transaction that
may require a correcting journal entry to be made - or the bank
may need to correct an error or cover a fraudulent transaction. These items will not be matched and will remain open until resolved.
Golden Rule - All unmatched items are simply rolled forward to each
subsequent accounting period until they are resolved. There are
no exceptions to this rule.
These principles apply to all the matching rules. Other matching
rules include:
In this matching rule the voided checks are matched against the
outstanding check list using the attributes:
· Check number
· Amount
Note: Both sets of data are taken from the General Ledger. This
is the only rule which does not involve bank data.
Perhaps the most popular 'non-checking' rule, this rule uses the
attributes:
· Matching Field
· Amount
The matching field is often populated with loan numbers for mortgage
and pay-day applications. Of course, the field can represent any
detailed information. In addition, the matching field can contain either numeric or alphanumeric
data.
This rule sums up transactions prior to matching. While the Matching
field is most commonly used - and illustrated below, the transactions
can be summarized by check number as well. Attributes:
· Matching Field (or Check Number)
· Amount
In addition, this rule covers One-to-Many and Many-to-One matches.
Bank Reconciliation calculations will sum the amount based on either
the matching or check number field.
Additional built-in rules include credit card matching, derivations
of matching field rules to also include site numbers, and basic
amount only for simple deposits.
Custom matching rules and scripting are available upon request.
You can 'Match' without 'Reconciling', but not vice-versa.
Many clients simply perform high speed matching without reconciling
to:
· combat fraud
· confirm deposits are made on a timely basis
· generate outstanding check lists and other unmatched lists
for inclusion in internal reports
For a detailed comparison
of Matching vs. Reconciliation
In addition to system matching, Bank Reconciliation contains a window
to manually match records. Oftentimes, this is used when a check
number's MICR line has not been read correctly by the bank and there
is no check number.
All matching rules, also known as a passes or routines, are driven
by Microsoft SQL Server Stored Procedures.
Stored procedures can run on either SQL Express or SQL Server. For
version information see Bank
Reconciliation calculation and general specifications.
Bank Reconciliation calculation rated speeds vary per rule and
based upon server load. It is safe to estimate 4,000 records matching
per minute for any rule.
| 
