Application and Unapplication of Payment Processes

 Overview

The Application of Payment process applies payments to outstanding charges based on the priority defined on the Detail Code Control Form (TFADETC/TSADETC).

The Unapplication of Payment process may unapply payments if payments which affect the method of application are posted to an account after application of payments has been processed.

Application and Unapplication of Payment are processes run nightly within the AR Feed to FIS job. Unapplication of Payment is run first followed by Application of Payment which is run 3 times with different parameters. This document describes these processes and provides guidance on how to research Application and Unapplication of Payment-related issues as well as how to test new configurations.

Application of Payment

Application of Payment is a process used to apply payments to charges based on system and user-defined priorities in which:

  • Payments are applied to charges
  • Balances of payment transactions are reduced
  • Balances of charge transactions paid are reduced.

The process is run to:

  • Reduce the balance on charges in order to understand what is still outstanding
  • Reduce the proper receivable in the General Ledger
  • Determine what is PAID vs. PAST DUE for late charges.

The process is controlled by:

  • The standard Order of Processing logic in the Application of Payment program (TGRAPPL)
  • The run-time parameters for the the Application of Payment program (TGRAPPL)
  • The values of certain fields for each detail code on the Detail Code Control form - Student (TSADETC)
  • The payment authorization records associated with students on the Authorization Maintenance form (TVAAUTH)
  • The definition of Financial Aid Process years on the Term Code Validation form (STVTERM)

Order of Processing

Application and of Payment Processing takes places in the following general order:

  • Direct Payment (TPays)
  • Direct Invoice Number
  • Like Detail Codes within the same term
  • Priority Order within
    • Title IV (if parameter is set to "Y")
    • Order by term
    • Contracts/Exemptions - "priority in descending order"
    • Like Term
    • Like Aid Year
    • Title IV (if parameter is set to "N")
    • Oldest Charges
  • Refund to any priority
  • Negative charge to any priority

Refer to the Banner Accounts Receivable User Guide - Application of Payment procedure for a detailed description of the sort order of transactions for application of payment. This user guide can be found in the Banner Documentation Bookshelf.

Application of Payment Program

The Application of Payment program (TGRAPPL) is executed 3 times in the the daily AR Feed to FIS job. The parameter values for each execution are identical except for the following:

  1. 1st Pass: Apply Contract/Exemption Payments using Cross-Reference information - Order by Priorities and Ignore Term
  2. 2nd Pass: Apply Contract/Exemption Payments Payments using Detail Code priority - Order by Priorities and Ignore Term
  3. 3rd Pass: Apply Contract/Exemption Payments Payments using Detail Code priority - Payments and charges are both ordered by term
Application of Payment Program Parameters

The Application of Payment program (TGRAPPL) has the following parameters:

ID Number. (Optional). Enter a specific account ID to be applied (single request using the ID number), or leave blank for all accounts that have transactions with outstanding balances. This parameter is blank for all 3 parameter sets.

Apply Refund to any priority. (Required). Enter Y to allow refund charges to be paid by any credit regardless of priority and like term indicator.

  • Y Pay refund charges
  • N Do not pay refund charges
  • ("N" used for all 3 parameter sets)

Apply Neg Chg to any priority. (Required).  Enter Y to allow negative charges to be applied to any charge regardless of priority and like term indicator. A negative charge is then treated as a payment with priority code 000.

  • Y Apply negative charges
  • N Do not apply negative charges
  • ("Y" used for all 3 parameter sets)

Apply Cont/Expt Credits. (Required). Select whether Banner will apply contract and exemption payments by using the cross-reference information on the transaction or the detail code priority.

  • C Contract/exemption credits will be applied using the cross-reference information. You can view cross-reference information on the Student Account Detail form (TSADETL)
  • D Contract/exemption credits will be applied using the detail code priority. You can view detail code priority on the Detail Code Control form (TSADETC).
  • ("C" is used for the first pass and "D" is used for the second and third passes)

Apply Title IV First. Required. Enables you to apply Title IV payments first, then follow the priority order to apply other payments.

  • Y Title IV payments will be applied first
  • N Payments will be applied in standard priority order.
  • ("Y" used for all 3 parameter sets)

Apply Aid to Future Term. (Required). Indicates if you want financial aid (source code equals F) to be applied to charges from a future term, e.g., Fall applied to Spring. It will not go beyond "Like Aid Yr" or "Like Term" if checked.

  • Y Financial aid will be applied to any term.
  • N Financial aid will be applied only to terms less than or equal to the financial aid term. (Like term and like aid year restrictions are still enforced).
  • ("Y" used for all 3 parameter sets)

Apply Other to Future Term. (Required). Indicates if you want other credits (source code other than F) to be applied to charges from a future term, e.g., Fall applied to Spring. It will not go beyond "Like Aid Yr" or "Like Term" if checked.

  • Y Other credits will be applied to any term.
  • N Other credits will be applied only to terms less than or equal to the term of the credit. (Like term and like aid year restrictions are still enforced).
  • ("Y" used for all 3 parameter sets)

Order by Term. (Required). Determine the order in which you want to apply payments.

  • 1 (default) Both - Payments and charges are both ordered by term.
  • 2 Payments - Payments from the oldest term will apply to the highest priority charges, regardless of the term of the charge.
  • 3 Charges - Charges from the oldest term will be paid by the highest priority payments, regardless of the term of the payment.
  • 4 Neither - Banner will apply payments by using priorities and ignoring the term
  • ("4" is used for the first and second passes and "1" is used for the 3rd pass)

Print Application Pending Rost(er). (Required). Lets you print a list of accounts that still have outstanding credit and debit detail balances.

  • Y Print a list of accounts that have application pending.
  • N Do not print a list of accounts that have application pending.
  • ("Y" used for all 3 parameter sets)

Selection Identifier. (Optional) Enter the code that identifies the population with which you wish to work. The selection identifier must be defined on the Population Selection Inquiry Form (GLISLCT). All or none of the population selection parameters must be entered. (This parameter is not used.)

Application Code. (Optional). Enter the code that identifies the general area for which the selection identifier was defined. All or none of the population selection parameters must be entered. The Population Selection Extract Inquiry Form (GLIEXTR) may be used to review the people who will be processed in the load from the selection identifier and application code entered. Valid values may be viewed on the Application Inquiry Form (GLIAPPL). (This parameter is not used.)

Creator Id (Optional). Enter the user ID of the person creating the subpopulation rules. The creator ID must have been specified when defining the selection identifier. All or none of the population selection parameters must be entered. (This parameter is not used.)

User. (Optional). User ID of the person who ran the population selection. (This parameter is not used.)

Unapplication of Payment

Unapplication of Payment is a process that:

  • Breaks apart a prior application of payments
  • Brings the balance back to the related detailed account transactions
  • Sets the re-apply flag on the related application of payment transactions

Unapplication of Payment is run to:

  • Clean up accounts
  • Use later payments to cover charges paid by an earlier payment
  • Change the way a payment was applied

Unapplication of Payment is currently run using auto-selection criteria. It may also be run using population selection.

With auto-selection, payments are selected for unapplication when the account meets at least one of the following three criteria:

  1. Title IV
    • A Title IV is posted and a credit balance exists and a non-Title IV transaction paid an institutional charge.
    • Unapplication of payment has not happened since the credit was posted.
  2. Offsetting transaction
    • A debit balance and a credit balance exist.
    • Unapplication of payment has not happened since the credit was posted.
  3. Reversing charge
    • A reversing charge has been posted.
    • Unapplication of payment has not happened since the reversing entry was posted.

Unapplication of Payment Program

The Unapplication of Payment program (TGRUNAP) is executed in the daily AR Feed to FIS job prior to the Application of Payment program (TGRAPPL). Currently, the following parameters and values are used:

  • Run Mode = B
  • Unapply Automatically = Y
  • Output Popsel Option = N

The remaining parameters are not used.

Unapplication of Payment Program Parameters

The Unapplication of Payment program (TGRUNAP) has the following parameters:

Run Mode.(Required). Options for running the program.
S = Select mode - select accounts that meet one of the three auto-selection criteria
U = Unapply mode - used for population selection only
B = Both -- use auto-selection and population selection

Unapply automatically? (Optional). Indicates whether you want Banner to unapply all records for a term that matches at least one of the three unapplication criteria.
N = No. Only use population selection
Y = Yes. Unapply for the auto and population selection accounts

***Population Selection-Related Parameters Follow.*** All or none of the population selection parameters must be entered.

Selection Identifier. (Optional). Code that identifies the population with which you wish to work. The selection identifier must be defined on the Population Selection Inquiry Form (GLISLCT).

Application Code. (Optional). Code that identifies the general area for which the selection identifier was defined. The Population Selection Extract Inquiry Form (GLIEXTR) may be used to review the people who will be processed in the load from the selection identifier and application code entered.

Creator ID. (Optional). User ID of the person creating the sub-population rules. The creator ID must have been specified when defining the selection identifier.

User ID.(Optional). ID of the person creating the sub-population. This will match the Creator ID and is the Banner logon user ID.

Term Code. (Optional). Indicates the term that you want to use for your population selection. You must enter a value for either this parameter or the Applied Date parameter for your population selection.

Applied Date. (Optional). Indicates the date of application that you want to use for your population selection. You must enter a value for either this parameter or the Term Code parameter for your population selection.

Output Popsel Option.(Optional). Indicates how you want to create an output population selection that you can use to unapply and reapply transactions.
A Append - Adds the new accounts to an existing selection ID and application ID. The new records will be added.
R Replace - Replaces the current accounts with the new account records.
N None - does not create an output population selection.
You must already have defined a selection ID and application ID to create an output population selection.
If you want to create an output population selection, you must run this process in either Unapply or Both mode. Refer to Chapter 3 of the Return of Title IV Funds and Authorizations Handbook for information about creating an output population selection.

Output Selection Identified. (Optional). Code that identifies the population with which you wish to work. The selection identifier must be defined on the Population Selection Inquiry Form (GLISLCT). This value cannot be the same as the input selection identifier.
You must enter a value for this parameter if you chose either Append or Replace for the Output Popsel Option parameter.

Detail Code Control Form - Student

The Detail Code Control Form - Student (TSADETC) is used to define the detail codes that are used throughout Accounts Receivable. Each detail code is defined as a charge or a payment, assigned to a user-defined category and given application of payment information, The fields on the form that affect the Application of Payment process for transactions with the associated detail code are:

Like Term. When checked, restricts payments to apply only to charges from the same term. This is used primarily for financial aid that is awarded to cover current term charges.
Like Aid Year. When checked, restricts payments to apply only to charges from terms within the same Aid Year (as defined on STVTERM, Financial Aid Process Year), with a preference for the matching term.
Title IV. When checked will apply only apply Title IV payments first if the "Apply Title IV First" Application of Payment program parameter is set to Y.
Priority. Priority associated with this transaction.

Priority Codes

Priority codes are series of 3 numbers that:

  • Control the order in which charges should be paid - detail code with highest priority paid first
  • Control the order in which payments are used - detail code with highest priority used first
  • Control which charges are paid by which payments by matching charge and payment priority codes column by column.

The matching of charge and payment priority codes takes place according to the following rules:

  • Zeros (0) are wildcards for matching payments to charges
  • Wildcards on charges are not needed because a negative charge can be applied to any priority.
  • Numbers are matched column by column
    • Payment priority code 999 can pay charge priority 999 only
    • Payment priority code 990 can pay charge priority 990-999
    • Payment priority code 900 can pay charge priority 900-999
    • Payment priority code 000 can pay any charge priority 000-999

Priority Code Examples

Following is a generic Sungard example of charge and payment priority codes and how they would be interpreted by the Application of Payment program (TGRAPPL).

Charge Priority Codes

  • 999 - NSF
  • 899 - Tuition
  • 898 - Student Service Fee
  • 897 - Lab Fee
  • 889 - Housing
  • 887 - Meals
  • ...

Pay Priority Codes and what they will pay

  • 899 - Tuition-only Scholarships -- will pay 899 charges only
  • 890 - Tuition and Fee Scholarships -- will pay 897, 898 and 899 charges
  • 889 - Housing-only Scholarships -- will pay 889 charges only
  • 880 - Housing and Meal Scholarships -- will pay 887 and 889 charges
  • 800 - Tuition/Fee/Housing/Meals Scholarships will pay 887, 889, 897, 898 and 899 charges
  • ...
  • 000 - Cash, Check, Credit Card -- will pay any charges.

Authorization Maintenance Form

This Authorization Maintenance form (TVAAUTH) is used to associate authorization codes with a student, and to maintain a student’s authorization records.

A 'TIV' record authorizes payment on non-institutional charges with Title IV funds. A 'PY' record authorizes payment of prior year charges with Title IV funds. 'TIV' and 'PY' combined authorize application of future aid to a past due balance that is an institutional or non-institutional charge. A maximum of $200 in prior year charges may be paid with future aid. No authorization records are required to apply up to $200 of current financial aid to prior year institutional charges.

Application of Payment Analysis Report

The Application of Payment Analysis report (BS_APPL_OF_PAYMENT) is used to facilitate research and diagnosis of Application and Unapplication of Payment-related issues.

The program assembles data from the following forms for an account for a given term and/or effective date range:

TSIAPPL - Application of payment transactions
TSAAREV - Account detail transactions
TSADETC - Detail code records
TVAAUTH - Payment authorization records.

The program then groups and orders the record as follows:

Group 1 - Applied transactions. Applied payments are on the left and the charges they applied to are on the right. These transactions are ordered by descending application date followed by descending charge priority number.
Group 2 - Unapplied payments.
Group 3 - Charges with no applied payments
Group 4- Authorization records for the account. 

NOTE: The first column in Group 1 contains an application of payment date. This date should be accurate for applications that have not been unapplied. However, when a payment is unapplied, the Unapplication of Payment program writes over the original application date with the date of the unapplication. Since Application of Payment is run nightly, though, it should be reasonably safe to assume that the effective date on the report for an unapplied payment was the original application date.

Accessing the Application of Payment Analysis Report

You may access the Application of Payment Analysis report from Banner SIS using Direct Access or the Reports menu. When you select the Application of Payment Analysis Report, the Process Submissions Control form (GJAPCTL) will display so that you may enter the parameters required to run the report.

Accessing the Application of Payment Analysis Report Using the Reports Menu
  1. Log into Banner.
  2. Select Reports and Jobs.
  3. Select Finance and Administration.
  4. Select Business Services.
  5. Select Application of Payment Analysis.
Accessing the Application of Payment Analysis Report Using Direct Access

Enter BS_APPL_OF_PAYMENT in to GOTO Box and press enter.

Running the Application of Payment Analysis Report

To run Application of Payment Analysis Report, you first need to set up the required parameters. The Process Submissions Control form (GJAPCTL) is used to enter parameters for reports.

Key Block (Page 1 - Block 1):

The Key Block specifies which job you are running.

Enter the following information:

Process: Process will be pre-populated with the Application of Payment Analysis Report (BS_APPL_OF_PAYMENT). If it is blank, enter BS_APPL_OF_PAYMENT.

Parameter Set: Enter the name for the set of parameters you wish to use if you have saved a set of parameters previously. Otherwise, leave blank.

Choose Block/Next from the menu bar to move to the Printer Control block or use the mouse to click into the block.

Printer Control Block (Page 1 - Block 2):

The Printer Control block allows you to choose which printer to use and the time to submit the job.

Enter the following information:

Printer: Printer will be pre-populated with your default department print queue. You may change the printer code if you want the report to print to a different location. Choose Help/List from the menu bar for valid printer codes. If you do not see your print queue listed, call our Faculty & Staff Help Desk for assistance. You may also enter DATABASE and the report will be available for only viewing by selecting Options/Review Output from the menu bar.

Special Print: Leave the value blank.

Number of Lines: Leave the value blank.

Submit Time: Leave the value blank if you wish job to run immediately. If you wish the job to run at a later time, enter the time in military format (i.e., 23:00 for 11:00 PM).

Choose Block/Next from the menu bar to move to the Parameter Values block or use the mouse to click into the block.

Parameter Values Block (Page 1 - Block 3):

The Parameter Values block displays a list of parameters used to create the Application of Payment Analysis report.

Enter the following information:

Student ID . (Required). Enter the ID of the student account.

Transaction Type . (Optional). The selection criteria that follows will apply to charges, payments or both depending on the value entered in this parameter. C=Selection will be based on charge transaction data, P=Selection will be based on Payment transaction data. Default (%) = Select charges and payments that meet the selection criteria.

Include Re-Applied Transactions?. (Optional). Y = list re-applied transactions. N = do not list re-applied transactions. Default is N.

From Term Code. (Optional). Enter the from transaction term code. Default is 000000. Choose Help/List from the menu bar for valid codes.

To Term Code. (Optional). Enter the to transaction term code. Default is 999999. Choose Help/List from the menu bar for valid codes.

From Effective Date. (Optional). Enter the from transaction effective date. Default is 01-JAN-1990.

To Effective Date. (Optional). Enter the to transaction effective date. Default is 31-DEC-2099.

Transaction Number.. (Optional). Enter the transaction number. Wildcard (%) is allowed.

Use the vertical scrollbar or down and up arrow keys to cursor through the records. After entering your parameter values, choose Block/Next from the menu bar to move to the Submission block or use the mouse to click into the block.

Submission Block (Page 1 - Block 4):

The Submission block allows you to save your parameters for future use and to submit the job.

Enter the following information:

Save Parameter Set as: If you wish to save the parameters exactly as is to use again, check this box.

Name: If you have checked the Save Parameter Set as box, enter a name for the parameter set. If you did not check the Save Parameter Set as box, leave Name blank.

Description: If you have checked the Save Parameter Set as box, enter a description for the parameter set. If you did not check the Save Parameter Set as box, leave Description blank.

Hold/Submit: Select the Submit radio button.

Choose File/Save from the menu bar to submit your job. The Application of Payment Analysis Report job should complete within 5-10 minutes. When the job has completed, the reports should print automatically on the designated printer. If they don't, please contact the

Researching Application of Payments Problems

Application/Unapplication of Payment questions often arise when a student questions why they received a collection letter when they were under the impression they had paid all prior term charges. This is frequently due to the fact that a payment originally applied to prior term charges was unapplied and re-applied to current term charges. There are multiple factors involved, such as:

  • Payment and charge priority codes
  • Title IV vs. non-Title IV payments
  • Institutional vs. non-institutional charges
  • Students' authorization records.
  • Financial Aid Processing Years

Generally, the root questions are the following:

  • Why was the payment(s) to the charges from the previous term unapplied?
  • How was that payment(s) re-applied?

A common scenario is that the student had debit balances on prior term, non-institutional charges, had authorized payment of these charges with Title IV funds, and Financial Aid for a new financial aid year was posted before all of the institutional charges for that term were posted. In this case, the Financial Aid would have initially been applied to the prior term/financial year charges. When the remaining institutional charges were posted for that term, the Financial Aid would have been unapplied and re-applied.

If the account has relatively few transactions, or you are thoroughly knowledgeable of the detail codes involved, you may be able to answer these questions by reviewing the student's detail transactions on the Detailed Transaction form (TSAAREV). Otherwise, as in the example below, the Application of Payment Analysis report can be used.

Research Example

Student Paula A. said she received a collection letter dated October 22, 2008. She said that she was aware she had had some outstanding charges from Spring and Summer 2008, but, when she checked her account on September 30, 2008, she said it showed a credit balance. She wants to know why she got the collection letter.

Assuming the student's recollection is correct, the mostly likely reason is that payments that had been applied to her prior charges had been unapplied and re-applied to different charges between the time she checked her account and when the collection letters were run. A review of her Student Mail form (SUAMAIL) confirmed she received Collection Letter 1 for the 200703 term on October 22, 2008. A review of her Account Detail Review form (TSAAREV)showed she received new charges during this time and no longer had a credit balance. How can you verify what happened, when and why?

Research questions:

Answering these questions should help:

  • What is the state of her previous terms (200703-04) charges now? Do any have debit balances now?
  • Did these charges ever have 0 balances, especially on or about September 30, 2008?
  • If they appeared to have zero balances on September 30th, but they have debit balances now, what happened? 

First, run an analysis of her charges from Summer 2008, and any associated applications and unapplications. Running the report for Spring as well as Summer would be more complete, but when unapplication transactions are requested, a report can get very long. So it's best to see if the answers can be determined with a shorter report.

Applied transactions are listed first. Re-applied transactions (Y in the "RA" column) are listed next. The first 3 lines of the report show that there are three summer charges (transactions 195, 197 and 201) with payments applied and 0 balances. Charges with no applied payments are listed next. They only have data on the right. Three summer charges (transactions 196, 200 and 202) currently have no payments applied, and they have debit balances. Together, these 6 lines represent the current state of the student's summer charges.

The report also indicates that on October 1 a September 26 payment was unapplied from these six transactions. This suggests it is reasonable to assume these charges had zero balances on September 30 as the student indicated, paid by transaction 218.

To determine why they were unapplied and how that payment was re-applied, we will now have to do some research on the payment transaction side, specifically, the unapplied payment transaction (218).

  • Click here to see report parameters
  • Click here to see report output

This report image shows part of the history of pay transaction 218. We can again see it was unapplied on October 1st. To determine what happened on October 1st to cause an unapplication, you could look at the Detail Transaction form (TSAAREV). However, this report shows another unapplication on October 2, and, in it, you can see there were two charges (transactions 224 and 225) on October 1st that were unapplied On October 2nd. These new transactions were institutional charges. Further research, not shown here, revealed that the student received all of her Fall 2008 financial aid between September 24-26, well before all her fall tuition and fees were posted. So she would have had a credit balance on October 1st when the new charges were posted.

We can see from the report that transactions 224 and 225 were institutional charges. Reviewing the 3 criteria for automatic unapplication of payments reveals that her account on October 1st would have met the criteria "a credit balance and a debit balance transaction exist with no unapplication since the credit was created." Hence the September 26 payment would have been unapplied.

After the Unapplication of Payment process completed, the 3 Application of Payment processes would have run. Looking at the documentation of the parameters shows that the Order of Term parameter value for the first run would have been 4 - "order payments and charges by priorities and ignore term." Looking at the report, we can see that 3 of the summer transactions had higher priorities (998) than the tuition charges, so they would have been paid first. Tuition and the other summer charges had the same priority (991), but the tuition charges are institutional charges. Reviewing detailed sort order in the Accounts Receivable User Guide - Application of Payment procedure would show that institutional charges for the same term are paid before non-institutional charges for prior terms. The report shows that the October 1 transactions were institutional charges while the summer charges were non-institutional charges. Hence, the final result that high priority, prior term charges have 0 balances, while low priority, non-institutional charges have, once again, a debit balance.

Researching a complex account with many transactions may require running multiple analysis reports, referring to this documentation and referencing the Banner Documentation Bookshelf.

Testing the Application and Unapplication of Payment Processes

In order to test any and all Application of Payment-related data or program parameters, you must have the following privileges in the test database you will be working in:

  • Maintenance access to the Detail Code Control form - Student form (TSADETC) and maintenance privileges to the necessary detail code categories defined by the User Profile Definition form (TGAUPRF).
  • Maintenance access to the Process Submissions Control form (BS_APPL_OF_PAYMENT)to enter job submission parameters for the Application of Payment Analysis program.
  • Maintenance access to the Process Submissions Control form (TGRAPPL)to enter job submission parameters for the Application of Payment program.
  • Maintenance access to the Process Submissions Control form (TGRUNAP)to enter job submission parameters for the Unapplication of Payment program.
  • Maintenance access to the Account Detail Review form - Student (TSAAREV).
  • Maintenance access to the Authorization Maintenance form (TVAAUTH).

If, for example, you wanted to see the Application of Payment impact of changing a priority code and a run-time parameter, you would perform the following steps in test:

  1. Change the priority code on the Detail Code Control form - Student form (TSADETC).
  2. Enter test transactions on the test account's Account Detail Review form - Student (TSAAREV).
  3. Enter the Application of Payment program parameters on the Process Submissions Control form (TGRAPPL)and submit the job for execution.
  4. Upon completion, run the Application of Payment Analysis program to see the results.