Reconciliation

Batches must be settled, closed, or deposited to the appropriate TPPs to receive funding on the transactions generated during the day. It is recommended that the merchant reconcile transactions from the POS application to the Elavon software applications prior to performing settlement. In some instances, this is either impractical or a business decision is made to deposit the transactions and reconcile later.

Elavon Gateway cannot enforce reconciliation. When the POS application is integrated, as outlined in this guide, the POS application and the Elavon software applications should be in balance. However, being in balance does not guarantee that correct amounts are going to be processed against a cardholder account.

Reconciliation should always include:

  • Verify amounts processed have been deposited in the merchant account.
  • Merchant is responsible for confirming the amount is correct if the settlement is automatic.

Elavon Gateway requires that its clients have the necessary procedures in place to ensure that a merchant can identify and escalate the following items:

Identification

Merchants can clearly identify settlement failures.

Training

Merchants are properly trained in areas of problem identification, escalation, and resolution, especially related to settlement issues.

Notification

Escalate settlement issues after a problem has been identified and preliminary troubleshooting. If reconciliation is not performed before settlement, the cardholder may be exposed to errors that can result in potential guest service issues and chargebacks.

Pre-Settlement Reconciliation

Prior to actual settlement, the POS application (or the merchant) verifies totals. Compare reports from the Elavon Gateway applications with reports generated by the POS application during the end-of-shift or day procedures.

The procedures and transactions used to verify transaction totals include:

  • POS application Pre-settlement report
  • Elavon Gateay applications Pre-settlement report
  • In an MPS implementation, Fusebox is not running on the local system, and reports and export files are not immediately available
  • Consult with your Elavon Gateway Integration Analyst on how to integrate API Based Settlement and reconciliation functions. More information is available in the Fusebox API Based Settlement section .

Pre-Settlement Report from the POS Application

The POS application pre-settlement report is usually printed as part of the merchant end-of-shift or day procedures to hrelp reconcile the case drawer. The POS application most likely has reporting modules in place for payment balancing. Ensure at least one report is available to display and print:

  • Total number of transactions by tender type
  • Total dollar amount for each payment (cash, checks, gift certificates, credit cards, or other form)
  • Total number of transactions
  • Grand total
  • Sub-total by tender type (optional, but good to include)

The merchant must also be able to generate a pre-settlement report from the POS application to verify the total number of electronic payment transactions, and the total amount they expect to deposit (settle). Ensure the report contains a detailed listing of each transaction sorted by location, and within the location by payment type (Visa, MasterCard, or other type of payment).

POS Settlement Summary Report Example

The table below is an example of the POS Settlement Summary Report.

Term ID Payment Type Date Ref. # Auth. # Acct. # Sales Returns Totals
TERM1 VI 04/15/02 100123 432093 0001 123.45
VI 04/15/02 100156 719284 8881 400.01
VI Total 523.46
AX 04/15/02 200432 204891 9635 300.00
AX Total 300.00
TERM1 Total 823.46
TERM 2 MC 04/15/02 100654 943104 3201 678.00

Detail Settlement Reports

Detail Settlement Reports data should include:

General Data

  • Transaction Date.
  • Amount.
  • Reference Number (Field 7).
  • Masked Account Number (Field 1008).
  • Token or Unique ID, if implemented in the POS application (Field 3).
  • Print only the last four characters of the account number to ensure cardholder security and privacy.
  • Transaction Type (i.e. Sale, Return).
  • Authorization Number (Field 6).
  • Terminal ID (Field 109).

Settlement Data

  • Settlement Date and Time
  • Third Party Processor Interface or Transaction Processor Name
  • Batch Transaction Count
  • Net Transaction Total

Modifying Transactions Prior to Settlement - Corrections

During your reconciliation process, it may be necessary to change a transaction in the Elavon Gateway applications or a transaction in the transaction processor batch file (if Host Capture).

To change records in the Elavon Gateway applications, follow the procedures outlined in the Processing Corrections and Adjustments section. Corrections can be processed from the POS application using our standard Elavon Gateway Message or through one of the Elavon Gateway application user interfaces.

Your POS customer will most likely want to make corrections from the POS whenever possible. Doing so allows the cashier to correct their own mistakes (not everyone will likely be allowed to login to the Elavon Gateway applications). It also ensures that revenue is reported correctly in the POS application.

POS Application Pre-Settlement Report

The POS application pre-settlement report is usually printed as part of the merchant end-of-shift or day procedures to help reconcile the cash drawer. The POS application most likely has reporting modules in place for payment balancing. Ensure at least one report is available to display and print:

  • Total number of transactions by tender type
  • Total dollar amount for each payment (cash, checks, gift certificates, credit cards, or other form)
  • Total number of transactions
  • Grand total
  • Sub-total by tender type (optional, but good to include)

The merchant must also be able to generate a pre-settlement report from the POS application to verify the total number of electronic payment transactions, and the total amount they expect to deposit (settle). Ensure the report contains a detailed listing of each transaction sorted by location, and within the location by payment type (Visa, MasterCard, or other type of payment).