Distributing A Payment Amongst An Account's Contracts

CAUTION: This section deals with the concept of distributing a payment amongst an account's contracts. It does not discuss how the sum of a payment event's tenders is balanced out by payment allocations. For more information about payment event balance, refer to Unbalanced Payment Events.

A payment must be distributed to one or more contracts for its financial impact to be realized. When a payment satisfies an account's entire debt, you don't have to worry about how the system distributes the payment. The concept of payment distribution is only relevant when a partial or excess payment is distributed.

The first important point to understand is that the method of distributing a payment amongst an account's contracts is contained in an algorithm that's plugged in on to Customer Class. This means that you can have different distribution algorithms for different customer classes.

Note: Manual overrides. Most of the time, you'll let the payment distribution algorithm distribute the payment amongst an account's contracts. However, you may manually distribute a payment when a customer directs a payment to specific contract(s).

The following explanation describes one of the base package payment distribution algorithms (refer to Payment Distribution - Pay Priority and Debt Age for information about this algorithm). This algorithm distributes a payment based on:

The age of each contract's debt.
The payment distribution priority of each contract's contract type.

The following diagram helps illustrate how the distribution algorithm works.

Note: Important! There are other payment distribution algorithms in the base package. Click here to see the available algorithm types.

The figure illustrates how a payment is distributed against the contracts of the account based on the age of the debt and contract's distribution priority.

The above example shows three columns, one for each contract linked to a hypothetical account. Notice that two of the contracts have the same distribution priority, the third has a lower priority. The numbers in the cells indicate the order in which the system distributes a partial payment.

Note: Debt terminology. Before we can discuss the distribution algorithm, you must understand the terminology we use to categorize debt. Delinquent debt is associated with financial transactions that appear on overdue bills. Non-delinquent debt is associated with financial transactions that appear on current bills. New debits debt is associated with financial transactions that do not yet appear on a completed bill (e.g., a late payment charge that hasn't been billed yet).

The following points describe the algorithm used to distribute the partial payment:

The system pays off delinquent debt of the highest priority contracts first. In the above example, where multiple contracts have the same distribution priority, the system does NOT payoff one contract before it starts on the next (which one would it pick?). Rather, it distributes the payment amongst the contracts based on the age of the respective debt on each contract. In the above example, this is represented by steps 1 through 6 (notice how the distribution jumps between Contract 1 and Contract 2).
After all delinquent debt has been relieved from the highest priority contract(s), the system pays off the next priority until all delinquent debt is relieved. In the above example, this is represented by steps 7 through 9.
The system next pays off non-delinquent debt using each contract's respective distribution priority. Note well, the payment distribution algorithm doesn't associate an age with non-delinquent debt and therefore the distribution is based purely on the contracts' respective distribution priority. In the above example, this is represented by steps 10 through 12.
After all non-delinquent debt is relieved, the system next pays off "new debit" debt based on the contracts' respective distribution priority. In the above example, this is represented by steps 13 through 15.
Refer to Overpayment for a description of what happens if money still exists after the above distribution is complete.

Note: Payment segments and financial transactions. A payment segment exists for each contract that receives a portion of a payment. Linked to each payment segment is a financial transaction. It is the financial transaction that causes the contract's debt to be relieved and the general ledger to be impacted.

Fastpath: Refer to Payment Exception for more information about how the system handles errors detected during the payment distribution process.

Note: Overriding the distribution algorithm for uploaded payments. The standard distribution algorithm is used for payments that are Interfaced From An External System unless you specify a MATCH_VALUE and MATCH_FLG on the Payment Staging row associated with the uploaded payment. These fields are used in conjunction to indicate that the distribution of the payment should be restricted in some way (i.e., the standard payment distribution algorithm should not be used). MATCH_FLG indicates how the payment should be distributed (e.g., only distribute to a specific contract), MATCH_VALUE contains the ID of the restriction (e.g., the Contract ID).

Note: Open item customers. For an open-item customer, you MUST override the standard distribution algorithm because the payment is distributed as per the open items that it is relieving. Refer to Payments And Match Events for more information.