Distributing A Payment Amongst An Account's Service Agreements

Warning:

This section deals with the concept of distributing a payment amongst an account's service agreements. 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 service agreements 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 service agreements 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 service agreements. However, you may manually distribute a payment when a customer directs a payment to specific service agreement(s).

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

  • The age of each service agreement's debt.
  • The payment distribution priority of each service agreement's SA type.

The following diagram helps illustrate how the distribution algorithm works.

The payment distribution algorithm distributes a payment based on the age of each service agreement's debt and payment distribution priority of each service agreement's SA Type. This example shows three columns, one for each service agreement linked to an account. Notice that two of the service agreements 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.

The above example shows three columns, one for each service agreement linked to a hypothetical account. Notice that two of the service agreements 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 service agreements first. In the above example, where multiple service agreements have the same distribution priority, the system does NOT payoff one service agreement before it starts on the next (which one would it pick?). Rather, it distributes the payment amongst the service agreements based on the age of the respective debt on each service agreement. In the above example, this is represented by steps 1 through 6 (notice how the distribution jumps between SA1 and SA2).
  • After all delinquent debt has been relieved from the highest priority service agreement(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 service agreement'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 service agreements' 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 service agreements' 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 service agreement that receives a portion of a payment. Linked to each payment segment is a financial transaction. It is the financial transaction that causes the service agreement'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 service agreement), MATCH_​VALUE contains the ID of the restriction (e.g., the SA ID).

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.