Elavon downloads and stores cookies on your device when you visit our website. We use these cookies to better understand and improve your browsing experience by identifying most visited pages, personalising content, and measuring site performance.

Essential cookies enable core functionality such as page navigation and access to secure areas. The website cannot function properly without these cookies; they can only be disabled by changing your browser preferences.

Performance cookies help us to improve our website by collecting and reporting information on its usage (for example, which of our pages are most frequently visited).

Cookie Settings

Elavon Financial Services DAC. Registered in Ireland – Number 418442.
Registered Office: Block F1, Cherrywood Business Park, Dublin 18, D18 W2X7, Ireland.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is regulated by the Central Bank of Ireland.
 
Elavon Financial Services DAC. Registered in Ireland with Companies Registration Office. The liability of the member is limited. United Kingdom branch registered in England and Wales under the number BR022122.
Elavon Financial Services DAC, trading as Elavon Merchant Services, is a credit institution authorised and regulated by the Central Bank of Ireland.  Authorised by the Prudential Regulation Authority.  Subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority.  Details about the extent of our regulation by the Prudential Regulation Authority are available from us on request.

Prior to settlement, merchants should reconcile transactions from the POS application to Elavon software applications. In some instances, this is either impractical or a business decision is made to deposit the transactions and reconcile later. Fusebox does not enforce reconciliation. 

If the POS application is integrated as outlined in this guide, the POS application and the software applications should be in balance. This does not guarantee that correct amounts are going to be processed against a cardholder account.

## Best practices
- Reconciliation processes should always verify that amounts processed have been deposited in the merchant account.
- Merchants are responsible for confirming the amount is correct if the settlement is automatic.  
- The following procedures must be in place to ensure that a merchant can identify and escalate issues as necessary:
  - **Identification** - Merchants must clearly identify settlement failures.
  - **Training** - Merchants are properly trained in problem identification, escalation, and resolution, especially related to settlement issues.
  - **Notification** - Settlement issues must be escalated once a problem has been identified and preliminary troubleshooting steps have been followed. 

:::::notice{important}
If reconciliation is not performed before settlement, cardholders may be exposed to errors that can result in potential customer service issues and unwanted chargebacks.
:::::


## Pre-settlement reconciliation
Prior to actual settlement, the POS application (or the merchant) verifies totals. Reports created manually through the Fusebox Batch Management User Interface (BMUI) can be compared with reports generated by the POS application during the end-of-shift or day procedures. For more information please refer to Fusebox UI user guides.

The procedures and transactions used to verify transaction totals include:
- POS application pre-settlement report.
- Fusebox pre-settlement report . 
- In an MPS implementation, Fusebox is not running on the local system; 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 under :magic-link[Fusebox API based settlement]{id="settlement-transactions"}.


## Pre-settlement report from POS application
The POS application pre-settlement report is usually printed as part of the merchant end-of-shift or day procedures to help reconcile the case drawer. The POS application commonly has reporting modules in place for payment balancing. 

POS reporting must be able to compile and display the following details:
- 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
Below is an example of the POS settlement summary report:
:::image{id="/content/dam/developer-portal-solutions/en-us/elavon/media/images/products/fusebox/POS_Settlement_Report2.png" alt="" max-width="" max-height=""}
::: 

## Detail settlement reports
Detail settlement reports data should include the following data fields:

**General data**
- Transaction Date (Field 0013)
- Amount (Field 0002)
- Reference Number (Field 0007)
- Masked Account Number (Field 1008)
- Token or Unique ID, if implemented in the POS application (Field 0003)
- The last four characters of the account number, to ensure cardholder security and privacy.
- Transaction Type (Field 0001)
- Authorization Number (Field 0006)
- Terminal ID (Field 0109)

**Settlement data**
- Settlement Date and Time (typically same as Transaction Date)
- Third Party Processor Interface or Transaction Processor Name
- Batch Transaction Count (Field 1014)
- Net Transaction Total (Field 1013)

## Corrections and adjustments prior to settlement
During your reconciliation process, it may be necessary to modify a transaction in Elavon Gateway applications or a transaction in the transaction processor batch file (if Host Capture). To change records in Elavon Gateway applications, follow the procedures outlined in the **Processing corrections and adjustments** section. Corrections can be processed from the POS application using standard Elavon Gateway API message or through the Elavon Gateway application user interface, Fusebox UI.

Your POS customer will most likely want to make corrections from the POS whenever possible. Doing so allows your cashier to correct their own mistakes and maintain a clear audit trail. Not all employees will likely be allowed to login to the Elavon Gateway applications to make adjustments. Using the terminal to reconcile ensures that the transaction is recorded correctly in the POS.

## 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. Create a pre-settlement report to verify the total number of electronic payment transactions, and the total amount expected to deposit (settle). Ensure the report contains a detailed listing of each transaction sorted by location, and within that location by payment type (Visa, MasterCard, or other type of payment):

- 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 useful to include)



Reconciliation

Alliance Offers

Data as a Service

Invitation to Apply

Accounts

Bank Holidays

Card Activation

Card Controls

Commercial Credit Cards

Credit Card Account Details

Credit Card Accounts Overview

Credit Card Alerts

Credit Card Application Status

Credit Card APRs

Credit Card Disputes - Coming Soon

Credit Card Payments

Credit Card Qualified Offers

Credit Card Statements

Credit Card Transactions

Data Sharing for Marketing Purposes

Digital Wallets

Make a Payment - Coming Soon

Rewards Accelerator

Rewards Automatic Redemption

Rewards: Balance Summary

Rewards Redemption - Coming Soon

Rewards Redemption Accounts

Rewards Redemptions

Rewards Transactions Earned and Redeemed

Travel Notifications

User Profile

3DSecure2

Avvance

CheckoutJs

Commerce SDK

Converge

Disputes Management

Dynamic Currency Conversion

eBoarding

Elavon Cloud Payments Interface

Elavon Payment Gateway

Fusebox

Hosted Payment Page

In Person Payments on Opayo

Leads

Lightbox payment modal

Online Payments on Opayo

Opayo

Opayo Direct

Opayo Forms

Opayo Reporting API

Opayo Server

Opayo Shared API

Payment Method Gateway

Payments Core 365

Simplify

viaconex

XML API

Access Online Transactions

Account Transfers

Account Validation

ACH Originations

Bank Information

Card as a Service

Card as a Service API

Check Payables

Core Banking API

Corporate Account Information

Corporate Credit Cards

Corporate Onboarding

Corporate Statements

Custody

Data Toolbox

Data Toolbox - Accounts

Data Toolbox - Documents

Data Toolbox - Transactions

Disbursements via Zelle®

U.S. Bank Flexible Capital Platform

Freight Payment Customer Profiles

Freight Payment Transactions

Instant Payments

Investment Accounting

Money Movement API

PaySmart

Payee Choice

Payee Token+

Personal Loans

Positive Pay

Push to Card

Receivables

Reference API

RTP® - Real-Time Payments

Tokenized Payments

Treasury Builder

U.S. Bank FBO Account

Virtual Account Reporting

Virtual Card Payments

Voyager Accounts

Voyager Cards

Voyager Drivers

Voyager Transactions

Voyager Vehicles

Wire Transfers

Fusebox Overview

Getting Started

Transaction Flow

API Message Format

Transaction Sequencing

Settlements

Transaction Types

Authorization Only (01)

Sale Transaction (02)

Prior-Authorized Sale (07)

Return (09)

Void Sale (11)

Batch Close (13)

Batch Create and Inquiry (14)

Void Return (17)

Transaction Inquiry (22)

Full Authorization Reversal (61)

Heartbeat (73)

Incremental Authorization (75)

Partial Authorization Reversal (76)

Concepts

Tokenization

Tokenization introduction

Tokenization API fields

Tokenization scenarios

Example transactions

Error scenarios

Retail

Retail Scenarios

Retail API Fields

Retail Examples

Lodging

Lodging Transactions

Lodging API Fields

Lodging Examples

Credential on File Transactions

Best Practices

Software Conversions

Restaurant

Restaurant Transactions

Restaurant API Fields

Restaurant Examples

Restaurant Credential on File Transactions

Restaurant Receipts

MOTO and eCommerce

eCommerce Transactions

MOTO and eCommerce API Fields

Ecommerce Examples

Direct Marketing Examples

eCommerce Credential on File Transactions

EMV Transactions

Implementation Considerations

Certification

EMV API Fields

EMV Public Cap Keys, Parameters, and Reports

Sample Files

EMV Receipts

EMV Integration Samples

API Based Settlement

Settlement Transactions

API-Based Settlement API Fields

API-Based Settlement Examples

Check Payment

Check Transactions

Check API Fields

Check Payment Examples

DCC Transactions

DCC Transaction Flows

DCC API Fields

DCC Examples

DCC Receipt Requirements

DCC Certification Process

Gift and Stored Value Cards

Gift and Stored Value Card Transactions

Gift and Stored Value Card API Fields

Gift and Stored Value Card Examples

Online Debit Transactions

Online Debit API Fields

Online Debit Examples

Private Label Cards

Private Label Transactions

Private Label API Fields

Private Label Examples

Health Savings Account Cards

HSA Support

Fusebox and Simplify HSA Card Support

HSA Card API Fields

Puerto Rico

E4 Support

API Fields

EBT Transactions

IVU Transactions