Credit Card Reconciliation

A. Typical '2-way'
In a 'typically' scenario - only two sets of data are used in the Automated Transaction Matching process - your internal records and the bank's record. This can be used when batches are recorded in your internal records, and the bank data is in a similar fashion.

For an overview of Credit card reconciliations, and specifically for those between internal data and bank data, see 'Credit Card Rec'.

B. Internal -> Credit Card Processor -> Bank Matching Process
However, there may be times when your internal records are kept in a detail/transactional manner, and a match is needed to the bank's batch amounts.

This matching can be achieved using either a:
--programming routine, or
--lookup table

Programming Routine
This involves consolidating internal detail records and attempting a match against the bank's summary record. If successful, each detail record, along with the bank record, are marked with the unique audit trail number. If unsuccessful, a secondary (or tertiary) matching routine can be applied to attempt a match. Otherwise, the records remain unmatched and can be manually acted upon or followed up in one of our standard reports.

An example of when a programming routine would be indicated - all credit card deposits for the day are batched and sent to the processor in one batch. This batch is processed and sent to the bank for deposit. Any fees, commissions, or charge backs would be processed separately and not effect the batch total.

Our programming logic would summarize the detailed records by calendar date for the match against the bank records.

Lookup table
Sometimes life is not so simple, in that calendar date cut-offs are not available - or followed - on a regular basis. When the relationship between the detailed transactional records and their corresponding bank summary record can not be programmatically defined (either through logic or consistency), a lookup table will be used.

This lookup - or 'index' table will be used as a reference by the program to help identify the relationship between the two sets of data. In addition, the table can be used to help identify differences between the sets of data and generate an adjusting entry on the internal record set.

Example:
Twenty credit card transactions were received at a retail location for a total of $1,500.00. Upon closing for the night ('Z' ing the register), this detailed information was transmitted by that location to their credit card processor. The credit card processor rejected one of the transactions for $300, and sent the remaining $1,200 for payment to the bank. The bank records reflect a $1,200.00 deposit.

Using a lookup table, Bank Reconciliation would identify the $300 rejection at the processor and would generate a detailed entry on the internal books for -$300. Depending on the default settings chosen by the retailer, this exception can be flagged for further validation/verification, or processed and marked as matched, and of course available for management review on an exception report.

Technical detail from above:
The system actually creates two equal and offsetting entries, one for $300, and one for -$300. The match would consist of the following records:
Internal $1,500.00
Internal -$300.00 (system created)
Bank $1,200
The remaining $300 system created entry would remain open as an unreconciled entry, available as a source for journal entry back into your accounting system (note - this entry can also be suppressed as above).

Of course, the same logic above applies to fees, chargebacks, and any other adjustments.

Regardless as to whether your application necessitates a programmatic approach or lookup table approach, these are custom applications - and these routines would be in addition to the off shelf version available on the Internet.

Need more information? Give us a call: 866-226-5732.