Introduction

The purpose of this guide is to explain the concept of reconciliation, its peculiarities and how it can be handled and facilitated within the gateway.

Intended Audience

This guide will be useful for the PSPs that want to deepen their understanding of reconciliation specifics around processing and remittance in order to organize the reconciliation process in the optimal and effective way.

Overview

Transaction processing involves two key processes - processing and remittance. These processes involve several participants - a software platform, gateway, processor and bank. To register the movement of funds, each system keeps a record of transactions. To confirm the consistency of the transaction data between the two systems, which are technically connected and contain the same information (transactions of various type, statements, deposits, etc.), reconciliation is necessary. Ideally, during the reconciliation process, the data should match in both systems. But sometimes there may be a discrepancy. The reason for a discrepancy in the records can be identified by reconciling the reports between two systems.

Reconciliation - a process that involves comparison of the record across two systems of records. The purpose of this process is to confirm the consistency of the data between the systems that are technically connected and contain the same information (transactions of various types, statements, deposits, etc.). For example, the data can be reconciled between the gateway and a processor or a PSP’s accounting system and bank statement information. Typically, reconciliation is carried out on monthly basis, but there may be required a daily or quarterly reconciliation.

The reconciliation process is organized around two basic processes - processing and remittance.

Processing reconciliation - a process that allows for identifying a discrepancy in the data on the processed transaction amount and volume across the systems of a processor and the gateway. To do this type of reconciliation, settlement/deposit reports provided by the processor on one side and by the gateway on the other side are used.

Remittance reconciliation - a process that allows for understanding how funds received by a PSP on behalf of a merchant are distributed. To do this type of reconciliation, information from the bank statements provided by the accounting system on one side and the merchant statements provided by the gateway on the other side are used. With the help of this reconciliation process, one can understand what has happened with the funds after transaction processing is done. Much of the money goes to the merchant, but some part can be temporarily (in the form of reserves) or permanently (in the form of fee payments) withheld by the PSP.

Cross-reference - a process that allows for reconciling the data on the amount and volume of the processed transactions between the software platform and the gateway. To do this type of reconciliation, transaction processing reports are used. With the help of this reconciliation, a software platform can reconcile whether the transactions of a particular merchant are present in both its and the gateway’s systems.

Reconciliation reports - the dashboards that allow for reconciling the records and identify a discrepancy, if any exists, as a result of transaction processing, remittance, cross-reference; the reports are available as dashboards on the user interface and as reports in CSV format.

Processing reconciliation reports

To analyze information across all available processors within the gateway, Processing Reconciliation Dashboard is used. Processing Reconciliation Dashboard - а dashboard that allows for analyzing processing volume between a PSP and all processors across the portfolio.

To perform processing reconciliation, the Processor Reconciliation Dashboard is used within the gateway. Processor Reconciliation Dashboard - a dashboard that allows for reconciling the volume of the transactions processed over a month between a PSP and a particular processor.

For the data on the transactions processed by a processor to be shown on the processor reconciliation dashboard, the data has to be imported into the system. To allow for this, reports from the processor in a delimited format (for example, CSV) are needed and reconciliation integration must be implemented between the gateway and a respective processor. The reconciliation integration is used to import the data automatically from the processor into the gateway and subsequently integrated into the dashboard. 

To facilitate the analysis and reconciliation, there are additional dashboards, such as Transaction Summary by Account, Transaction Summary by Payment Type and Transaction Detail. To access these dashboards, drills are used. Let’s review the diagram below representing how to drill through to each dashboard:
Transaction Summary by Account - a dashboard that groups information on the transactions by a particular account over a certain period of time (usually a day).

Transaction Amount by Payment Type - a dashboard that groups information on the transactions for a particular account by payment type (Visa, MC, etc.) over a certain period of time (usually a day).

In case there is a need to get detailed information on a particular transaction, the dashboards (Transaction amount by payment type and Transaction summary by account) allow for drilling through to a Transaction detail dashboard.

Transaction Detail Dashboard - a dashboard displaying a list of transactions grouped by certain criteria, for example, by account number, transaction amount, status, etc. As a rule, this dashboard is used to drill through a particular processing total to show the transactions it is comprised of.

If a software platform needs to do processing reconciliation automatically, it can use the transaction detail dashboard, described above. To allow for this, a software platform can download this report and reconcile the number and amounts between its system and the gateway’s system using cross-reference fields, for example, transactionCode - an identifier assigned by the software platform itself.

Processing Reconciliation Dashboard

Processing Reconciliation Dashboard - a dashboard that shows aggregated information across all the processors for the transactions processed over a month and allows for reconciling the records between a PSP and a processor.
 
The dashboard shows the data of the transactions processed over a month. On this basis, the accounting records are reconciled between the processor and the gateway. Typically, reconciliation is done on a quarterly basis. The dashboard shows the records accumulated over a month that are balanced and recorded at the beginning of the next month.
 
The dashboard contains the following columns:
Date - the day when transactions were settled by a processor. Gateway - the total amount of the transactions processed over a day at the gateway’s side. Processor - the total amount of the transactions processed over a day at the processor’s side.  
The dashboard contains the following totals:
Balance In - an opening balance for a given month, calculated for a processor and the gateway for the processed transactions. Balance Out - a closing balance for a given month, calculated for a processor and the gateway for the processed transactions.
If there is a need to reconcile the records associated with a particular processor, there is a possibility to drill through to the Processor Reconciliation dashboard to analyze where a discrepancy comes from.

Processor Reconciliation Dashboard

Processor Reconciliation Dashboard allows for analyzing the records on the processed transactions at the level of a particular processor. The records provided by the processor are reconciled in detail against the records within the gateway. Considering that reconciliation is done on a monthly or quarterly basis for accounting purposes, any difference accumulated over a month is balanced and recorded at the beginning of the next month.

The purpose of the dashboard is to identify any discrepancy between the records on the processed transactions provided by the processor and the records provided by the gateway.

Processing Problems Affecting Reconciliation

There are certain problems that can cause a discrepancy in the processor reconciliation dashboard:

1. A discrepancy caused by a settlement cut-off issue If a processor uses host capture, settlement is done automatically at a certain time. The time when settlement occurs is called settlement cut-off. All transactions that have been authorized before settlement cut-off are done at the processor’s side, should be settled on the current day and funded the following day. If the transactions have been settled after settlement cut-off occurred on the processor’s side, there will be a one-day funding delay. Within the gateway, the settlement cut-off mechanism works the same and runs in parallel with the processor and, as a rule, at the same time with the processor or with a small time difference. But, sometimes, settlement on the processor’s side occurs a few minutes earlier or later than the time the gateway states as the end of the day. This can result from several reasons: (a) human error, (b) incorrect system time due to a system error, (c) incorrect settlement execution due to incorrect communication settings, communication problems with the firewall or incorrect configuration of a real-time processor’s profile. Thus, if transactions are submitted during this time interval, there is a possibility that transactions will be settled on the current day in the gateway, but within the processor’s system they will be settled the next day, or vice versa. If this is the case, there may be a discrepancy in total amounts of the transactions processed over a certain day. To understand how the three problems mentioned above affect the settlement cut-off, let’s review three examples below:
 
a. Human error A processor and a merchant are located in different time zones. The time difference is one hour. Settlement cut-off on the processor’s side occurs at 10 pm. To make it by the settlement cut-off time of the processor, the merchant has to submit transactions for subsequent processing by 9 pm, which corresponds to 10 pm in the time zone of the processor. But the merchant mistakenly submits transactions for processing at 10 pm local time. Transactions are submitted for processing after settlement on the processor’s side is done. Thus, during reconciliation, there will be a discrepancy in the total amount of the processed transactions. The transactions submitted after settlement will be settled the next day.
 
b. Incorrect system time Settlement cut-off on the processor’s side is done at 10 pm. Due to a technical problem, a timing failure may happen within the gateway’s system. As a result of this failure, 5 minutes time difference was created. Thus, the gateway submits transactions for processing at 10 pm and settlement on the processor’s side occurs at 10 pm. But, at 10 pm on the gateway’s side it is actually 10:05 pm on the processor’s side. So, when the gateway submitted transactions for processing, settlement on the processor’s side had occurred 5 minutes earlier.
 
c. Settlement is done incorrectly A settlement file containing real-time transactions performed by merchants during the day is submitted to the processor. In the gateway, these transactions are processed on the current day. But the processor rejects the file from processing due to an incorrectly specified MID in the processor’s profile settings. The PSP corrects the mistake in the profile, regenerates the file and resubmits it to the processor. But the file is actually submitted after settlement is done on the processor’s side. For that reason, the file is processed the next day. Thus, during reconciliation, there is a discrepancy in the total amounts of the processed transactions because the dates within the processor's system differ from the dates within the gateway’s system. 
 
2. Technical problems around direct debit returns/chargebacks The problems around direct debit returns or chargebacks may occur on both sides - the processor’s and the gateway’s.
If problems around direct debit returns/chargeback processing occur on the processor’s side, this may cause a discrepancy in the processing totals for a day. For example, a processor has generated files, but its FTP server does not work. As a result, the gateway is not able to download the files in time. For that reason, transactional data gets to the system later than the day they actually get downloaded. Consequently, the dates of the transactions in the reports, which are based on the financial statistics within the processor’s system, differ from the dates of the same transactions within the gateway’s system. Thus, the processor considers that the transactions have already been processed and shows this in its reports for the previous day. But the gateway has not received the data on these transactions yet. The data will be received later, as soon as there is a connection with the processor’s FTP.
 
If the problems around direct debit returns/chargeback processing occur on the gateway’s side, this may cause a discrepancy in the processing totals for a day. For example, a processor has generated the files and the gateway has downloaded them from the processor’s FTP but has not imported them due to a bug within the system. For that reason, transaction data is not displayed in the reports, which are based on the financial statistics. As a result, the dates of the transactions within the processor’s system differ from the dates of the same transactions within the gateway’s system. Thus, the processor shows in its reports that direct debit returns/chargebacks were processed on the previous day. But, there will not be any records of these transactions in the report of the gateway.
 
3. Technical problems around sales If there are any technical problems with processing of real-time transactions on the processor’s side, this may cause a discrepancy in the totals of the transactions processed for a day. For example, the gateway uploads settlement files to the FTP server. This means that the transactions have been processed on the gateway’s side. But these transactions may not be processed on the processor’s side due to technical problems. Thus, a discrepancy for the day when the problems occurred may be identified during reconciliation.

Processor Reconciliation Columns

The dashboard contains the following columns:

• Date - the day when the transactions were settled by a processor.
• Merchant initiated transactions - financial transactions submitted by a merchant (sale, credit).
• Processor initiated transactions - financial transactions retrieved from a processor (chargebacks, returns).
• Gateway - total amount for the transactions processed on a day on the gateway’s side.
• Processor - total amount for the transactions processed on a day on the processor’s side.
• Difference – an imbalance amount appearing on a particular day. Once a discrepancy is identified, it is populated in this column. Then, if the variance is caused by routine issues, it is either wholly or partially aligned over a one-month period in the Readjustments column. To learn more about the most common problems resulting in an imbalance, please review this link. If the imbalance is not aligned in the Readjustments column during the month, this means that the discrepancy was caused by technical issues that were not identified or resolved.
• Readjustments - an amount of imbalance that was aligned. This column shows the positive/negative amounts that are aligned over a specific period of time (typically over a 5-day period). The values in this column always add up to zero. If the variance is aligned, this means that the issue that causing the discrepancy was either self-resolved or manually fixed. To learn more about the most common problems resulting in an imbalance, please review this link.
• Difference MTD - a balance of discrepancies accumulated to date. If on the 1st of the current month, the Difference column contains an imbalanced amount that was not aligned during the previous month, it is accumulated during the current month.

To see Difference, Readjustments and Difference MTD in action, review the use case below:
The dashboard contains the following totals:

• Balance In - the balance of the processed transactions on the processor’s/gateway’s side at the beginning of the month (for the previous month);
• Balance Out - the balance of the processed transactions on the processor’s/gateway’s side at the end of the month that is shown as an opening balance (balance in) on the next month.

 
To understand how Balance In and Balance Out work, let’s review the example below:

Transaction Summary by Account/Payment Type Dashboards

Transaction Summary by Account Dashboard - a dashboard that covers a certain period of time (usually a day) and groups information on the transactions by a particular account. The dashboard allows for reviewing the information on the financial transactions. In case there is a need to get detailed information on a particular payment type, there is a possibility to drill through to the Transaction Amount by Payment Type dashboard.

Transaction Amount by Payment Type Dashboard - a dashboard that covers a certain period of time (usually a day) and organizes information on the transactions for a particular account by payment type (Visa, MC, etc.)

The dashboards allow for reviewing information on financial transactions (captures, refunds, returns, chargebacks). The information can be reviewed by transaction amount and transaction number for any given time period.

The dashboards contain the following columns:

• Account - the account ID for which the dashboard data is generated
• Payment Type - the card brand for which the dashboard data is generated
• Approvals - the amount/number of approved sale-transactions
• Captures - the amount/number of captured sale transactions
• Declines - the amount/number of declines received on sale transactions
• Refunds - the amount/number of refund/credit transactions
• Returns - the amount/number of direct debit returns
• Chargebacks - the amount/number of chargebacks
• Errors - the amount/number of error transactions
• Net - the captured amount for the processed transactions net of refunds, chargebacks, returns (net=capture-refund-return-chargeback)

Transaction Detail Dashboard

Transaction Detail Dashboard - a dashboard providing a list of the transactions grouped by certain criteria, for example, by account number, transaction amount, status, etc. As a rule, the dashboard is used to drill through a particular processing total in order to show the transactions it consists of.

The columns available on the dashboard are grouped. This allows for specifying which column groups will be available on the dashboard as well as selecting what fields are going to be shown on the dashboard and what fields are going to be available via the report exported from the user interface.
The dashboard contains the following groups and their associated columns:

Account group contains the columns associated with account identifiers:

• account.id
• account.code
• account.name

Merchant group contains the columns associated with merchant identifiers:

• merchant.id
• merchant.code
• merchant.name

Reseller group contains the columns associated with reseller identifiers:

• reseller.Id
• reseller.code
• reseller.name

General group contains the columns associated with the transaction information:

• id
• submissionType
• accountTypeGroup
• activityDate
• amount
• captureDate
• transactionIndustryType
• transactionType
• transactionStatus
• entryModeType
• taxAmount
• transactionMemo

Account Info group contains the columns associated with an account holder’s information on behalf of which a transaction has been made:

• accountType
• accountNumber
• accountAccessory
• holderName
• token

Reference info group contains the columns associated with references to a transaction in an integrator’s system:

• batchCode
• transactionCode
• transactionInternalCode
• itemCode
• userCode
• customerAccountCode
• customerAccountInternalCode

Billing Address group contains the columns associated with billing information of an account holder on behalf of which a transaction has been made:

• billingStreet
• billingCity
• billingState
• billingCountryCode
• billingZipCode
• billingEmail
• bilingPhone

Shipping Address group contains the columns associated with shipping information of an account holder on behalf of which a transaction has been made:

• shippingName
• shippingStreet
• shippingCity
• shippingState
• shippingCountryCode
• shippingZipCode

Gateway Response group contains the columns associated with a standard gateway response:

• responseCode
• responseMessage
• avsResponseCode
• cscResponseCode
• approvalCode

Provider response group contains the columns associated with a standard provider response:

• providerProfileType
• providerTransactionId
• providerResponseCode
• providerResponseMessage
• providerAvsResponseCode
• providerCscResponseCode

Recommendations for Reconciliation Handling via Processor Reconciliation Dashboard

The main purpose of the reconciliation process is to reconcile the amounts of the processed transactions between the processor and the gateway and confirm that these amounts match with the deposit amount in the PSP’s bank account.

As specified above, the reconciliation process involves two systems. This means that reconciliation is done in relation to one particular processor or platform for which a deposit was received in the bank.

A processor can have several platforms. The platforms can process transactions in different countries. As a rule, a deposit is done separately for each particular platform or country. In other words, transactions that are processed via the platform, for example, in the USA and Canada, are deposited as two separate deposits. Thus, even though, there is one processor, for each particular platform a separate reconciliation process should be done.
 
To handle reconciliation in the most effective way, the following steps are recommended:
1. In the bank statement from the PSP’s bank account, locate the total deposit amount for which reconciliation is done.
2. Compare the deposit amount with the amount in the Processor column.
 
a. If the amounts do not match, you have to download the deposit report for the reconciliation period from the processor’s website and compare the deposit amount in the report with the deposit amount in the bank statement:

• If the amount in the deposit report from the processor’s website matches with the deposit amount in the bank statement, there is likely a problem with data import within the gateway. Contact gateway support to determine the reason why the amount the gateway shows for the processor differs from the one in the bank statement and processor’s deposit report. 
• If the amount in the deposit report from the processor’s website does not match with deposit amount in the bank statement, contact processor support and determine the reason why the deposit amount in the bank statement differs from the amount in the processor’s deposit report.

 
b. If the amounts match, go to the step 3.  
3. Compare the amounts in the Gateway and Processor columns. 
a. If the amounts do not match, check the Difference, Difference MTD and Readjustments columns.

• The amount is populated in the Difference column. It is recommended to wait for the amount to get aligned over a 5-day period. To understand how the amounts get aligned in the Difference MTD and Readjustments columns, see the examples in this section.
  • If during a 5-day period the amounts do not become aligned in the Readjustment and Difference MTD columns, contact gateway support. The amounts do not get aligned over a specified period only if the time shift results from ad hoc processing issues. Review this section to learn more about the reasons for a possible time shift. To understand how the amounts are aligned in the Readjustments and Difference MTD columns, see the examples in this section.
  • If during a 5-day period the amounts become aligned in the Readjustment and Difference MTD columns, reconciliation is finished. The amounts get aligned over a specified period only if the time shift results from common processing issues. Review this section to learn more about the reasons for a possible time shift. To understand how the amounts are aligned in the Readjustments and Difference MTD columns, see the examples in this section.

Drill through the Difference, Readjustments and Difference MTD columns to the Transaction List form to analyze which transactions caused a discrepancy. In the Difference column, there may be a description specifying the problem that caused a discrepancy. To clarify the status of the problem resolution, contact gateway support. If a description is not available, the problem has probably not been identified. To clarify the status of the problem identification, contact gateway support.  
b. If the amounts match, the reconciliation is finished. Everything is ok.

Appendix 1: EMAF Report

Processing reconciliation logic is only available if it is possible to obtain information on the processed transactions from the processor. Each processor provides this information differently. In the case of Vantiv Tandem, this information is provided via the Enhanced Merchant Activity File (EMAF).

Enhanced Merchant Activity File (EMAF) is a report that contains information about the processed transactions and associated interchanges.

In the gateway, the EMAF mechanism works as follows:

1. Since the EMAF report contains the information on both processed transactions and interchanges, which are included in the processing cost, you can use this file for both cost-plus and blended rate pricing models. Regardless of whether cost plus or blended rate is used, the file can be used for processing reconciliation. Additionally, if the cost-plus model is used, you can get information on the interchanges included in the processing cost.
2. Since the EMAF report contains a great amount of data, the processor provides this file only upon request. Therefore, discuss the providing of the EMAF report directly with the processor.
3. To receive EMAF reports from a processor, create and configure the Vantiv Tandem reconciliation provider profile for a merchant.
4. When the data about the processed transactions is available, the gateway imports the EMAF reports from the processor’s sFTP. After importing, the report files are available in the merchant’s folder on the FTP server.
5. If you use the processing reconciliation logic of the gateway, the data from the EMAF report is used for the Processing Reconciliation report.
6. If a merchant uses the cost-plus pricing model, the data from the EMAF report is available in the merchant’s statements. In particular, the information about the interchanges included in the processing cost is shown in the Processing Cost section of a merchant statement. Note that only those transactions which were processed through the gateway are included in the statements.

Remittance Reconciliation Dashboard

To analyze remittance information across the merchants associated with a particular reseller or portfolio, the Remittance Reconciliation Dashboard is used.
Remittance Reconciliation Dashboard allows to analyze the distribution of the funds received as a result of transaction processing and deposited to a merchant by the gateway. The bank statements of the payment facilitator are reconciled in detail against the records within the gateway represented as merchant statements. The analysis can be performed at the account, merchant, reseller or portfolio level.

As a rule, a payment facilitator’s portfolio may include merchants working according to different remittance models. For example, most merchants process according to the demand-demand model, but there are groups of merchants who use the demand-cycle and cycle-cycle models. There could be difficulties with reconciliation of these merchants because of the difference in the cycles of statement generation and fee withholding. For this reason, the dashboard includes an additional filter for remittance models, which allows users to load data for merchants working on a particular model.

Remittance Problems Affecting Reconciliation

There are certain problems that can cause a discrepancy in the remittance reconciliation dashboard:

1. Required settings are not configured or a statement is not approved If there are no configurations for the fees/remittance period settings or a merchant statement has not been approved, an amount that is processed does not get into a statement. If the statement does not have any data, the remittance process is impossible. Thus, funds come in but do not go out as a result of remittance. Money remains pending and is unprocessed.

2. Remittance hold is activated

• If the remittance hold mechanism is activated for a merchant, an amount gets included in a merchant statement but does not come out as a result of remittance. In this case, funds are recorded as a negative balance on the merchant. Thus, funds are received by the merchant, but they are not actually deposited as a result of remittance. Money goes on the merchant’s balance.
• If remittance is put on hold, funds may accumulate on a merchant’s balance. If remittance hold is eventually disabled, the accumulated funds go to the subsequent merchant statement that is generated right after the remittance hold is deactivated.  As a result, when reconciliation is done the amount populated as net remittance can exceed the amount populated as processed.


3. Specific remittance period settings If the remittance period is set as “2” or higher, then the processed transaction amount is included in a merchant statement not earlier than the next day. Thus, when reconciling transactions for the processing day the record of the processed transaction amount may belong to the day it was actually processed within the payment facilitator’s system. Within the gateway, however, there might be no record proving that this amount was actually remitted. This is because the statement is generated not earlier than the next day (the amount is shown in the Unprocessed column).


4. Merchant has a debt If a merchant has a debt, there can be a discrepancy between the amount that is populated as processed and the amount that was deposited as the result of remittance. Within the gateway, a merchant balance that has a debt is shown as positive. If the positive balance is offset via subsequent deposits to the merchant’s account, then the amount populated as net remittance can be less than the amount populated as processed.

5. Advance payment An adjustment can be made to a previously transferred advance payment. In this case, for the day the advance payment was transferred and the day it was withheld, a discrepancy can be identified between the amount populated as processed and the amount deposited as a result of remittance. For example, a merchant received an advance payment via a wire transfer. This payment was done via an adjustment in the previous statement. But to avoid a repeated transfer of the advance payment, the payment facilitator makes an adjustment to this amount in the subsequent statement. Thus, for the day the advance payment was transferred, a discrepancy is identified between the amount deposited as the result of remittance and the amount populated as processed. Moreover, a discrepancy between these amounts is identified for the day the advance payment was withheld.

A discrepancy can be as follows:

• the day an advance payment is transferred, the amount deposited as the result of remittance can exceed the amount populated as processed.
• the day an advance payment is withheld, the amount deposited as the result of remittance can be less than the amount populated as processed.

6. Test transactions For gateway testing purposes, test merchants can be used. Remittance is not done for this type of merchants. As a result, funds are accumulated on their balance. When reconciliation is done, a negative balance can be identified. To have it offset, refunds have to be issued manually.

Remittance Reconciliation Columns

The dashboard contains the following columns:

• Date - date of a month, for which activity is reflected.
• Record Type shows the type, for which a reconciled amount is related to:
  • T - total balance is an expected balance for the end of a previous and beginning of a current day. Shown in the columns, which are related to the funds accumulation for settlements with the payment facilitator (Unremitted, Balance, Reserves, Receivables) and third parties (Splits, Charges).
  • R - returns amount is an amount, which was returned to the payment facilitator’s account as a result of the failed attempt to deposit funds or an amount, which failed to be withheld from a merchant’s account as a result of withdrawal. Shown in the columns, which are related to the collecting money from the merchant (Fees, Taxes, Withdrawal) and to the money stuck as a result of a failed depositing attempt (Balance).
  • D - deposit amount is a record, which shows the movement in the columns in a day. The record is based on the amount processed by the gateway and which is going to be deposited to the merchant by the payment facilitator. This line includes all transfers (crediting and disbursement amounts), which eventually affect the deposit amount.
  • C - reconciliation amount is a reconciliation statement amount, in the context of which settlements with the payment facilitator are carried out.

Merchant’s activity is represented as an amount processed in a day. The processed transactions, included in this amount, can be both positive (sales) and negative (chargeback, returns, credits). The settlements between the merchant and payment facilitator are carried out in the context of the money processed during the day. This amount is shown in the Processed column.

• Processed - shows an amount received by the gateway on behalf of the merchant during a particular period of time, such as a business day or weekend. These periods are separated as the transactions, processed during a weekend, are settled by a processor only on the next business day. The amount can be both positive (sales) or negative (chargeback, returns, credits). The movement in the Processed column is shown in line D. Under normal circumstances, the amount in the Processed column on the Remittance Reconciliation Dashboard coincides with the Gateway column on the Processor Reconciliation dashboard.

For certain remittance models and in some scenarios, remittance may not be made and the processed amount may not be deposited to the merchant on the day when it was actually processed. In this event, settlement between the merchant and payment facilitator is not carried out, and money gets stuck in the account of the payment facilitator. This amount is shown in the Unremitted column.

• Unremitted - shows an amount, which is accumulated in the payment facilitator’s account if the remittance process has not been executed. If the amount is negative, it means that money is not deposited and the payment facilitator holds it in its account. If the amount is positive, it means that the merchant receives the money, which had been unremitted.

The movement in the Unremitted column is shown in the T, D and C lines:

• A negative amount in line T shows the merchant’s balance in the amount, which the payment facilitator must transfer to the merchant’s account after a certain period of time (at the end of the day or cycle).
• A negative amount in line D shows that the amount, which the payment facilitator owes to the merchant, is held in its account to be deposited after a certain period of time (at the end of the day or cycle).
• A positive amount in line D shows that the payment facilitator transfers the amount, which was held in its account.
• A positive amount in the line C shows that the payment facilitator transfers the amount, which was held in its account.

Typical cases when an amount will be unremitted:

• merchant has incorrect settings for statements, and the statement has not been generated;
• merchant processed transactions but it works according to the cycle-based remittance model and statement generation time has not come yet;
• merchant statement has been canceled;
• merchant statement has not been approved.

The payment facilitator may withdraw funds from the merchant, and then deposit these funds to either the merchant or 3rd parties. This money is held in the payment facilitator’s account but in fact is not a profit for them. To keep a record of this money, a set of Payables columns is used. This set includes the following columns: Balance, Reserves, Splits, Charges, Adjustments.

• Payables = amounts that a payment facilitator withholds in favor of a merchant or 3rd parties. If the amount is negative, it means that the payment facilitator collects money from the merchant. If the amount is positive, it means that the payment facilitator either pays out the amount to the merchant/3rd party or covers the costs of the merchant at its own expense (such as for a chargeback or return). Payables amounts are shown only if a merchant statement has been generated.

Depending on the column, activity in Payables is shown in lines T, R, D, C.

• A negative amount in line T shows the merchant’s balance in the amount, which the payment facilitator has to transfer to the merchant’s account after a certain period of time (at the end of the day, cycle, after remittance hold is deactivated, etc.).
• A positive amount in line T shows the merchant’s balance in the amount, which the merchant pays off to the payment facilitator after a certain period of time (at the end of the day, cycle, after remittance hold is deactivated, etc.).
• A negative amount in line R shows that there was a failed attempt of depositing or withdrawal.
• A negative amount in line D shows that:
  • the amount is held by the payment facilitator in its account to be paid off after a certain period of time (at the end of the day or cycle);
  • the merchant owes the indicated amount to the payment facilitator.
• A positive amount in line D shows that:
  • the amount that the merchant owes to the payment facilitator goes to the balance until it is paid off after a certain period of time (at the end of the day, cycle, after remittance hold is deactivated, etc.);
  • the payment facilitator owes the indicated amount to the merchant.
• A negative amount in line C shows that:
  • the amount that the payment facilitator owes to the merchant is held in its account to be paid off after a certain period of time (at the end of the day, cycle);
  • the merchant owes the indicated amount to the payment facilitator.
• A positive amount in line C shows that:
  • the amount that the merchant owes to the payment facilitator goes to the balance until it is paid off after a certain period of time (at the end of the day, cycle, after remittance hold is deactivated, etc.);
  • the payment facilitator owes the indicated amount to the merchant.

After the remittance process has been executed, a debt of the merchant to the payment facilitator or vice versa may appear. The amount of the debt is tracked via the Balance column.

• Balance - merchant’s balance, which shows how much a merchant or a payment facilitator each owes to the other. Activity in the Balance column is shown in lines T, R, D, and C.

Typical cases when there is an activity in the Balance column:

• the payment facilitator pays off its debt to the merchant after hold is deactivated, covers chargebacks/returns expenses of the merchant, etc.
• the merchant does not have enough funds to pay off its debt to the payment facilitator;
• for the demand-demand or cycle-cycle remittance models, there were problems with the merchant’s account when a deposit or withdrawal had been attempted.

When a merchant uses the split payments mechanism, part of the processed money goes to affiliates as a result of sales transactions or is received by the merchant as a result of credit transactions. In this case, the logic of funds balancing depends on whether the affiliate’s remittance has been already performed. If not, money sticks in the payment facilitator’s account. How funds, attributed to the split payments, are circulated is shown in the Splits column.

• Splits - the amount of split-out or pull-in transactions that is paid to the merchant’s affiliates as a result of a sale or to the merchant as a result of a credit. The column can be included/excluded from the report via the Format form. Activity in the Splits column is shown in lines T, D, and C.

Typical cases when there is an activity in the Splits column:

• affiliate has not had remittance done yet, and funds are stuck in the merchant’s balance;
• merchant transfers money to the affiliates as a result of the split-out transactions;
• merchant receives money from the affiliates as a result of the pull-in transactions.

If a merchant has the logic of reserves activated, it means that a part of the processed funds goes to the reserve for covering possible chargebacks, returns, refunds. How funds are moved in and out of reserves is shown in the Reserves column.

• Reserves - the amount which is withheld to the merchant’s reserve or returned to its account. The column can be included/excluded from the report via the Format form. Activity in the Reserve column is shown in lines T, D, and C.

Typical cases when there is an activity in the Reserves column:

• part of the funds processed by the merchant are reserved;
• merchant covers chargebacks/returns/refunds from the reserve;
• reserved amount is returned to the merchant.

When working with software platforms, a merchant may pay fees not in favor of a payment facilitator, but in favor of the software platform. In this case, a part of the processed funds is withheld on behalf of a reseller using the charges mechanism. How funds are charged by the reseller is shown in the Charges column.

• Charges - amount that the merchant pays to the reseller. The column can be included/excluded from the report via the Format form. Activity in the Charges column is shown in lines T, D, and C.

Typical cases when there is an activity in the Reserves column:

• merchant did not have enough money to cover the amount of a charge;
• money is withheld from the merchant to cover the amount of a charge.

To have an amount of a statement corrected, a payment facilitator applies adjustments. The adjustments are created manually or via the scheduled adjustments mechanism, and can be either positive or negative. The amount adjusted within the statement is shown in the Adjustments column.

• Adjustments - the amount of adjustment applied in a statement. The column can be included/excluded from the report via the Format form. Activity in the Adjustments column is shown in lines D and C.

Typical cases when there is an activity in the Adjustments column:

• money is withheld from the merchant as an adjustment in the statement;
• money is transferred to the merchant as an adjustment in the statement.

A payment facilitator collects fees for its services. For certain business scenarios, it charges processing cost and taxes separately. Depending on a negative balance handling mode, money can be collected as a deduction or withdrawal. If the deduction option is used, money gets collected during remittance, and the merchant receives net profit. If the withdrawal option is used, a negative balance amount is accumulated on the merchant’s balance and gets collected from the merchant’s account as a separate transaction. In case there are any issues with the account, the payment facilitator receives a return. The amount of the return can be detailed via the dashboard. How much the processor charges for its services is shown in the Fees, Processing Cost, and Taxes columns.

• Fees - summary of the fees that are to be deducted or withdrawn.
• Processing Cost - summary of the processing cost that is to be deducted or withdrawn; can be included/excluded from the report via the Format form.
• Taxes - summary of the taxes that are to be deducted or withdrawn; can be included/excluded from the report via the Format form.

Activity in the Fees/Processing Cost/Taxes columns is shown in lines T, D, C, and R.

• A positive amount in line T shows the merchant’s balance in the amount, which the merchant has to pay off to the payment facilitator after a certain period of time (at the end of the day, cycle).
• A negative amount in line D shows that the merchant owes the indicated amount to the payment facilitator.
• A positive amount in line D shows that the amount that the merchant owes to the payment facilitator goes to the merchant’s balance to be withdrawn at the end of a cycle.
• A negative amount in line C shows that the payment facilitator collects the amount that the merchant owes.
• A positive amount in line R shows there was a failed withdrawal attempt and a return was received.

Accumulation and collection of fees/processing cost/taxes is shown in the Receivables and Due columns. Two different columns are needed to separate amounts that are actually collected from the merchant and that are accumulated on its balance until a particular day of a cycle when it will be withdrawn in favor of the payment facilitator.

• Receivables - the amount of the fees/processing cost/taxes, which was assessed as a result of transaction processing. The column is filled out only for the demand-cycle remittance model. Activity in the Receivables column for the Fees/Processing Cost/Taxes columns is shown in lines T, R, D, and C.

Typical cases when there is an activity in the Receivables column:

• an amount is assessed for the processed funds and expects to be withdrawn;
• an amount is collected from the merchant in the statement.

• Due - the amount of the fees/processing cost/taxes, which is actually collected as a result of transaction processing. Activity in the Receivables column for the Fees/Processing Cost/Taxes columns is shown in line D.

Typical cases when there is an activity in the Due column:

• amount of fees/processing cost/taxes is collected from the merchant, which works according to the demand-demand or cycle-cycle remittance model;
• amount of fees/processing cost/taxes is present in the Receivables column expecting to be withdrawn from the merchant, which works according to the demand-cycle remittance model.

As a result of transaction processing and at the end of a cycle, it is necessary to deposit money to the merchant as well as collect any negative balance from it. The deposit and withdrawal amounts are shown in the Remittance and Withdrawal columns. When calculated, the amounts of remittance/withdrawal must result in zero with other columns.
Activity in the Remittance/Withdrawal columns is shown in lines D, C, and R.

• A negative amount in line D shows that the payment facilitator transfers funds to the merchant from its account.
• A positive amount in line D shows that the payment facilitator collects a debt from the merchant as a deduction.
• A positive amount in line C shows that the payment facilitator collects a debt from the merchant as a withdrawal.
• A negative amount in line R shows that there was a failed withdrawal attempt and a return was received.

When the withdrawal model is used, a payment facilitator collects the amount of negative balance as a separate transaction for a certain cycle. Meanwhile, a merchant may have issues with its account and, as a result, money withdrawal is impossible. In this case, the payment facilitator receives a return. After receiving returns with one hard decline (a decline received with a response code indicating that a subsequent attempt makes no sense) or two soft declines (a decline received with a response code indicating that a subsequent attempt may be successful), the merchant is automatically switched to the deduction conditional model and its remittance is put on hold. Amounts that are related to the negative balance handling are shown in the Withdrawal column. When calculated, the amounts in the Fees/Processing Cost/Taxes and Withdrawal columns must result in zero.

• Withdrawal - the amount of negative balance (fees/taxes/processing cost or merchant’s debt), which is collected by the payment facilitator via a separate transaction from the merchant’s account. Used for merchants that work according to the demand-cycle remittance model. Activity in the Withdrawal column is shown in lines C and R.

After transaction processing is completed, a processed amount must be deposited to the merchant. Depending on the remittance model, the deposited amount can be either gross or net of fees and other deductions. Amounts, that are related to the transferring of the processed funds to the merchant, are shown in the Remittance column. When calculated, the amounts in the Processed and Remittance columns must result in zero when those columns are combined.

• Remittance - the amount of funds deposited from the payment facilitator to the merchant. Used when a deposit statement is generated for the merchants that work according to the demand-demand and demand-cycle models, and when a reconciliation statement is generated for the merchants that work according to the cycle-cycle model. Activity in the Remittance column is shown in lines D and C.

Remittance Reconciliation Test Task

Before starting to use the remittance reconciliation logic, we would like to help you verify if you have completely understood the information described in the guide above and acquired necessary skills on the topic.
For this purpose, we created a test task. Please, download it, pass the test, and send it to the gateway support via the ticketing system. If the test task has been performed correctly, you will be certified as a remittance reconciliation professional user.
When sending the result of the test, please, follow these recommendations:

1. The result can be provided in either Word or PDF format.
2. Use the Support Request form available in your documentation under the Forms button.
3. Select Documentation category.
4. Select Test Task Submission request type.
5. Upload the file with the results of the test and submit the form.