At the core of our Bank Reconciliation software - 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:
Void-to-Issue
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.
Prefer your own matching criteria? Not a problem with BankRec's User Defined Matching Rule.
For journal entries, adjustments and other items that may not have been foreseen - easily match items.
Depending on your data requirements - Bank Rec provides advanced support for transaction and site classification. Similar to Microsoft Outlook-style Rules, Bank Rec rules examine test/examine each item - and then takes an action.