Installment Lattices
Overview
The general billing flow is that the policy system will send Policy Transactions to the billing system. The billing system will process the charges for the transaction, and divide each into a set of installment items, distributed across installments. These installments are then used to construct invoices.
The Installment Lattice is a template that is used determine exactly how to distribute the charges, both in terms of amounts for each installment item (which sum to the amount of the charge), and the timing, as determined by the installments that are created.
Key points to remember are:
Installment Lattices are each contained in a single policy term. On renewal, a new lattice will be created for the new term.
A single lattice will be used for each term unless it needs to change based on installment plan changes, or changes to the policy start or end time (which would affect the start or end time of one or more terms in the policy.)
The lattice has Frames which are then used to create Installments for a transaction.
Each installment is created by a transaction and is then immutable. When the installment reaches its
generateTime, it is used to construct an invoice. The invoice is the receivable that the insured is then responsible for paying.Multiple installments may be used to construct a single invoice.
The installment sequence may be regular (such as Jan 1 -> Feb 1, Feb 1 -> Mar 1, etc..) or irregular based on the options for installment weighting, caps on the number of installments in a term, and date anchoring which may shift the installment boundaries earlier or later.
There is a distinction between the nominal time range of an installment, which is often tied to a month, like “January 2025,” and the coverage time range. For example, if the first installment in the term is weighted at 2x compared to following installments, its coverage duration will be twice the coverage duration of those following terms, even if the nominal time range is identical.
Note
The reason for having a separate coverage time slice is so that subsequent transactions that are effective after the term start have installment distribution that is intuitive, with no stray amounts landing on the wrong installment. This can be particularly frustraing and confusing in the case of cancellation, where slight mismatches result in non-zero invoice amounts well past the cancellation time.
Structure
A typical installment lattice for a quarterly cadence, billing 14 days in advance, and due dates 2 days in advance, might look like this:
Frame 1 |
Frame 2 |
Frame 3 |
Frame 4 |
|
|---|---|---|---|---|
Nominal Start |
Jan 1 |
Apr 1 |
Jul 1 |
Oct 1 |
Nominal End |
Apr 1 |
Jul 1 |
Oct 1 |
Jan 1 |
Coverage Start |
Jan 1 |
Apr 1 |
Jul 1 |
Oct 1 |
Coverage End |
Apr 1 |
Jul 1 |
Oct 1 |
Jan 1 |
Invoice Generation |
Dec 18 |
Mar 18 |
Jun 17 |
Sep 17 |
Invoice Due |
Dec 30 |
Mar 30 |
Jun 29 |
Sep 29 |
Here, the nominal and coverage time ranges are identical because there are no installment settings that cause coverage to diverge from billing.
If we decided to limit the number of installments in the term to 3, and overweight the first installment by 2x, align the due date to the 15th of the month, and anchor so that the installments fall on the 2nd month of each quarter, we’d get this:
Frame 1 |
Frame 2 |
Frame 3 |
Frame 4 |
|
|---|---|---|---|---|
Nominal Start |
Jan 1 |
Feb 15 |
May 15 |
Aug 15 |
Nominal End |
Feb 15 |
May 15 |
Aug 15 |
Jan 1 |
Coverage Start |
Jan 1 |
Mar 20 |
Jul 21 |
Oct 11 |
Coverage End |
Mar 20 |
Jul 21 |
Oct 11 |
Jan 1 |
Invoice Generation |
Dec 18 |
Feb 1 |
May 1 |
Aug 1 |
Invoice Due |
Dec 30 |
Feb 13 |
May 13 |
Aug 13 |
In this case there are only 3 full installments (the first one is shorter and so doesn’t count,) and the first installment duration is overweighted which pushes the coverage end out past the nominal end.
Process
When a new transaction is being processed for billing, the system will do the following for each affected policy term:
Create a new installment lattice if needed
Overlay each charge against the lattices’ coverage time segments
Compute the amount for each installment item based on the coverage duration in the overlap between charge start/end and frame start/end
Combine the installment items created by each frame into a single installment
Set the installment’s nominal and coverage start and end times, along with the invoice generate and due times to be the same as the corresponding frame in the lattice.
After this, these new installments are eligible to be invoiced when their respective generateTime is reached.