action.skip

Settlement Concepts

← Reconciliation Overview

payment_app_intro JustOn Cash Management is a Salesforce app that integrates Salesforce CRM with European banks and payment service providers. The app allows you to trigger payments and track payment information related to your business with customers.

You will be able to prepare and execute payment operations based on your orders, invoices or other statements that involve payments or payouts, be it SEPA orders via banks or payments via payment providers. Furthermore, you will be able to retrieve information on processed payments and to associate it with the corresponding receivables or payables – the basis for automatically handling overdue payments.

Broadly speaking, JustOn Cash Management helps reconcile accounts.

Understanding Settlement

Businesses sell and purchase products and services. These operations involve payments or payouts. To settle (or reconcile) accounts, you need to retrieve information on processed payments and to associate it with the corresponding accounts receivable or accounts payable.

pay_app_settle

Settlement in JustOn Cash Management

The settlement implementation allows users or the software to assign registered payments to open entries. In this sense, it constitutes the reconciliation means.

Note

Make sure to not confuse this settlement feature, which associates processed payments with related entries, with the settlement function in JustOn Billing & Invoice Management, which offsets non-related invoices and credits.

Implementation Details

To settle accounts, JustOn Cash Management relates entries with payments using entry items.

Entry Item Concepts

As a result of a settlement operation, entry items associate entries with payments in an n:m relationship. This allows, for example, to distribute one money transfer to multiple entries or to settle one entry with multiple money transfers.

This means: the amount of an entry and the amount of a payment do not necessarily need to be the same. The settlement implementation allows to

  • Associate one entry with multiple payments
  • Associate multiple entries with one payment
  • Associate partial payment amounts with an entry

Entry items "live" and can be modified – through user interaction, like manual assignments, or automatic processes, like settlement by end-to-end ID or payment processing via payment providers. That is, entry items are subject to change, may become 0, but will never be deleted.

Entry Item Amount Values

The entry item holds the actual amount used for the settlement operation. In addition, an entry item can block a certain amount during an ongoing payment transaction, represented as Expected Amount – which is 0 after the collection has completed.

With respect to the settlement progress, the following amount values on entry items are relevant:

pay_app_entryitem_amounts

Amount Type Description
Assigned Amount Shows the amount assigned to an entry in order to settle it using this entry item. Produces both the Assigned Amount on the related entry and the Assigned Amount of the related payment. Negative values are payments, positive values are payouts (see Payment Types).
Expected Amount Shows the expected amount of a pending (requested but not collected) payment, produces the Expected Amount on the related entry. Negative values are payments, positive values are payouts.
Effective Amount The sum of Assigned Amount and Expected Amount.
Required for calculating payment amount values.

Entry and Payment Lifecycle gives an outline view of how these values change as payment and settlement progress.

For an overview of all objects that are relevant for JustOn Cash Management, see Object Model.

General Settlement Logic

The settlement relates entries with payments. Before executing the actual settlement logic, JustOn Cash Management compares the payment assignment keys on entries and the assignment keys on payments to filter the entry-payment pairs that are eligible for being settled.

  • If the two keys match (with the same value, except for null), the corresponding entry-payment pair will be subject to the settlement operation. If there are multiple possible matches, JustOn Cash Management uses the oldest records first (according to the statement date of the entry or the collection date of the payment, respectively).
  • If there is an entry with a payment assignment key but no payment with a matching assignment key, the entry will be excluded from the settlement operation. Likewise, if there is a payment with an assignment key but no entry with a matching payment assignment key, the payment will be excluded from the settlement operation.
  • Entries and payments where the key is null will not be subject to the automatic settlement.

After the key-based filtering, the settlement operation applies the following logic, irrespective of the settlement approach:

  • The actual settlement amount usually defaults to the available amount of the relevant payment record.
  • To prevent overpayments, the settlement amount (as a result of a reassignment or optionally set by a user, see Manually Settling Individual Entries) will never exceed the open amount of the entry. Any remaining amount remains on the payment – available to be assigned to another entry.
  • In case of n:m settlements, a newer entry/payment pair takes precedence, which would, if necessary, modify the settlement amount of a previous entry/payment pair.
  • If the Account fields of an entry and a payment differ, JustOn Cash Management considers this as a debtor change.

    With the settlement operation, the amount of existing entry items associated to entries of different accounts becomes 0. Once completed, the account of the payment is set to the account of the entry.

  • The payment date of an entry item is set to the payment date of the associated payment.

  • The payment date of an entry is updated each time a settlement operation takes place, where

    • the payment date of the entry is set to the payment date of the newest entry item with a non-zero amount if the sum of all entry items settles the open amount of the entry,
    • the payment date of the entry is cleared if the sum of all entry items falls below the open amount of the entry.
  • With ongoing payment transactions (payments in the statuses Open or Pending), JustOn Cash Management blocks the settlement amount, represented as Expected Amount. The expected amount becomes 0

    • after the collection has completed so that the settlement can take place, or
    • if the collection has failed permanently, which frees the money from the entry for another collection attempt.

Settlement Approaches

The association between entries and payments can take place in various ways:

Settlement or payment matching?

Make sure not to confuse settlement with payment matching.

Settlement
Settlement is the mechanism for effectively associating payments with entries using entry items.
Payment matching
Payment matching is the operation that compares bank statement items or payments with entries using customizable matching configurations. After successful matching, JustOn Cash Management can complete the actual settlement.

Automatic Settlement Using a Unique Criterion

For system-initialized payment operations, that is, when initiating payment transactions via a payment provider integration or a connected bank account, there is, usually, a unique ID – a payment provider ID or, with direct debits or credits produced from JustOn Cash Management, an end-to-end ID. Using the unique ID, JustOn Cash Management can complete the settlement – relating the executed money transfer with the original receivable/payable. Generally, this is the safest – and therefore, preferred – way to settle entries with payments.

pay_app_ebics_match

Automatic Settlement Using Data Comparison

Your business may allow bank transfer as a payment method, enabling customers (payers) to execute payments at their discretion. In this case, there is no unique ID. On bank statement retrieval or when triggered manually, JustOn Cash Management therefore proceeds to execute a payment matching operation: it compares bank statement items (and payments created from them) with accounts and entries, looking for matching data like the customer number or statement number – as passed with the reference text – or the amount.

pay_app_auto_match

Overview

JustOn Cash Management's account matching mechanism includes comparison by IBAN (taken from the Debtor IBAN or Creditor IBAN fields), by account number (retrieved from the Reference field) and by account name or contact name (taken from the Debtor Name or Creditor Name fields).

The entry matching mechanism includes comparison by statement number (retrieved from the Reference field), by amount or by date correlation (where the entry's Statement Date must be before the bank statement item's Booking Date or Value Date). Since entries are always related to accounts, the entry matching mechanism will always produce an account match.

During the matching process, JustOn Cash Management filters bank statement items for the status BOOK and checks for related payment records – consequently, it will either update an existing payment (like in case of a chargeback or refund) or create a new one.

After successful matching, JustOn Cash Management completes the settlement, relating the bank statement items and the produced payments with an account and, depending on the given data, with an entry.

Multiple Matches

The settlement logic can handle multiple matches.

A single payment record, as related to one bank statement item, can be matched not only with a single entry but also with multiple entries. A number of use cases may result in this scenario:

  • The customer pays multiple invoices with a single money transfer.
  • The customer makes a late payment for an installment invoice.
  • There are non-unique matching criteria configured, like matching by name or amount.

Now when a single payment matches with multiple entries, JustOn Cash Management settles all corresponding entry records, creating multiple entry items to relate them with the payment. In this case, the settlement logic applies the following prioritization:

  • First, the matching configuration's priority is considered.
  • Then, if there are multiple entries for the same matching configuration, the entries are ordered by their Statement Payment Due Date (with the oldest coming first).
  • The settlement continues until all determined matching entries are settled, or until the available amount on the payment is completely "consumed".

Info

If a single payment matches with multiple entries, the first settled entry determines the account and the business entity. For the further settlements, entries associated to different accounts or business entities are ignored.

Under certain conditions, there may be multiple payments concurring for the same entry. In this case, the oldest payment (ordered by their Collection Date) takes priority.

Payments that remain unassigned are considered credit balances and are subject to credit balance strategies.

Data Comparison Configuration

The data comparison is configurable using matching configurations. Each matching configuration holds a predefined and reusable search template for one discrete matching target.

For details, see Configuring Payment Matching.

Manual Settlement

Users can manually select a payment and associate it with an entry. The manual settlement process allows users to

  • Create payments from bank statement items,
  • Associate unassigned payments to entries, or
  • Re-associate payments to different entries.

pay_app_manual_match

For details, see Manually Settling Entries.

Settlement Process Overview

Depending on which party has triggered the payment operation – the merchant using JustOn Cash Management features (system-initialized payment operations) or the customer (payer-initialized payment operations) –, the settlement will take place in two different ways.

System-Initialized Payment Operation

In a rough outline, the automatic settlement process for a system-initialized payment operation using a unique criterion takes place as follows:

pay_settle_me_1

When initializing the payment transaction for an open entry via a connected bank account (using SEPA direct debit) or a payment provider (using the payment page), JustOn Cash Management creates an open payment record (Issued or Pending) – specifying a unique ID and related to the entry.

pay_settle_me_2

JustOn Cash Management gets information from the bank or payment provider about the executed payment transaction, creating a corresponding bank statement item or payment notification. Using the unique ID, JustOn Cash Management can relate the incoming information with the pending payment record.

pay_settle_me_3

Associating the matching bank statement item or payment notification, JustOn Cash Management completes the settlement. It sets the payment record to Collected and, consequently, the related entry to Balanced.

Payer-Initialized Payment Operation

For a payer-initialized payment operation – which requires a data comparison –, the settlement process looks different:

pay_settle_them_1

With payment transaction executed on the payer's discretion, like a bank transfer, JustOn Cash Management retrieves information about a collected payment without immediate matching criterion.

pay_settle_them_2

JustOn Cash Management proceeds to execute a payment matching operation: it compares the bank statement item with open entries (or accounts), looking for matching data like customer number, statement number or amount.

pay_settle_them_3

Once successfully matched, JustOn Cash Management relates the payment (as produced from the bank statement item) with the corresponding entry. It sets the related entry to Balanced, completing the settlement.

Matching and Settlement Results

Settlement operations can produce various results – as kept in the field Matching Result on payments, refunds and bank statement items. According to the outcome, users may need to take additional action.

Matching Result Description
Account matched JustOn Cash Management has found a matching account, but has not completed the settlement. A user must proceed to manually settle the payment.
Manually settled A user has settled the payment manually.
Payment Id matched JustOn Cash Management has found a matching payment based on a unique ID but the current transaction involves an amount with a reversed sign. Usually, this indicates a chargeback.
Settled by Payment Id JustOn Cash Management has completed the settlement based on a matching unique ID.
Settled by automatic match JustOn Cash Management has completed the settlement through data comparison based on active matching configurations.
Unmatched JustOn Cash Management has not found any matching data. A user must review the matching configurations and repeat the automatic settlement, or proceed to manually settle the payment.
Unmatched, multiple results JustOn Cash Management has found multiple possible matches for different accounts or business entities. A user must review the matching configurations and repeat the automatic settlement, or proceed to manually settle the payment.

Credit Balances

Certain business operations may produce credit balances. A credit balance is a "free" amount of money on a debtor's account that is not used to settle a receivable.

Typical use cases that may result in a credit balance include, among others

  • The merchant cancels a debit entry,
  • The merchant reduces a debit entry using a credit,
  • The system cannot associate a payment with a debit entry automatically,
  • The customer pays more than the sum of open debit entries.

These "residual" amounts of money must be dealt with. To this end, JustOn Cash Management supports credit balance strategies.

Credit Balance Strategies

Credit balance strategies allow to define how to deal with free amounts of money on a debtor's account in an automatic way. Each strategy describes the behavior for a certain business processes.

There are different strategies that can be applied to a business process:

Credit Balance Strategy Description
Future Settlement Represents a credit balance available to be settled with the next receivable.
Prepared Refund A prepared refund blocks the credit balance from being available for settlement. The credit balance is not paid back to the customer automatically. The money is effectively "frozen" on the debtor's account until the money is actually moved.
Direct Refund A direct refund is defined by refunding money with a reference to the original payment transaction.
The behavior differs depending on the payment transaction context:
For payments made via a payment provider, this triggers a Referenced Refund.
For payments made via a bank account, this triggers a SEPA Credit Transfer.

You can select the applicable credit balance strategies on three levels, where the definition on a more specific level overrides the general setting:

Organization default
Org admins can set organization default values in the (business process-specific) credit balance strategy fields on the Business Entity object. These options will be applied if neither the business entity nor the business process define a specific credit balance strategy.
Business entity default
More specifically, you can select (business process-specific) credit balance strategies for your business entity. These settings will override the organization default values.
Business process execution
Certain business operations allow users to specifically select a credit balance strategy. Doing so will override both the org default and the business entity setting for the current operation.

Supported Business Processes

Supported business processes for applying credit balance strategies currently include:

Business Process Credit Balance Strategy Description
Cancel Entry Future Settlement (default)
Prepared Refund
Direct Refund
Canceling an entry will affect the association of existing payments to entries, and will therefore create a credit balance.
For details on setting up the credit balance strategy for the entry cancellation, see Configuring Cancellation Credit Balance Strategy.