Dates in LogiSense Billing

Last verified with: 10.8.6.0

Overview #

Dates in LogiSense Billing are handled consistently, but not every entity uses dates in exactly the same way.

That is important because billing, usage, discounts, contracts, and price applicability all rely on date boundaries. A misunderstanding about whether a date is inclusive or exclusive can change what is billed, what is discounted, what is taxed, or which price applies.

This guide explains the practical rules of date handling and highlights the most important entity-level behaviors in one place.

The Core Pattern #

Across much of LogiSense Billing, the most common internal date model is:

• start dates are inclusive,
• end dates are exclusive,
• and time-of-day is often normalized to date behavior for billing decisions.

What this means is:

• if something starts on July 15, July 15 is included,
• if something ends or cancels on July 24, July 24 is usually not included,
• and many billing calculations evaluate dates using whole-day boundaries rather than partial-day billing behavior.

This pattern is especially common in recurring billing periods, service temporals, discount applicability, usage periods, and bucket consumption periods.

Important Exception #

Not every entity follows the same rule.

One important exception is account price plan hierarchy range evaluation, which is intentionally inclusive of both the start and end dates.

This is why it is helpful to think of date behavior as an entity-level rule rather than assuming every date in the platform behaves the same way.

Reference Table #

Entity or Date Type	Start Date Behavior	End or Cancel Date Behavior	What This Means In Practice
Account Package Effective date	Inclusive	n/a	Billing can begin on the effective date itself.
Account Package Effective Cancel date	n/a	Exclusive for billing	The package stops billing before the cancel date begins.
Account Service Effective date	Inclusive	n/a	Service billing can begin on the service effective date itself.
Account Service Effective Cancel date	n/a	Exclusive for billing	The service stops billing before the cancel date begins.
Recurring billing periods	Inclusive start	Exclusive end	A period from October 1 to November 1 bills October 1 through October 31.
Invoice item displayed period end	Inclusive for display	Inclusive display value	Invoice line items often show period end as the last billed day, even though internal billing periods are end-exclusive.
Service status temporals	Inclusive start	Exclusive end	A new status beginning on a date takes effect on that date, and the prior status ends before it.
Service transition event date	Inclusive event date	n/a	A transition charge can be associated with the transition date itself.
Discount Start date	Inclusive	n/a	A discount can apply starting on its configured start date.
Discount End date	n/a	Exclusive	A discount does not apply on its end date.
Non-prorated discount applicability	Inclusive start	Exclusive end	A non-prorated discount applies when the as-of date is on or after the start date and before the end date.
Prorated discount period overlap	Inclusive overlap start	Exclusive overlap end	A prorated discount applies only to the overlapping portion of the billed period.
Discount end shown on invoice detail	Inclusive display value	Inclusive display value	Discount detail can present the last discounted day, even when the internal end boundary is exclusive.
Non-recurring charge effective date	Inclusive event date	n/a	A one-time charge uses the event date itself; time-of-day does not create partial-day billing.
Usage aggregation periods	Inclusive start	Exclusive end	Usage is counted when the usage date is on or after period start and before period end.
Usage bucket consumption period	Inclusive start	Exclusive end	Usage can consume from a bucket when it falls on or after the bucket start and before the bucket end.
Usage bucket Effective date	Inclusive	n/a	Usage on or after the bucket effective date can count toward that bucket.
Account Price Plan hierarchy range	Inclusive	Inclusive	A date exactly equal to the start or end can still be considered in range.
Contract or commitment period evaluation	Inclusive start	Exclusive end	A period is typically considered active from its start date up to, but not including, the next calculated period boundary.

What This Means For Billing #

For recurring billing, the most important rule is that the system usually treats the next billing boundary as the first non-billable date.

Example:

• Period start: October 1
• Period end: November 1

Expected behavior:

• October 1 is billable,
• October 31 is billable,
• November 1 is not part of that billing period.

This same logic is why cancel dates are commonly treated as exclusive in billing scenarios.

What This Means For Cancellations #

For package and service cancellations, the effective cancel date is generally the first date that is not billable.

Example:

• Service effective cancel date: October 24

Expected behavior:

• October 23 is the last billable day,
• October 24 is not billed,
• and the final charge depends on the configured cancellation policy, not on including the cancel date itself.

This behavior is one of the key foundations behind proration.

What This Means For Discounts #

Discounts follow the same general boundary logic used by many other billing entities:

• the discount begins on its start date,
• and stops before its end date.

Example:

• Discount start date: October 1
• Discount end date: November 1

Expected behavior:

• the discount can apply on October 1,
• it can still apply on October 31,
• and it does not apply on November 1.

This is helpful to understand because discounts often appear to run “through” a date in business language, while the underlying billing logic still uses an exclusive end boundary.

What This Means For Usage #

Usage periods are typically evaluated with an inclusive start and exclusive end.

Example:

• Usage billing period: October 1 through November 1

Expected behavior:

• usage dated October 1 is included,
• usage dated October 31 is included,
• usage dated November 1 belongs to the next period.

This same pattern also appears in usage tier counting, aggregation, and bucket consumption logic.

What This Means For Usage Buckets #

Buckets follow date rules in two important ways:

• bucket instances are active across an inclusive-start and exclusive-end period,
• and a bucket effective date acts as the first eligible date for usage to count toward that bucket.

Example:

• Bucket effective date: November 15

Expected behavior:

• usage before November 15 does not count toward that bucket,
• usage on November 15 can count toward that bucket,
• and bucket participation is evaluated from that point forward.

This is especially important in entitlement and shared-pool scenarios where the timing of included usage matters just as much as the quantity.

What This Means For Price Applicability #

Price applicability is one area where readers should be especially careful not to assume the default start-inclusive and end-exclusive pattern.

Account price plan hierarchy range checks are intentionally inclusive of both boundaries.

Example:

• Price plan start: January 1
• Price plan end: January 31
• Evaluation date: January 31

Expected behavior:

• the date is still considered in range.

This is different from many billing and discount period evaluations, which would normally treat the end boundary as exclusive.

Why Invoice Dates Can Look Different From Billing Dates #

One source of confusion is that invoice line items often display the final billed day, while the internal billing logic works with an exclusive period end.

What this means is:

• the internal period may be stored as October 1 to November 1,
• but the invoice can display October 1 to October 31,
• because October 31 is the last billable day in that period.

This is expected behavior and is intended to make invoice presentation easier to understand.

Recommended Way To Think About Dates In LogiSense Billing #

The simplest way to interpret dates in the platform is:

1. Start by assuming the system uses inclusive start and exclusive end behavior.
2. Check whether the entity is one of the known exceptions, such as account price plan hierarchy ranges or invoice display periods.
3. Remember that billing and usage often evaluate whole-day boundaries, even when timestamps are present in the source data.

This mental model will explain the majority of billing, discount, usage, and cancellation outcomes in the system.

Why This Matters #

Understanding date behavior helps teams:

• predict what will bill and what will not,
• explain proration and cancellation results,
• design discounts and contracts correctly,
• troubleshoot usage and bucket timing,
• and avoid misunderstandings when comparing UI dates, invoice dates, and internal billing calculations.

The practical benefit is simple: when teams understand how date boundaries work, the system becomes much easier to configure, validate, and explain.