Overview

Versapay Settlement Reporting for Business Central enables the ERP to keep 100% reconciled automatically with all activities, payments, and fees processed by the payment processor. Because Versapay Payments is fully integrated with Business Central, our solution already knows about all the payments processed in your ERP or on our cloud services. However, there are still occasions where there could be small variations between the payment processor records and the ERP. The goal of Settlement Reporting is to account for those occasional variations and ensure the ERP is an exact mirror of the merchant statement.

The three scenarios where Settlement Reporting is most impactful are:

1. Settlement Batch: When credit card payments are accepted by a merchant, each payment will be part of a settlement batch at the payment gateway, and each settlement batch typically represents a deposit into the merchant’s bank account. Therefore, as payments are taken throughout the date, the settlement batch at the payment gateway builds up and then is eventually closed – typically based on the time of day. When new payments are taken after the batch is closed, they end up on the next day’s batch. The batch close time is set based on the funding cutoff for the day so that funds can be deposited into the merchant’s bank account the next day. If a batch is held open too long, the next-day funding deadline might not be met, and the merchant would need to wait an additional day to receive the funds.  Because payments taken on the same day might end up in two different batches, based on the cutoff time, it’s important to reconcile the payments in the ERP system with the batch details and deposit amounts daily.

2. Payments processed outside the ERP: The use of a virtual terminal direct from the merchant portal or gateway portal to the processor would result in a payment processed outside of the ERP. When this happens, the ERP does not have any record of the payment. With Settlement Reporting, we can bring awareness of those payments to the ERP user for reconciliation in the ERP.

3. Fee Recording: Some merchant service provider’s payment processing fees are billed daily. Without batch deposit reconciliation, the merchant will not know the fee amount until they receive a statement at the beginning of the following month. This extended period makes manual bank reconciliation difficult, as the deposit amounts will not align with anything in the ERP system.

As stated above, the settlement information will become available typically the next day for retrieval into Business Central (BC).  If enabled, Versapay Payments can retrieve, validate, and post the settlement batch without user intervention.  If the batch cannot be fully validated, it will stay open.  The user must then take action to resolve the issues with the batch, re-validate it and post it manually.

Setups

There are multiple setups that need to exist in order to take advantage of this feature. The list of features is below, but each will be covered in greater detail:

1. Gateway Synchronization Codeunits

2. Gateway Account

3. Gateway Account Synchronization Setup

4. Fee Setup

5. Job Queue

Gateway Synchronization Codeunits

It is required that an EFT Gateway Synchronization Codeunit record related to the VPYNETWORK gateway is created for the Synchronization Type of Settlement Batch (as follows):

Both the Settlement Batch and Settlement Exception records should be added automatically upon upgrade or loading of the Versapay Payments application.  If they are not present, then you can run the “Repair Setup Data” action from the Gateway Card to add the required records, or you can add them manually.

Gateway Account

It is assumed that the user has previously created a VPYNETWORK (VPY) Gateway Account and has verified its connectivity with the Versapay Cloud Platform.  This could have been done through the Payment Setup Wizard, or setup manually. When using the Wizard, the EFT Synchronization Setup is created automatically for you. You will want to confirm that there is a record for the Synchronization Type of Settlement Batch and Settlement Exception (assuming you are using that) and will need to update the Synchronization Direction from “No Integration” to “Cloud to ERP Only”. The screenshot below shows what the completed setup will look like.

Please note that the “Settlement Exception” record is not required as part of the settlement reporting feature.  This record is used for the settlement exception feature (discussed in a separate document).  Settlement exceptions are used to process credit chargebacks, ACH returns, etc.

Fees

When the settlement batches are retrieved, they likely will contain fees.  Thus, it is required that the system understands how to record these fees in the ledger.  Go to the VPYNEWTORK Gateway Account that was discussed previously and click on the “Settlement Fee Setup” action in the ribbon.  An example of the setup page follows:

The Gateway Account Route Code is optional (the use of routes is not explained in this document).

Please note that a record with no Fee Type means that if a fee type is encountered that is not otherwise specified, the system will use the setup record with the blank Fee Type. Select the Account Type, Account No., and Global Dimension 1 and 2 that you would like to post the fee transaction with.

Job Queue

Typically, it may be desired to run the retrieval of settlement batches using a Job Queue Entry.  As stated previously, the system will attempt to validate and post the batch directly after retrieval from the Versapay Cloud Platform (if validated).  It is recommended that the Job Queue Entry be set to run once per day (typically in the morning – seven days per week).  Set the Job Queue Entry to run codeunit 37028754 (EFT Settlement Rep. Mgt.).

Processing

Once the EFT Synchronization Setup record has been added and enabled (via the Synchronization Direction field), the system will no longer create summary lines in the Cash Receipts Journal since the settlement batch processing will now replace that function.  The postings to the Customer Ledger will work the same as before.

On the Versapay Payments Activities pane, you will find three new items:

• Open Settlement Reports – this is the indication to the user of batches that could not be validated

• Retrieve Settlement Reports – a user can click this action to manually retrieve settlement reports. In this mode, the system will still attempt to auto validate and post each batch retrieved. Use this action if you are not setting up a Job queue to retrieve automatically.

• Settlement Reporting Batches – this action will open a page of all settlement batches, whether they are open or closed (i.e., posted).

An example of a Settlement Reporting Card follows:

Besides reviewing the card details, the user can view the following:

Fees

On the Settlement Reporting Fees page, the user can view the fees the processor applied to the batch.  Fees can be included in the batch deposit (this is typical) or can be separately processed directly from the bank account.  An example of the fees that the processor applied to batch follows:

The Routing Number and Account Number fields are not relevant when the fee record is “Included in Batch Deposit” since the fee was netted against the “Net Transaction Amount”.  If the fee was not included in the batch deposit, then banking information will be relevant as the processor separately charged the bank account for the fee.

When the fee is not included in the deposit and the system cannot determine the bank account for the fee record(s), the user will need to edit the record to indicate the proper bank account to use.  Once that change has been made, the user will need to return to the Settlement Reporting Card to re-validate and post the batch.

Transactions

Each settlement reporting batch will contain at least one transaction.  An example of transactions included with a settlement report batch follows (some fields are not shown):

The system will attempt to match each transaction using the “Transaction Token” matched against the “Transaction ID” from an existing “EFT Transaction” record in the system.  If the system cannot match all transactions, the user must intervene.  Unmatched transactions will not have an “EFT Transaction Entry No.” value.  Some typical scenarios to explain why the system cannot match a transaction follow:

• Collaborative AR Portal is utilized and the most recent transactions, including one or more from this batch, have not yet been fully retrieved and posted into the ERP.

  • Solution: Run the process to retrieve the C-AR payments from the Versapay Cloud Platform and fully post them into the system – then click “Re-Process” on the above page to now create the match.

• E-commerce integration is used, yet one or more of the transactions from this batch need to be retrieved into web orders / sales orders.

  • Solution: Run the “Retrieve Payments and Orders” action to pull in orders created from e-commerce activities – then click “Re-Process” on the above page to now create the match.

• A transaction was created directly using the processor’s system (e.g., Tpro4 virtual terminal). The system does not have record yet of this transaction.

  • Solution: The user can click on the “Discover” action to pull more information (using the “Transaction Token”) into the record. As the user scrolls right, additional fields will be updated with information retrieved using the discovery action (Approval Number, Account Type, Surcharge Amount, Exp. Month, Exp. Year, etc.).  Once these fields are populated, the user must click “Submit EFT Transaction” to create the approved EFT Transaction that will typically require separate posting from the Cash Receipts Journal.  Once the EFT Transaction has been successfully created, the user will need to click “Re-Process” on the above page to now create the match.

Journal Entries

The journal line page is used to show the user the summary amounts that will be posted to the ledger.  Once posted, the records will remain, just with the Posted field marked as True.  An example of the journal lines from a settlement reporting batch follows:

The “Re-Process” action can only be used prior to posting.  If, for example, the user has changed the “Settlement Fee Setup” information, the user can click “Re-Process” to update the journal lines with the correct information.  Also, note that the dimensions can be viewed using the Related action.

Validate

A settlement reporting batch must be validated prior to posting.  As stated before, the system will attempt to validate the batch upon initial retrieval.  If the batch cannot be initially validated, the user will need to manually validate the batch in order to post.  If the validation fails, the user be presented with a dialog like:

If the user clicks Yes, an error list will be presented informing the user of all errors that need resolving.  Once the user has resolved all errors (as discussed previously), the user should be able to re-click Validate and receive the message that the batch has now been validated.  The next step for the user is to Post the batch.

Once posted, the batch will no longer be included in the Open Settlement Reports cue.

The “Find Entries” action can be used to navigate the entries created during the posting process.  If the user wants to view additional ledger data for the batch, then the following is suggested:

• Open the settlement reporting batch in question

• Click “Find Entries”

• Open the “G/L Entries” from the search

• Click Related, Entry, EFT Batch Entries

An example of the page that will open follows: