Billing Extension Points

Last verified with: 10.8.6.1

Overview #

Billing extension points allow LogiSense Billing to apply customer-specific billing logic at controlled points in the invoice lifecycle.

This guide is intended to answer a practical question: when standard billing has calculated an invoice, where can customer-specific logic be applied, and what should you expect the system to do?

LogiSense Billing supports two important billing extension points:

• Post Billing Extension Point
• Invoice Render Pre-Processing Extension Point

Both are designed for specialized billing behavior. They should be used when a customer requirement cannot be modeled cleanly through standard product catalog, rating, discount, tax, or invoice configuration.

The Core Model #

The two extension points happen at different stages of billing.

What this means is:

• the Post Billing Extension Point is used for invoice charge adjustments before the invoice is finalized,
• the Invoice Render Pre-Processing Extension Point is used after invoice calculations are complete and just before invoice rendering,
• each extension point has a different purpose,
• and choosing the right extension point is important because it affects invoice totals, taxes, rerenders, and operational support.

The most important rule is:

• use the Post Billing Extension Point when the current invoice needs additional charge or credit lines,
• use the Invoice Render Pre-Processing Extension Point when logic depends on the completed invoice result or needs to prepare data immediately before rendering.

Where These Extension Points Fit #

During a typical bill run, LogiSense Billing calculates invoice charges from packages, services, usage, contracts, taxes, discounts, credits, payments, and other configured billing behavior.

The Post Billing Extension Point runs after the standard invoice charge generation work has produced the main invoice content, but before the invoice is fully finalized.

The Invoice Render Pre-Processing Extension Point runs later, after invoice calculations are complete and immediately before the invoice is rendered.

What this means is:

• Post Billing logic can become part of the current invoice’s financial result,
• Render Pre-Processing logic can inspect the completed invoice result,
• Render Pre-Processing changes are available to the rendering process because invoice data is loaded after the extension point runs,
• and logic that creates future-cycle activity must be designed to avoid duplicate work during rerenders.

Post Billing Extension Point #

The Post Billing Extension Point allows customer-specific logic to add invoice charge adjustments.

This is useful when the standard billing engine has completed its normal invoice item generation, but the customer requires one or more additional adjustment lines based on business-specific rules.

What this means is:

• the extension can add positive or negative adjustment amounts,
• the extension can add up to 10,000 invoice line item adjustments for a single invoice,
• adjustment lines can include a description, billing period, quantity, price, tax category, general ledger mapping, package reference, service reference, and usage-related values where applicable,
• the platform persists those adjustment lines as invoice adjustment items,
• those adjustment lines can participate in later tax processing,
• and the final invoice totals can include the adjustment.

This extension point only applies while the invoice is still open. It is not intended to modify invoices that are already posted, rendered, delivered, void, or in the process of being voided.

Post Billing Example: Contractual Adjustment #

Example:

• A customer has a contractual rule that charges a monthly administrative fee when invoice usage exceeds a defined threshold.
• Standard recurring and usage charges have already been calculated.
• The customer-specific rule evaluates the invoice result and determines that a $25 adjustment should be added.

Expected behavior:

• the invoice receives an additional adjustment line,
• the line can carry the correct description, billing period, tax category, and general ledger mapping,
• the adjustment is included before the invoice is finalized,
• and the final invoice total reflects the additional charge.

Post Billing Example: Usage-Based Credit #

Example:

• A customer receives a credit when the current invoice contains usage charges above an agreed monthly amount.
• The credit is not a standard discount because it depends on customer-specific usage grouping and invoice-level rules.
• The extension calculates a credit amount of $12.50.

Expected behavior:

• the invoice receives a negative adjustment line,
• the adjustment appears as part of the current invoice result,
• taxes and totals can be calculated with the adjustment in place,
• and finance teams can see the credit as a distinct billing adjustment rather than a manual correction.

Invoice Render Pre-Processing Extension Point #

The Invoice Render Pre-Processing Extension Point allows customer-specific logic to run after invoice calculations are complete and just before the invoice is rendered.

This is useful when logic needs the completed invoice result before it can act. It is also useful when information must be prepared immediately before the invoice document, invoice data export, or related render output is produced.

What this means is:

• the extension can inspect the completed invoice,
• it can prepare data that should be visible during rendering,
• it can perform customer-specific logic that depends on final invoice totals,
• and it can support future-cycle billing setup based on the current completed invoice.

Because this extension point runs after invoice calculation, it should not be the default choice for current-invoice financial adjustments. Current-invoice charges and credits should normally be handled by the Post Billing Extension Point so they participate in the invoice calculation flow.

Render Pre-Processing Example: Next-Cycle Credit Or Surcharge #

Example:

• A customer wants to apply a credit or surcharge in the next billing cycle based on this invoice’s amounts.
• The final invoice totals must be known before the next-cycle credit or surcharge can be determined.
• The extension evaluates the completed invoice immediately before rendering, after all invoice totals have been calculated.

Expected behavior:

• the current invoice is calculated normally,
• the extension reads the completed invoice totals,
• the extension determines whether a credit or surcharge should apply to the next billing cycle,
• the extension creates or prepares the billing data needed for that next-cycle credit or surcharge,
• and the current invoice can still render with the completed invoice information.

Render Pre-Processing Example: Final Total-Based Invoice Notice #

Example:

• A customer wants a special invoice notice when the final invoice total, tax total, or usage charge total crosses a defined threshold.
• The notice cannot be determined until all invoice calculations are complete.
• The extension evaluates the completed invoice immediately before rendering and prepares the message or summary data that should appear on the invoice.

Expected behavior:

• the final invoice calculation remains intact,
• the extension determines whether the invoice meets the customer-specific notice rule,
• the extension prepares the message or summary data used by the invoice template,
• the invoice render process picks up the latest invoice information,
• and the rendered invoice can include the final-total-based notice without changing the invoice’s calculated charges or taxes.

Choosing The Right Extension Point #

Use the Post Billing Extension Point when:

• the current invoice needs an additional charge or credit,
• the adjustment should affect invoice totals,
• the adjustment should be available before tax and finalization,
• the adjustment should appear as a distinct invoice adjustment line,
• or the logic is tied to invoice charge creation rather than invoice rendering.

Use the Invoice Render Pre-Processing Extension Point when:

• the logic depends on the completed invoice result,
• the logic prepares information for rendering,
• the logic creates or prepares future-cycle billing activity,
• the logic should run immediately before invoice documents or exports are produced,
• or the current invoice should remain financially complete before the extension runs.

Reruns And Rerenders #

Billing extension logic must be designed to behave predictably if billing is retried or an invoice is rendered again.

What this means is:

• Post Billing adjustment logic should not create duplicate adjustment lines for the same invoice,
• the platform avoids re-running the Post Billing adjustment logic when existing invoice adjustment items are already present,
• Render Pre-Processing logic can run again during rerender scenarios,
• and any future-cycle or render-preparation logic should be idempotent so the same invoice does not create duplicate downstream activity.

Idempotent behavior is especially important when an extension creates records for a later billing cycle, updates invoice-related metadata, or prepares supporting render data.

Operational Guardrails #

Customer-specific billing extensions should be kept narrow, predictable, and auditable.

What this means is:

• extension logic should be scoped to the current account and invoice context,
• it should avoid long-running external dependencies during bill run processing,
• it should produce deterministic results for the same invoice state,
• it should write enough operational detail for support teams to understand what happened,
• and it should fail clearly when required data is missing or invalid.

For Post Billing adjustments, the platform supports up to 10,000 invoice line item adjustments for a single invoice. Implementations should avoid creating high-volume adjustment detail that would be better represented through standard usage, rating, or product configuration.

What You Should Expect To See On The Invoice #

From a billing-operations perspective, the most visible outcomes are:

• Post Billing adjustments can appear as distinct invoice adjustment lines,
• those lines can affect the current invoice total,
• taxes can be calculated for those lines when tax configuration applies,
• Render Pre-Processing changes can affect what data is available to the render output,
• and future-cycle setup created during Render Pre-Processing may not appear as a charge until the next applicable bill run.

When Not To Use These Extension Points #

These extension points are not replacements for standard billing configuration.

They should generally not be used to:

• replace normal recurring charge setup,
• bypass usage rating,
• recreate standard discount behavior,
• correct product catalog configuration problems,
• make routine manual billing corrections,
• or modify invoices that have already completed their financial lifecycle.

If the required behavior can be modeled using standard products, prices, usage rates, discounts, taxes, bill groups, or invoice templates, standard configuration is usually the better choice.

Why This Matters #

Billing extension points are important because they let specialized customer logic live inside a controlled billing lifecycle.

They allow businesses to:

• support customer-specific billing agreements,
• add invoice adjustments without manual invoice editing,
• prepare next-cycle charges from completed invoice results,
• enrich render-time invoice data,
• preserve predictable invoice lifecycle behavior,
• and keep custom billing rules explainable to implementation, operations, and finance teams.

The practical benefit is flexibility without turning every customer-specific billing rule into an ad hoc operational process.