The Pismo platform generates an Accrual status changed event in response to any change in an account's accrual status. This event includes an accrual status field with the following possible values:

• REFINANCING_START—Refinancing has started.
• REFINANCING_CHANGE—Account went from overdue to refinancing.
• REFINANCING_STOP—Refinancing has stopped.
• OVERDUE_START—Account is overdue.
• OVERDUE_CHANGE—Account went from refinancing to overdue.
• OVERDUE_UNDERPAID—Account started out in either overdue or refinancing, and a payment was made that did not cover the total amount due. This is meant to serve as a notification that a payment occurred, but it did not change the account status from overdue or refinancing.
  Note: This status can occur without the account ever being overdue. It's enough for it to be in refinancing when the new payment is made.
• OVERDUE_STOP—Account is no longer overdue and is not being refinanced.
• STOP_ACCRUAL—This status is triggered when the account has been in overdue status (that is, OVERDUE_START or OVERDUE_CHANGE) for the number of days specified in the Stop accrual # of days program parameter. Use Control Center to view or set this parameter.

Event flows

Accruals begin to accumulate the day after the statement due date. The amount of an accrual depends on the relationship between the total amount due (TAD), the amount paid, and the minimum amount due (MAD). The following scenarios illustrate various event flows for Accrual status changed events.

📘

To make the following sections easier to read, the account statuses are used as shorthand for the events. For example, "OVERDUE_STOP was emitted" is shorthand for "An Accrual status changed event with account_status set to OVERDUE_STOP was emitted".

Scenario 1: Client pays less than the MAD by the due date

When a client does not pay the MAD by the due date, OVERDUE_START is emitted on the day after the due date. If the client later pays the TAD, OVERDUE_STOP is emitted.

In the following example, the client had a $5000 TAD, a $750 MAD, and they did not pay anything by the due date. So, on the day after the due date (DD1 + 1), OVERDUE_START was emitted. Later, the client paid the $5000 TAD, and OVERDUE_STOP was emitted.

Scenario 2: Client pays the MAD by the due date but does not pay the TAD

When the client pays at least the MAD by the due date, but the amount paid is less than the TAD, REFINANCING START is emitted on the day after the due date. If the client later pays the TAD, REFINANCING STOP is emitted.

In the following example, the client had a $5000 TAD, a $750 MAD, and they paid $1000 before the due date. So, on DD1 + 1, REFINANCING_START was emitted. Later, the client paid $5000, and REFINANCING_STOP was emitted.

Scenario 3: Client pays less than the MAD by the due date. Later, they make another payment that fulfills the MAD but not the TAD.

As explained in Scenario 1, when the client does not pay the MAD by the due date, OVERDUE_START is emitted on the day after the due date. If the client later makes another payment that makes the total amount paid greater than the MAD, but less than the TAD, REFINANCING_CHANGE is emitted. If the client later pays the TAD, REFINANCING STOP is emitted.

In the following example, the client had a $5000 TAD, a $750 MAD, and they did not pay anything by the due date. So, OVERDUE_START was emitted on DD1 + 1. Later, the client paid $1000. This was greater than the MAD, but less than the TAD, so REFINANCING_CHANGE was emitted. Later, the client paid the remainder of the TAD, so REFINANCING STOP was emitted.

Scenario 4: Client pays the MAD by the due date but does not pay the TAD. No additional payments are made by the next due date.

This scenario starts out like scenario 2. When client pays at least the MAD by the due date, but the amount paid is less than the TAD, REFINANCING START is emitted on the day after the due date. If the client has not made another payment by the following due date, OVERDUE_CHANGE is emitted on the day after the second due date. If the client later pays the TAD, OVERDUE_STOP is emitted.

In the following example, the client had a $5000 TAD, a $750 MAD, and they paid $1000 before the due date. So, on DD1 + 1, the REFINANCING_START was emitted. The client didn't make any more payments before the next due date passed, so an OVERDUE_CHANGE was emitted on DD2 + 1. Later, the client paid the TAD, and an OVERDUE_STOP was emitted.

Scenario 5: Client pays the MAD by the due date but does not pay the TAD. No additional payment is made until after the next due date, when a payment is made that is greater then the MAD, but still less than the TAD.

This scenario also starts out like Scenario 2. When the client pays at least the MAD by the due date, but the amount paid is less than the TAD, REFINANCING START is emitted on the day after the due date. If the client has not made any additional payments when the next due date passes, OVERDUE_CHANGE is emitted on the day after the second due date. If the client later makes a payment that is greater than the MAD, but still less than the TAD, REFINANCING_CHANGE is emitted.

In the following example, the client had a $5000 TAD, a $750 MAD, and paid $1000 before the due date. So, on DD1 + 1, REFINANCING_START was emitted. The client had not made any additional payments when DD2 passed, so OVERDUE_CHANGE was emitted on DD2 + 1. Later, the client paid $2500. This was greater than the MAD, but it did not pay off the TAD, so REFINANCING_CHANGE was emitted.

Scenario 6: For two cycles, the client pays the MAD by the due date but does not pay the TAD

This scenario also starts out like Scenario 2. When the client pays at least the MAD by the due date, but the amount paid is less than the TAD, REFINANCING START is emitted on the day after the due date. If, in the next cycle, the client again pays at least the MAD, but less than the TAD, no event is emitted on the day after the second due date, because the account status has not changed.

In the following example, the client had a $5000 TAD, a $750 MAD, and paid $1000 before the due date, so REFINANCING_START is emitted on DD1 + 1. In the next cycle, the client paid $1000 before the due date. No event is emitted on DD2 + 1.

Scenario 7: Client doesn't pay anything until STOP_ACCRUAL, then pays the TAD

When the client does not pay anything before the due date, OVERDUE_START is emitted on the day after the due date. If they still don't pay anything for the number of days configured in the Stop accrual # of days program parameter, STOP ACCRUAL is emitted. If the client later pays the TAD, OVERDUE_STOP is emitted.

In the following example, the client has a $5000 TAD, a $750 MAD, and did not pay anything before the due date. So, on DD1 + 1, OVERDUE_START was emitted. The client still did not pay anything for the next two cycles. On DD3 +1, STOP ACCRUAL was emitted. Later, the client paid $6000, and OVERDUE_STOP was emitted.

Scenario 8: Client pays less than MAD after account is already overdue

When an account is already overdue (OVERDUE_START or OVERDUE_CHANGE has been emitted), and the client pays less than the MAD before the due date passes, OVERDUE_UNDERPAID is emitted.

In the first example that follows, the client had a $5000 TAD, and the client didn't make a payment by the due date, so OVERDUE_START was emitted on DD1 + 1. Later, the client made a payment, but the amount paid was less than the MAD, so OVERDUE_UNDERPAID was emitted..

In the second example, the client had a $5000 TAD, a $750 MAD, and paid $1000 before the due date, so REFINANCING_START was emitted on the DD1 + 1. The client did not make another payment by DD2, so OVERDUE_CHANGE was emitted on DD2 + 1. Later, the client made a payment, but the amount paid was less than the MAD, so OVERDUE_UNDERPAID was emitted..

Scenario 9: Amount paid less than TAD after refinancing starts

When REFINANCING_START or REFINANCING_CHANGE has already been emitted, and the client pays less than the TAD by the due date, OVERDUE_UNDERPAID is emitted.

In the first example that follows, the client had a $5000 TAD, a $750 MAD, and paid $1000 before the due date, so REFINANCING_START was emitted on DD1 + 1. After this event to be emitted, the client makes a payment, but the amount paid was less than the TAD, so OVERDUE_UNDERPAID was emitted..

In the second example, the client had a $5000 TAD and didn't pay the MAD by the due date, so OVERDUE_START was emitted on DD1 + 1. Later, the client paid $1000. This was greater than the MAD, but less than the TAD, so REFINANCING_CHANGE was emitted on DD2 + 1. Later, the client paid $300. This was less than the TAD, so OVERDUE_UNDERPAID was emitted..