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:

Installment Lattice - Typical

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:

Installment Lattice - Effect of Multiple Settings

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.

See Also