Managing Suspended Payments

About Suspending Payments

A suspended payment is a payment that needs to be corrected. Payment Suspense Manager saves payments a special account called a payment suspense account. You can then allocate them manually, or save them to an exception batch.

Payment suspense handles the following payment scenarios:

Payments that fail the BRM validation process.
Payments that were posted incorrectly to customer accounts.
Payments that pay the bills for multiple accounts. You can subdivide a suspended payment into a list of distributed payments and apply each payment to an individual customer account.
Account-level payments allocated to accounts with multiple bill units (/billinfo objects).

Managing suspended payments also enables you to perform the following payment processing tasks:

Manually suspend payments during payment processing. If you find a successful payment in a payment batch that you suspect contains incorrect data or requires special handling, you can manually suspend that payment so that it can be carefully examined before it is posted to the account.
Manually suspend payments after they have been posted to customer accounts. If a payment was posted incorrectly, you can suspend it and then repost it to the correct account.
Allocate suspended payments to one or more accounts.
Partially allocate a suspended payment so that an amount remains in the payment suspense account. This enables you to track the unrealized revenue in your general ledger (G/L) system.
Create financial reports on revenue that you have realized but that remains unallocated. Suspended payments are assigned to their own G/L segment.

Payments can remain suspended indefinitely. You can move payments back and forth between customer accounts and the payment suspense account any number of times.

You use Payment center to to manually suspend payments that were incorrectly posted to customer accounts and to correct suspended payments.

How you work with this application depends on whether you receive the payment as a batch file from the bank or use a payment gateway that has been directly integrated with BRM payment services.

About the Payment Suspension Process

Payment suspension begins when you collect payments from a financial institution: whether you use payment clerks to manually post payments from batch files or you use a third-party payment gateway to automatically post payments.

The payment processing phase involves three steps: validation, suspension, and correction. These steps are sequential and rely on the completion of the prior step.

Validation: BRM determines whether a payment meets the validation criteria and assigns a status of successful or “to be suspended." BRM takes the following actions:
- If the payment is successful, BRM posts the payment to the account.
- If the payment does not meet the validation criteria but has enough information to qualify for suspense, BRM marks it as “to be suspended" and forwards it to the opcodes responsible for suspending the payment.
  
  BRM can suspend both successful and financially failed payments. For example, a payment batch includes two check payments, each with an incorrect account number. The payment information indicates that one check has cleared and the other bounced.
  
  Coming into BRM, the first payment would be considered successful and the second, failed. When BRM validates the payments, both would be marked for suspense because, regardless of the financial success or failure of the payment, neither payment can be posted to the correct account.
- If the payment does not meet the validation criteria and also does not qualify for suspense, BRM informs you that the payment cannot be posted. You must create an exception batch to handle payments that fall into this category.
Payment validation is initiated automatically through the payment gateway or manually by a payment clerk.
Suspension: BRM moves the payment to the payment suspense account and creates the associated events and items to store information on the suspended payment.

Payent suspense can occur during account maintenance, after payments have been saved to the BRM database.
- During account maintenance, payment suspense is initiated manually by using Payment Center. Payment suspense is initiated when you undo the allocation of a payment from a customer account.
Correction: To correct a suspended payment, you use Payment Center to assign it to a correct account number or bill number and apply it to the customer account. You can also create a distribution list for a suspended payment, which enables you to apply the payment to multiple accounts.

After payment analysts correct suspended payments and assign them to one or more accounts, the payments must be validated again. If the payment validation is successful, BRM posts the payments to the correct accounts. If the suspended payment is allocated completely (an amount does not remain in suspense), BRM reverses the suspended payment, removing it from the payment suspense account. While performing this operation, BRM creates the required objects and events.

Note:

Payment correction is always initiated by a payment clerk through Payment Center; this step is never automatic. If, during revalidation, the payment still meets the suspense criteria, BRM again assigns a status of suspended and the payment is resubmitted to suspense.

Figure 21-1 shows the steps involved in payment suspension and the basic operations they perform:

Figure 21-1 Basic Operations and Steps Involved in Payment Suspension

Description of "Figure 21-1 Basic Operations and Steps Involved in Payment Suspension"

About Payment Suspense and Client Applications

The payment suspense process is initiated in one of three ways:

Through original payments and suspended payments when payment analysts work with a payment batch.
Through a payment gateway when it processes a payment file.

Note:

For the full range of payment suspense functionality to work with a payment gateway, the payment gateway must be directly integrated with BRM payment services.
Through Payment Center when payment analysts work with payment batches that contain suspended payments or after payments have been posted in customer accounts.

Payment center is the BRM client application that is used in the payment suspense process. Payment Center is used to investigate and correct suspended payments.

Use Payment Center for the following tasks:

Investigate and correct suspended payments.
Apply corrected payments to the appropriate account.
Remove a payment from suspense if you cannot correct it within a reasonable time.

When you use automated payment processing, like that provided by a payment gateway, there is no need for payment personnel to handle a payment batch, validate payments, or submit payments to BRM. These steps are all performed automatically by the payment gateway working in concert with BRM.

Figure 21-2 shows how the payment suspense process works if you use a payment gateway to process payments.

Figure 21-2 Payment Suspense Process Using Payment Gateway

Description of "Figure 21-2 Payment Suspense Process Using Payment Gateway"

In this case, the payment gateway directs BRM to perform the validation and suspense tasks. After BRM determines payment status, it submits the payments to the BRM database and moves any suspended payments to the payment suspense account. Then you use Payment Center to review the contents of the payment suspense account, investigate the suspended payments, correct any problems, and submit the corrected payments to BRM.

When you suspend payments that were successfully submitted to customer accounts, you use Payment Center to undo the allocation of the payments in the customer accounts and save them to the payment suspense account. You can then investigate the suspended payments, correct any problems, and resubmit them to the correct accounts.

For information on Payment Center, see Payment Center Help.

Removing Unallocatable Payments from Suspense

In some cases, you may determine that a suspended payment cannot be allocated, and should be removed from the system. Payments of this nature represent unrealized revenue. To track revenue and report for these payments, you can remove them from the payment suspense account as unallocatable.

Note:

When removing an unallocatable payment from suspense, only the active suspended payment is reversed. You cannot reverse any distributed payments or payments that have been reversed due to recycling. After you remove a payment as unallocatable, you cannot return it to the BRM system.

You use Payment Center to remove unallocatable payments from suspense. BRM assigns a G/L ID of 112 for the reversal, placing the payment amount in a special G/L bucket so that you can obtain information about how much unallocatable revenue you have. This amount was a credit that your company could not recognize toward a debit on any account. It is removed from the system and tracked for accounting purposes.

You can remove an original or recycled payment from suspense as unallocatable. Removing unallocatable payments from suspense does not generate any recycled payments.

In some cases, you may must partially distribute a suspended payment and remove the remaining suspended amount as unallocatable. If you then resuspend one of the distributed payments, BRM creates a new suspended payment for the distributed payment's amount, and you can later remove this new amount as unallocatable if necessary.

Note:

If one or more distributed payments have been removed as unallocatable, you cannot directly reverse the original payment from the BRM database.

Payment Suspension Guidelines and Restrictions

The following guidelines and restrictions apply to suspended payment processing.

Only externally initiated payments can be suspended and managed by using Payment Center.
The currency of a recycled payment must match the currency of its original payment.
Payments can be recycled any number of times, but a recycled payment can have only one original payment.
You cannot change the properties of a payment after it has been directly reversed, removed as unallocatable, or recycled completely.
You cannot directly reverse a suspended payment if any portion of the payment has been removed from suspense as unallocatable.
You cannot distribute failed payments. These payments are stored in BRM as /event/billing/payment/failed objects and have a status of PIN_PYMT_FAILED. They are created to handle unconfirmed payment processing.
To directly reverse a payment outside of the recycling process, you must reverse the original payment. If you reverse a suspended payment that was applied to one or more customer accounts, all posted payments will be reversed before the suspended payment is reversed.

The following guidelines apply to suspended payments.

You can process only one suspended payment at a time; you cannot apply multiple suspended payments to customer accounts in the same allocation. Similarly, you cannot return two distributed payments that originated from different suspended payments in the same operation.
If you change the properties (for example, the action owner) of a suspended payment, it will be reversed and a new payment event is created to contain the updated information.
You cannot change the action owner or any other properties of a suspended payment after it has been completely distributed to customer accounts. However, if you return any of the distributed payments to suspense, you can change the properties of the resulting suspended payment.
You cannot refund a suspended payment; you can refund only a payment that has been applied to a customer account. You create payment refunds by using Billing Care or Customer Center.
If you suspend a payment that was previously refunded (the /item/refund object was closed), the due amount on the account is increased by the same amount that was removed by the refund adjustment. For more information on adjustments, see "About Adjustments " in BRM Managing Accounts Receivable.

The following guidelines apply to distributed payment processing.

If the entire list of distributed payments does not pass validation, it is rolled back to suspense.
You cannot recycle a payment directly from one customer account to another customer account; first you must suspend the payment and then apply it to the target account.
When recycling a distributed payment to suspense, the entire payment is recycled; you cannot recycle a partial payment amount.
If one or more distributed payments have been removed as unallocatable, you cannot reverse the original payment from the BRM database.

Configuring BRM for Payment Suspense

To set up BRM for payment suspense, you complete three tasks:

Enabling Payment Suspense in BRM

To enable Payment Suspense Manager, run the pin_bus_params utility to change the PaymentSuspense business parameter. For information about this utility, see "pin_bus_params" in BRM Developer's Guide.

To enable Payment Suspense Manager:

Go to BRM_home/sys/data/config.
Create an XML file from the /config/business_params object:
```
pin_bus_params -r BusParamsAR bus_params_AR.xml 
```

In the file, change disabled to enabled:

<PaymentSuspense>enabled</PaymentSuspense>

Save the file as bus_params_AR.xml.
Load the XML file into the BRM database:
```
pin_bus_params bus_params_AR.xml 
```
Stop and restart the CM.

Creating a Payment Suspense Account

When BRM determines that a payment should be suspended, it stores the suspended payment and all information available for the payment in the payment suspense account.

By default, BRM supports only one payment suspense account. You create payment suspense accounts by using Customer Center and base them on the default customer service representative (CSR) plan. For more information about supporting multiple payment suspense accounts, see the documentation about PCM_OP_PYMNT_POL_SUSPEND_PAYMENT in BRM Opcode Guide.

To create the payment suspense account:

Start Customer Center and choose File - New - Account Type (Business or Consumer) to activate the Account Creation wizard.
On the Contact page, enter payment for First Name and suspense for Last Name. This information is not case sensitive.
On the Plan page, select the CSR package for your BRM system.
Note:

The CSR package you select must comply with these rules:
- The admin_client service should have been used when setting up the package.
- There can be absolutely no bundles or charge offers attached to the package.
On the Payment page, select Undefined for Payment Method.
For all other required fields in the Account Creation wizard, select the defaults.
Click Finish to create the account.

Configuring Suspense Reason Codes and Action Owner Codes

Suspense reason codes explain why a payment was moved into or out of suspense or why an unallocatable payment is removed from the system. Action owner codes indicate who is responsible for correcting the problem or taking other action on the payment.

Reason codes and action owner codes are used in various ways by the different tools you use to process payments:

Payment Center: Provides action owner lists that payment personnel can choose from when assigning a person to correct a payment or use as a criterion when searching for a suspended payment.
Payment Gateway: Automatically assigns reasons to payments processed through a payment gateway provided you implement a preprocessing application to map reason codes in the payment file to reason codes you have created in BRM.

To ensure that BRM can assign the full range of reason codes and action owner codes suitable for your business needs, you customize BRM by:

Creating and loading a reasons.locale file that lists each reason code and action owner code.
Associating each reason code and action owner code with the appropriate Payment Suspense Manager reason code domain.

The reasons.locale file defines each reason code domain, the reason codes or action owner codes that belong to the domain, and the event G/L ID. A reason code domain is a unique identifier, or version, used to organize reason codes according to the activities they are used for. For example, all reason codes that describe why you are removing an unallocatable payment from suspense would be defined within the reason code domain dedicated to that purpose. The domain and reason code information is used to build the /strings object and the event G/L ID is used to build the /config/map_glid object.

Payment suspense reason codes and action owner codes use the following domains:

Payment suspense reason codes: “Reason codes-Payment Suspense Management" version 14.
Action owner codes: “Reason codes-Payment Suspense Management Action Owner reason" version 15.
Reason codes for reversals due to recycling and removing unallocatable payments from suspense: “Reason codes-Payment Suspense Management, Reversal Reason" version 16.

The following ranges are reserved for default BRM reason codes related to payment suspense and payment status:

0: Default reason code.
1 to 1000: Reason codes for successful payments.
1001 to 2000: Reason codes for failed payments.
2001 to 3000: Reason codes for suspended payments.
3001 to 4000: Action owner codes.
4001 to 5000: Reason codes for reversals generated when a payment is moved from a source account to a target account during recycling and for removing unallocatable payments from suspense.

To add reason codes of your own, use values above 100,000.

You must assign G/L IDs for all reason codes you create for the following payment processes:

Removing unallocatable payments from suspense.

This enables BRM to map these payments to the G/L bucket used to store a record of payments that were removed from suspense because they were not correctable. You can then create reports and applications to help you track this form of unrealized revenue. The G/L ID assigned to the /event/billing/reversal event, which occurs when payments are removed from BRM as unallocatable, is 112.
Recycling payments to or from suspense. You can use information in this bucket to help determine how much revenue is recovered from suspense. This G/L bucket is reserved for distributed payments, distributed payments returned to suspense, and original payments to a customer account that are manually suspended, is 113. G/L ID bucket 113 stores both the recycled payment and its corresponding payment reversal. Storing both the payment and reversal in the same G/L ID bucket ensures the correct balance of debits to credits when generating reports.

Note:

You should not assign G/L IDs for action owner codes, and there is no need to assign G/L IDs for the reason codes for suspended payments.

The following example shows a reasons.locale file segment defining a payment suspense reason code domain. Some reason codes are BRM defaults, and some are defined by a user (ID >= 100,000).

LOCALE = en_US
DOMAIN = "Reason Codes - Payment Suspense Management";
STR
  ID = 2001;
  VERSION = 14;
  STRING = "Account No not found.";
  HELPSTR = "Account Number not found in database"
STR
  ID = 100,101;
  VERSION = 14;
  STRING = "Payment is too large.";
  HELPSTR = "The amount of a cash payment is over 10,000."
END

DOMAIN = "Reason Codes - Payment Suspense Action Owner reason";
STR
  ID = 102,001;
  VERSION = 15;
  STRING = "Alaya Baker";
  HELPSTR = "Payments Processing department"
STR
  ID = 102,002;
  VERSION = 15;
  STRING = "Micheal Orden";
  HELPSTR = "Payments Processing department"
END

DOMAIN = "Reason Codes - Payment Suspense Management Reversal Reason";
STR
  ID = 4999;
  VERSION = 16;
  STRING = "Unable to correct payment";
  HELPSTR = "Unable to correct payment."
  EVENT-GLID
    "/event/billing/reversal"         112;
  EVENT-GLID END
STR 
   ID = 110,000; 
   VERSION = 16; 
   STRING = "Payment recycled to suspense";
   HELPSTR = "Payment moved from wrong customer account to payment suspense account" 
   EVENT-GLID 
    "/event/billing/reversal" 113; 
   EVENT-GLID END 
END
STR 
   ID = 110,001; 
   VERSION = 16; 
   STRING = "Distributed Payment allocation";
   HELPSTR = "Suspended payment applied to multiple accounts" 
   EVENT-GLID "/event/billing/reversal" 113; 
   EVENT-GLID END 
END

For more information on the reasons.locale file and assigning G/L IDs, see "Assigning G/L IDs to A/R Actions" in BRM Collecting General Ledger Data.

To define reason codes and action owner codes for payment suspense, you edit the reasons.en_US sample file in the BRM_home/sys/msgs/reasoncodes directory. You then use the load_localized_strings utility to load the contents of the file into the /strings and /config/map_glid objects.

When you run the load_localized_strings utility, use this command:

load_localized_strings reasons.locale

Note:

If you are loading a localized version of this file, use the correct file extension for your locale. For a list of file extensions, see "Locale Names" in BRM Developer's Guide.
The load_localized_strings utility overwrites the /config/map_glid object. If you are updating this object, you cannot load new G/L ID maps only. You must load complete sets of data each time you run the load_localized_strings utility. This is also true when using the /strings object, but only if you specify the -f parameter. Otherwise, the load_localized_strings utility appends the new data to the object.

For information on loading the reasons.locale file and creating new strings for it, see "Loading Localized or Customized Strings" and "Creating New Strings and Customizing Existing Strings" in BRM Developer's Guide.