Describes how invoices are aged differently depending on how aging categories are defined.
This document was previously published as Customer Connection Solution 200782646
Solution
Overview of Aging
The Credit Analysis Refresh (R03B525) is used to age customer invoices for on-line review programs, as well as for sending Delinquency Notices. Aging can also be performed when generating statements. Invoices are aged consistently regardless of which program is being executed.
Aging is performed using the parameters established in the aging buckets in conjunction with the Aging As Of date entered in the processing options of Credit Analysis Refresh(R03B525). Aging can either be established in the A/R Constants table (F0010) or in the processing options of R03B525. Regardless of where aging is established, invoices are aged in the same manner.
Aging Considerations
Determining the bucket (or period) in which the invoice amounts will be updated depends on how the aging categories are defined. There are some standards which are followed:
Zero determines the starting point for aging based on the Aging As Of Date.
The first and second aging categories define the Current aging bucket.
The second and the third aging categories define aging bucket 1.
The third and the fourth aging categories determine aging bucket 2.
The fourth and the fifth aging categories determine aging bucket 3.
The fifth and sixth aging categories determine aging bucket 4.
The sixth and seventh aging categories determine aging bucket 5.
The seventh and eighth aging categories determine aging bucket 6.
The Future aging bucket is defined as anything prior to the first aging category. Not all applications have a Future aging field.
Credits and unapplied receipts can also be aged. These types of transactions can be aged differently by the processing options on the Aging Tab of R03B525. The options are to:
Blank - Do Not Age
1 - Use Aging Option 3 (ages credits like standard invoices using the date type specified in option 3)
2 - Current Amount (put credits in the current bucket only)
3 - Balance forward (ages credits up to the first invoice on through all invoices that use up the credit amounts)
Examples of Aging
Consider the following examples:
Aging is Based on Invoice Date
Aging Method is 1 (for aging days)
As Of Date is 4/01/05
Invoice #1 is for $100 and has an invoice date of 3/01/05
Invoice #2 is for $200 and has an invoice date of 3/15/05
Invoice #3 is for $300 and has an invoice date of 4/05/05
Invoice #4 is for $400 and has an invoice date of 5/15/05
Aging Categories are established as follows: -30, 0, 30, 60, 90, 120, 150, 999
Current Aging Category = -30 to 0
Aging Category 1 = 1 to 30
Aging Category 2 = 31 to 60
Aging Category 3 = 61 to 90
Aging Category 4 = 91 to120
Aging Category 5 = 121 to 150
Aging Category 6 = 151 to 999
According to the parameters established, invoices would be aged as follows:
Invoice #1, considered 31 days late, would be updated into aging category 2 (31 - 60).
Invoice #2, considered 16 days late, would be updated into aging category 1 (1 - 30).
Invoice #3, considered 4 days early, would be included in the Current aging category (-30 - 0).
Invoice #4, considered 45 days early, would not be included in an aging category unless the application has a Future aging field defined.
If the aging categories are changed as follows: 0, 30, 60, 90, 120, 150, 180, 999, the same invoices would be aged accordingly:
Invoice #1 would be updated into aging category 1 (31 - 60).
Invoice #2 would be updated into the Current aging category (0 - 30).
Invoices #3 and #4 would not be included in an aging category unless the application has a Future aging field.