Progressive billing

OpenMeter provides robust support for Progressive Billing through its advanced invoicing engine. This feature enables organizations to effectively manage cash flow and minimize financial risk.

Organizations can implement progressive billing through two key mechanisms:

1. Gathering Invoices - These provide real-time visibility into a customer's current outstanding balance
2. Progressive Billing Profile Settings - This allows for the automated creation of partial invoices during an active billing period when specified thresholds are reached

Progressive billing must be enabled via the Billing Profile. If it has been enabled OpenMeter allows creating invoices during a line's lifecycle:

const invoice = await openmeter.billing.invoices.invoicePendingLines({
  customerId: 'customer-id',
});

#Considerations

The enablement of progressive billing maintains the standard automatic billing behavior - OpenMeter continues to process invoice lines according to their period settings. Creation of partial invoices requires explicit manual initiation.

Progressive billing eligibility for usage-based items is determined by several technical constraints:

• Meter Characteristics: Meters that do not exhibit monotonic increase (such as averages or minimums) are incompatible with progressive billing, those lines will be billed In Arrears
• Pricing Structure: Volume-tiered pricing models cannot be processed through progressive billing

For In Arrears Flat Rate lines, billing occurs exclusively at the period's conclusion without pro-ration for partial periods.

To maintain billing consistency, once a line item has been partially billed, modifications to its unit discount are restricted on the invoice.

#Internals

From the API perspective once a line has billed progressively a line splitting happens. By default we would have one line per billing period that would eventually be part of an invoice:

When the usage-based line can be billed mid-period, we split the line into two:

During this process, the following transformations occur:

• The original Line1's status transitions from valid to split, effectively becoming a grouping line between invoices and excluded from calculations
• A new SplitLine1 is generated spanning from period.start to asOf (the time of invoicing) and is incorporated into the newly created invoice
• A subsequent SplitLine2 is created covering asOf to period.end and is allocated to the gathering invoice

This progressive billing implementation can be identified programmatically by examining the parentLineId attribute in API responses. The presence of this attribute on a valid line indicates it is part of a progressive billing split line configuration.