Invoice Lifecycle & Adjustments

Last verified with: 10.8.6.0

Overview #

Understanding the invoice lifecycle is important because an invoice in LogiSense Billing is more than a document. It is the point where billable activity becomes customer accounts receivable, and where later adjustments must be handled carefully to preserve financial accuracy, traceability, and customer clarity.

This guide explains how invoices move through their lifecycle, how different adjustment methods should be understood, where snapshot invoices fit, and what these events mean for the General Ledger.

The Core Lifecycle #

The invoice lifecycle is best understood as:

Draft -> Posted -> Closed

The working or draft stage is represented by an Open invoice together with temporary processing states such as tax, render, and delivery statuses. Once invoice totals are finalized, the invoice moves to Posted. Closure is then tracked separately on the invoice record as part of invoice management and invoice control.

That distinction matters because posting and closing are not the same event.

Posting is the point where the invoice becomes the financial receivable.
Closing is the point where the invoice is treated as complete in the invoice lifecycle.

Draft Stage #

When an invoice is first created, it begins in a working state.

From a business perspective, this is the draft stage. The invoice exists, but the platform is still assembling and finalizing the outcome. Charges, usage, taxes, credits, balances, and due-date logic are still being resolved.

This stage matters because it gives the platform a controlled place to build the invoice before it becomes a finalized financial statement.

Posted Stage #

The Posted stage is the most important lifecycle milestone.

This is the point where the invoice becomes the official receivable for the customer. Totals, balances, charges, taxes, discounts, and due dates are established, and the invoice becomes part of the customer’s AR position.

From a business point of view, posting means:

the invoice now stands as the financial outcome of billing,
the customer balance has been updated,
and the invoice is ready to participate in downstream receivables, payment, and reporting processes.

Posting is also the point where the system records the invoice-posted financial transaction that feeds AR tracking and downstream export logic.

Closed Stage #

The Closed stage is best understood as a lifecycle milestone rather than the moment AR is created.

A closed invoice is one that has moved beyond working invoice management. It has already become a receivable through posting, and it is no longer being treated as a draft or in-progress billing result.

This distinction is important:

Posted answers the question, “Has this invoice become a financial receivable?”
Closed answers the question, “Is this invoice complete in the invoice lifecycle?”

For finance and engineering teams, that means posting is the primary financial event, while closure is part of the invoice management and lifecycle-control model around that posted document.

What Snapshot Invoices Are #

Snapshot invoices are best understood as reference or preview documents rather than standard AR invoices.

Their purpose is to show an expected billing picture before the authoritative invoice lifecycle completes. In other words, a snapshot invoice describes charges to come, but it is not the same thing as the posted invoice that establishes customer receivables.

This is an important distinction because snapshot invoices are useful for customer visibility and forecasting, but they should not be treated as the formal billing document that drives AR.

How Snapshot Invoices Fit #

From a lifecycle perspective, a snapshot invoice sits before the formal invoice lifecycle reaches its posted AR state.

That means:

it is informational,
it can help with customer communication and expectation setting,
but it is not the authoritative posted receivable.

The standard invoice-processing path is built around Open, Posted, and related processing statuses for the actual invoice record. Snapshot invoices do not appear as a standard invoice state in that core processing path.

The practical takeaway is simple:

use snapshot invoices as a preview or reference concept,
and use posted invoices as the source of truth for AR, payment application, and financial export.

Adjustments: Three Different Concepts #

When something about an invoice needs to change, it is important to distinguish between voids, reversals, and credits.

They are related, but they are not interchangeable.

Voids #

A void is the full withdrawal of an invoice as the valid billing result.

When an invoice is voided, the system does not simply mark it inactive. It performs a controlled unwind of that invoice’s billing impact by creating a separate voiding invoice and generating reversal entries for the original invoice items and related effects.

A void means:

the original invoice should no longer stand,
its billing impact needs to be taken back,
and the account should be returned to a state where correct billing can proceed.

This is why voiding is such a significant action. It is not just a document correction. It is a billing and financial reversal process.

What Happens When An Invoice Is Voided #

When an invoice is voided, the platform performs a structured unwind of the invoice and its billing impact.

This includes:

creating reversed transactions for items on the invoice,
detaching disbursements that were applied to the invoice,
rolling back account-package next bill dates and last billed dates where applicable,
marking billed usage as unbilled so it can be billed again correctly,
creating a new invoice containing the reversing charges,
and updating the account balance.

One especially important point is that voiding does not reverse collected payments. It unwinds the invoice and its billing state, but cash-handling outcomes such as refunds remain separate business actions.

This distinction helps teams avoid confusing invoice correction with customer reimbursement.

When To Void An Invoice #

Voiding should be treated as a significant corrective action, not the default answer to every invoice discrepancy.

If an invoice has already been delivered to the customer, it should generally only be voided when the invoice needs to be fully retracted and replaced. This is most appropriate when there is a major difference between what the invoice contains and what it should contain, and that difference cannot be handled cleanly on a later invoice.

Examples include:

usage that failed to process and left important charges off the invoice,
missing bucket or share-plan configuration that materially changed the billing outcome,
or other billing-state issues that mean the invoice itself is no longer a valid statement of charges.

If the invoice has not yet been delivered, voiding can also be used to unwind the billing process so the account can be corrected and billed again.

Once the needed corrections are made, the account can be billed again to create the corrected invoice. Where usage-related configuration is involved, rerating can occur before the new billing run so that usage charges are rebuilt accurately.

In general, invoices should not be voided unless their charges require significant correction or replacement.

Restrictions On Voiding #

Invoice voiding is intentionally controlled to protect billing integrity.

The most important restrictions are:

only the latest invoice on an account can be voided,
if reversal transactions are already associated with an invoice, those reversals must be removed before the invoice can be voided,
and invoice voiding is treated as a controlled process rather than an inline edit of the original invoice.

These restrictions matter because voiding changes billing chronology and financial history. Limiting when it can occur helps preserve a clean and traceable invoice record.

Reversals #

A reversal is the mechanism used to create the opposite of a previously created financial or billing entry.

Reversals are often system-generated as part of another process, especially invoice voiding. They preserve traceability by showing how the original value was unwound instead of silently deleting history.

Reversals are valuable because they:

preserve auditability,
keep the financial trail explicit,
and show exactly how a previous invoice or invoice item was offset.

In simple terms, a void is a business action, while a reversal is one of the accounting and billing mechanics used to execute that action.

Credits #

A credit is different from a void.

Instead of retracting the original invoice, a credit leaves that invoice in place and introduces a separate adjustment to reduce what the customer owes or to recognize value owed back to the customer.

This is typically the right approach when:

the original invoice should remain on record,
but some amount needs to be offset,
corrected,
or commercially adjusted.

From a customer and finance perspective, credits are often the cleaner option when the goal is to adjust the outcome without rewriting invoice history.

Voids Versus Credits #

The easiest way to separate the two is:

Void = the invoice itself should no longer stand.
Credit = the invoice should remain, but the amount due needs an offset or adjustment.

That distinction matters because voids reopen and unwind billing impact, while credits adjust the financial outcome around an invoice that remains part of the billing record.

Most invoice issues do not require a void. Many problems can be handled more cleanly through credits, reversals into the next invoice period, a credit note, or a forward manual charge or manual credit.

When Reversals Appear #

Reversals can appear in more than one scenario.

They may be created:

when an invoice is voided,
when a previously created credit-related entry is unwound,
or when the system needs to produce the opposite side of a previously posted billing effect.

For finance and engineering teams, the important principle is that reversals are the preservation mechanism for historical integrity. Instead of erasing prior financial events, the system records the equal-and-opposite outcome needed to unwind them.

Impact On The General Ledger #

The General Ledger should receive the financial events that matter for accounting, while LogiSense Billing remains the detailed AR subledger and source of truth.

With that in mind, the GL impact of invoice lifecycle events is best understood as follows.

Draft Or Open Invoice #

A draft or open invoice is still in the working stage of invoice creation.

At this point, it is not yet the finalized AR event that should drive financial export in the same way as a posted invoice.

Posted Invoice #

A posted invoice is the core receivables event.

This is the stage where the invoice becomes an authoritative AR amount for the customer, and it is the primary lifecycle point that should drive invoice-related GL export and AR reporting.

Closed Invoice #

Closing an invoice is primarily a lifecycle-control event around a posted document.

The invoice has already become AR through posting. Closing does not replace posting as the core receivables event. Instead, it reflects that the invoice has moved beyond its active working lifecycle.

Snapshot Invoice #

A snapshot invoice is informational and should not be treated as the formal AR event.

Because it is a preview or reference concept rather than the authoritative posted receivable, it should not carry the same GL impact as the posted invoice.

Void And Reversal #

When an invoice is voided, the GL model should reflect the reversal of the original posted financial effect rather than simply pretending the invoice never existed.

That means the accounting view should be built around reversing the previously recognized invoice impact through explicit reversal events.

Credit #

A credit should be understood as its own financial adjustment event.

It does not mean the original invoice disappeared. Instead, it introduces offsetting value into the customer financial position. Depending on the financial model, the credit event itself and its later application to invoices may have different accounting meanings.

A Practical Way To Choose The Right Adjustment #

When deciding how to correct an invoice outcome, a useful rule is:

use a void when the invoice itself is wrong and should be fully withdrawn,
use a credit when the invoice should remain but the customer outcome needs to be reduced or corrected,
and understand reversals as the traceable mechanism that unwinds prior financial entries.

This helps teams avoid using one tool for every scenario and reduces unnecessary rebilling complexity.

Another practical rule is:

if the invoice needs to be fully taken back and replaced, use a void,
if the invoice should stay on record and only the amount needs correcting, prefer a credit, credit note, reversal, or forward adjustment.

A Simple Example #

Imagine an invoice is posted for $1,000.

Scenario 1: The Invoice Should Never Have Been Issued #

The business determines the invoice was fundamentally wrong.

Best fit:

Void the invoice

Result:

the original invoice is withdrawn,
reversal activity is created,
and the billing impact is unwound so corrected billing can proceed.

Scenario 2: The Invoice Is Valid, But The Customer Deserves A Reduction #

The business wants to reduce the amount by $200, but the original invoice should still remain part of the customer history.

Best fit:

Issue a credit

Result:

the invoice remains on record,
the credit offsets part of the customer’s obligation,
and the adjustment is preserved as a separate event.

Scenario 3: Finance Needs To Explain The Accounting Trail #

The finance team needs to show how a previously posted amount was undone.

Best fit:

explain the reversal entries created by the adjustment process

Result:

the accounting trail remains explicit,
and history is preserved rather than overwritten.

Why This Matters #

The invoice lifecycle is one of the core controls in a billing system.

If teams do not clearly distinguish between working invoices, posted receivables, informational previews, and different types of adjustments, they can create confusion in billing operations, customer communication, AR management, and financial export.

A strong operating model is built on a simple principle:

posted invoices establish receivables,
closed invoices represent lifecycle completion,
snapshot invoices are informational,
voids fully retract invoices,
reversals unwind prior effects,
and credits adjust customer obligation without erasing invoice history.

That is the foundation for understanding invoice lifecycle and adjustments in LogiSense Billing.

Still stuck? How can we help?