There are two customer master (CMASTR) fields tied together here - average payment days (CUAPD) and # of average payment invoice (CUAPI). CUAPI is hidden in the file and not shown on screen. The two fields are updated by the statement run when invoices are paid for a/r items. These two numbers are never reset and just continue to increment and update as purchases are made and paid.
Average Payment Days = Average number of days, from the date of invoice to the date of complete payment of the invoice, for the last X invoices on this customer account, where X is the API field in CMASTR (maximum of 50)
Note: The Average Payment Days uses the current CUAPI number in its calculations (rather than just averaging what is currently in AR history) for the new month. meaning the result could include invoices that have been purged from a/r history file (ARFILE). If the API field is greater than the amount of invoices in AR history, then the accuracy/origin of the number can't be verified. Also it's worth mentioning that only paid invoices are used for this number. Customers that never pay their invoices will have 0 here so it can't be used to gauge completely delinquencies.
Details and Examples
During the statement run the system takes the current payments on invoices and averages them with the existing values. So if the customer has never made a payment and then pays off one invoice after 20 days the CUAPD would be 20 and the CUAPI would be one. On average they have taken 20 days to pay their one invoice.
Say the next month the customer pays 3 invoices - one after 8 days, and two others after 15 days. This is more complicated but it's still the same kind of logic with just a weighted average. We have the original 20 days for the first one so we would add that to the new 8 days for one plus 15 days for the other 2, then divide it all by the total quantity of invoices (4).
(20 * 1) + (8 * 1) + (15 * 2) = 14.5
4
So now the CUAPD would be 14.5 and the CUAPI would be 4. On average the customer has paid their 4 invoices in 14.5 days.
The only kind of odd logic happens when a customer hits the max of 50 invoices. When a customer is at 50, the next payment of an invoice will trigger the statement run to do something different. The run looks at how many invoices are being paid and subtracts that number from the counter in order to re-average things with the most recent payments.
So let's say we have a customer that has an average of 40 days with a counter (CUAPI) of 50 already. During the statement run two invoices are paid after 20 days. The system will do this -
(40 * 48) + (20 *2) = 39.2
50
It takes the original 40 day average * 48 invoices (that's the original 50-2 since there are two new invoices) and adds it to the two new invoices paid at 20 days, then divides that all up by the total of 50. The new invoices do bring down the average, but the overall history of the customer's payments still accounts for the larger part of the number. If they have a large number of a/r invoices each month, this average payment days number is going to be almost a rolling monthly counter and not show a lot of historical relevance at all.