Financial GL Export and AR Reporting

Last verified with: 10.8.6.0

Overview #

Financial GL Export and AR Reporting in LogiSense Billing is built around a simple but important principle:

LogiSense Billing is the system of record for customer accounts receivable.

That means the billing platform is where the business determines:

• what the customer owes,
• what has been billed,
• what has been paid,
• what has been applied,
• what remains unapplied,
• and what the customer’s true financial position is.

The General Ledger serves a different role. It receives the financial events that should be reflected in accounting, but it is not the place where invoice-level allocation, AR ageing, and customer balance management are actively controlled.

This distinction matters because it explains why some events should be exported to the General Ledger and others should remain internal to billing.

General Ledger AR Versus the AR Subledger #

It is helpful to start with a clear distinction between two related but different layers of receivables:

• the Accounts Receivable balance in the General Ledger,
• and the customer-level AR subledger in LogiSense Billing.

The General Ledger holds the summarized accounting position. It reflects the financial events that matter for accounting and financial reporting, including the total receivables position that the business is carrying.

LogiSense Billing serves as the AR subledger. It is the customer-level operational record that tracks:

• individual invoice balances,
• payment and credit allocations,
• unapplied payments,
• unapplied credits,
• invoice due dates,
• and AR ageing.

This distinction is important because the General Ledger answers questions like:

• what is the business’s total receivables position,
• what financial events need to be recognized,
• and what should appear in accounting output.

The AR subledger answers different questions:

• which customer owes what amount,
• which invoice is still open,
• which payments have been applied,
• which amounts remain unapplied,
• and how old each receivable is.

This is the foundation for the rest of the guide. The General Ledger holds the summarized AR balance, while LogiSense Billing is the source of truth for the customer-level AR detail behind that balance.

Simple AR Subledger Examples #

Sometimes the easiest way to understand the relationship is to think of the General Ledger AR balance as the sum of the customer-level AR balances managed in the subledger.

Example 1: Simple Customer-Level AR Rollup #

• Customer 1 AR = $1,000
• Customer 2 AR = $2,500
• Customer 3 AR = $500

Total AR in the General Ledger = $4,000

This is the simplest conceptual model:

• the subledger holds the customer-by-customer detail,
• and the General Ledger reflects the summarized financial position derived from that detail.

Example 2: Unapplied Payment #

Customer 1:

• Invoice = $1,000
• Payment received = $600, but not yet applied
• AR balance = $1,000

Customer 2:

• Invoice = $2,500
• Payment applied = $2,500
• AR balance = $0

Customer 3:

• Invoice = $500
• No payment received
• AR balance = $500

Result:

• Total AR in the General Ledger = $1,500
• Unapplied cash in a separate General Ledger account = $600

This highlights two important points:

• AR is based on invoice status and application status, not just on whether cash has been received.
• The subledger tracks the application detail, while the General Ledger reflects the summarized financial position.

Example 3: Credit Applied #

Customer 1:

• Invoice = $1,000
• Credit applied = $200
• AR balance = $800

Customer 2:

• Invoice = $2,500
• Fully paid
• AR balance = $0

Customer 3:

• Invoice = $500
• No activity
• AR balance = $500

Result:

• Total AR in the General Ledger = $1,300

This highlights another key principle:

• AR is reduced when value is applied at the invoice level.
• The subledger explains exactly how that reduction happened, whether by payment, credit, or other adjustment.

The Core Principle #

The most important concept in this guide is that financial events and allocation events are not the same thing.

A financial event changes the accounting reality of the business.

An allocation event changes how that value is distributed inside the billing system.

That is why LogiSense Billing separates:

• receiving value,
• applying value,
• and presenting value.

This separation is what allows the billing platform to remain the source of truth for AR while still sending the right events outward for financial accounting.

Terminology Alignment #

Payments #

Current Product Term	Industry Term	Meaning
Applied	Payment Received	A payment has been successfully collected from the customer.
Disbursed	Payment Applied	A collected payment has been allocated to one or more invoices.
Issued	Payment Displayed	A payment is being shown on an invoice or document for presentation purposes.

Credits #

Product Term	Industry Term	Meaning
Applied	Credit Issued	A credit has been created as a financial event.
Disbursed	Credit Applied	A credit has been allocated to one or more invoices.
Issued	Credit Displayed	A credit is being shown on an invoice or document for presentation purposes.

Refunds and Chargebacks #

Product Term	Industry Term	Meaning
Refund	Refund	Cash or collected value is returned to the customer.
Chargeback	Chargeback	Previously collected value is forced back due to dispute or bank action.

Why This Terminology Matters #

This terminology matters because many billing and finance misunderstandings come from assuming that a payment being applied in one context means the same thing as a payment being applied in another.

In LogiSense Billing:

• a payment being received is the commercial and financial event,
• a payment being disbursed is the allocation event inside AR,
• and a payment being issued on a document is a presentation event.

Those are three different business meanings.

Billing as the AR System of Record #

LogiSense Billing is the place where AR is actively managed.

That includes:

• invoice balances,
• due dates,
• ageing,
• unapplied payments,
• unapplied credits,
• payment application,
• credit application,
• and the customer’s net financial position.

This is why the billing platform is the source of truth for AR rather than the General Ledger.

The platform knows not only that value exists, but also:

• whether it has been billed,
• whether it has been applied,
• which invoice it is tied to,
• and what balance still remains collectible.

What AR Means in This Model #

In this model, AR is invoice-based.

That means receivables are driven by posted invoice balances, and those balances are reduced only when value is actually applied to them.

This is a key rule:

• issuing a credit does not reduce invoice AR by itself,
• receiving a payment does not reduce invoice AR by itself,
• AR is reduced when that credit or payment is applied to the invoice.

That distinction is what keeps invoice-level receivable reporting accurate.

The AR Reporting Structure #

At a business level, customer position can be understood as the combination of:

• Invoice Balance
• Pending (Unbilled)
• Unapplied Payments
• Unapplied Credits

In practical terms:

• Invoice Balance is billed AR,
• Pending is value not yet invoiced,
• Unapplied Payments are collected amounts not yet allocated,
• Unapplied Credits are issued credits not yet allocated.

This is what allows the business to separate what is owed, what is waiting to bill, and what value is sitting on the account but not yet attached to a specific invoice.

The Difference Between Financial Events and Allocation Events #

This is the heart of the model.

Financial Events #

Financial events are the events that should be exported to the General Ledger because they represent a true economic change.

Examples include:

• invoice posting,
• payment received,
• credit issued,
• refund,
• chargeback,
• write-off,
• and certain account-closure reallocations.

Allocation Events #

Allocation events describe how existing value is applied inside billing.

Examples include:

• payment applied to invoice,
• and credit applied to invoice.

These events matter deeply for AR management, but they are not the same thing as new economic events.

What Triggers Financial Export to the General Ledger #

At a business level, the General Ledger should receive the events that represent actual financial activity, not merely internal allocation movement.

That means the export trigger points are the moments where value is created, changed, reversed, or formally recognized.

The main trigger categories are:

• Invoice Posted
• Payment Received
• Credit Issued
• Refund
• Chargeback
• Write-off
• and certain closure-related reallocations

This is one of the most important design principles in the guide:

• the General Ledger receives the event that changed the business financially,
• the billing system retains responsibility for how that value is applied inside AR.

Invoice Posted as a Financial Event #

When an invoice is posted, that is the moment the billed receivable becomes formal.

Business meaning:

• the customer has been billed,
• the receivable now exists at the invoice level,
• and the invoice becomes part of AR reporting and ageing.

This is the starting point for most downstream AR behavior.

Payment Received as a Financial Event #

When a payment is successfully received, that is a financial event.

Business meaning:

• the business has collected value from the customer,
• but that does not automatically mean a specific invoice balance has been reduced yet.

If the payment has not been disbursed to an invoice, it remains unapplied payment value on the account.

This is why payment receipt and payment application must not be treated as the same thing.

Credit Issued as a Financial Event #

When a credit is created, that is also a financial event.

Business meaning:

• value has been created in favor of the customer,
• but that value has not necessarily reduced a specific invoice yet.

Until the credit is applied, it remains unapplied credit value rather than invoice-level AR reduction.

Refund and Chargeback as Financial Events #

Refunds and chargebacks are also exported as financial events because they reverse or reduce previously recognized value.

Business meaning:

• a refund returns value to the customer,
• a chargeback forcibly removes previously collected value,
• and both require the customer’s financial position to be recalculated.

These events are especially important because they often happen after value has already been applied inside AR, which means the billing platform must also unwind internal allocation where appropriate.

What Does Not Trigger GL Export by Default #

The most important events that do not trigger General Ledger export by default are the routine allocation events:

• payment applied to invoice,
• credit applied to invoice.

These events are essential to AR operations, but they are internal allocation steps rather than new financial events.

This is the foundation of the model:

• financial exports follow economic events,
• AR reporting follows allocation and invoice satisfaction.

Exception for Account Closure #

There is one important exception: certain allocation events tied to account closure may need to be exported.

The reason is that account closure is not ordinary ongoing allocation behavior. It is a final settlement condition that may require explicit financial treatment.

The most important takeaway is this:

• standard allocation events stay inside billing,
• but account-closure settlement logic can require different treatment because it is part of final account resolution.

Example Flow 1: Invoice to Payment to Full Application #

This is the simplest end-to-end example.

Step 1: Invoice is Posted #

The customer is billed for $500.

Business result:

• invoice balance becomes $500,
• that $500 becomes part of AR,
• and the invoice enters ageing based on its due date.

General Ledger trigger:

• Invoice Posted

Step 2: Payment is Received #

The customer makes a payment of $500.

Business result:

• the business has received value,
• but until that payment is applied, invoice AR is still $500,
• and the payment exists as received value waiting to be allocated.

General Ledger trigger:

• Payment Received

Step 3: Payment is Applied to the Invoice #

The $500 payment is disbursed to the $500 invoice.

Business result:

• invoice balance becomes $0,
• AR is reduced,
• and the receivable is satisfied.

General Ledger trigger:

• none for the normal allocation event itself

This example is the clearest illustration of why the billing system is the AR source of truth. It is the platform that knows when the receivable was actually satisfied.

Example Flow 2: Invoice to Partial Payment #

Now take the same invoice for $500, but the customer only pays $300.

Step 1: Invoice is Posted #

Business result:

• invoice balance is $500,
• AR is $500.

General Ledger trigger:

• Invoice Posted

Step 2: Payment of $300 is Received #

Business result:

• the business has collected $300,
• but invoice AR is still $500 until that payment is applied.

General Ledger trigger:

• Payment Received

Step 3: Payment is Applied #

The $300 is disbursed to the invoice.

Business result:

• invoice balance falls from $500 to $200,
• the invoice remains open in AR,
• and the customer still owes $200.

General Ledger trigger:

• none for the normal allocation event itself

This flow shows that AR reduction is driven by application, not by receipt alone.

Example Flow 3: Overpayment #

Assume an invoice balance of $500, and the customer pays $700.

Step 1: Invoice is Posted #

Business result:

• invoice balance is $500,
• AR is $500.

General Ledger trigger:

• Invoice Posted

Step 2: Payment of $700 is Received #

Business result:

• the business has collected $700,
• and the account now carries $700 of received payment value.

General Ledger trigger:

• Payment Received

Step 3: $500 is Applied to the Invoice #

Business result:

• invoice balance becomes $0,
• $200 remains as unapplied payment value,
• and that excess remains a customer liability until it is allocated or refunded.

General Ledger trigger:

• none for the ordinary application itself

This example is important because it shows that overpayments should not be treated as revenue simply because the cash was received. Billing still has to track the remaining unapplied amount correctly.

Example Flow 4: Refund After Payment Application #

Assume an invoice for $500 has already been fully paid by a $500 payment.

Step 1: Invoice is Posted #

General Ledger trigger:

• Invoice Posted

Step 2: Payment is Received #

General Ledger trigger:

• Payment Received

Step 3: Payment is Applied #

Business result:

• invoice balance becomes $0.

Step 4: Refund of $200 is Issued #

Business result:

• $200 of previously recognized collected value is returned,
• the billing platform must reopen that amount on the invoice or customer balance position,
• and the customer again owes $200 unless another available value source satisfies it.

General Ledger trigger:

• Refund

This flow shows why billing must remain the AR source of truth. The General Ledger can know a refund happened, but the billing system is what knows which receivable position has now reopened.

Example Flow 5: Chargeback After Payment Application #

Assume an invoice for $500 has been fully paid and later a $500 chargeback occurs.

Step 1: Invoice is Posted #

General Ledger trigger:

• Invoice Posted

Step 2: Payment is Received #

General Ledger trigger:

• Payment Received

Step 3: Payment is Applied #

Business result:

• invoice balance becomes $0.

Step 4: Chargeback Occurs #

Business result:

• the previously collected value is forcibly removed,
• the billing platform must unwind the satisfied receivable position,
• and the customer’s balance becomes due again according to the amount affected.

General Ledger trigger:

• Chargeback

This is one of the strongest examples of why AR and GL must not be confused. The chargeback is the accounting event, but billing is what determines how the customer’s invoice-level truth changes.

Why AR Ageing Belongs in Billing #

AR ageing is driven by invoice due dates and remaining invoice balances.

That makes billing the right place to measure:

• current receivables,
• overdue receivables,
• how long a balance has remained open,
• and what customer amount is still collectible.

The General Ledger may reflect the financial events, but it is not the operational tool for invoice-level ageing and customer balance control.

Why Customers Value This Capability #

Customers value this model because it gives them a clean separation between:

• financial recognition,
• receivables management,
• and invoice allocation.

That means they can:

• use LogiSense Billing as the operational truth for AR,
• export the correct financial events to accounting,
• avoid confusing payment receipt with invoice satisfaction,
• and report accurately on open invoices, unapplied cash, unapplied credits, refunds, and disputes.

Summary #

Financial GL Export and AR Reporting in LogiSense Billing is built on a simple but powerful model:

• billing is the system of record for AR,
• the General Ledger receives the true financial events,
• invoice balance reduces only when value is applied,
• and unapplied payments and credits remain distinct until they are allocated.

That is what allows the platform to support accurate AR reporting, cleaner financial exports, and better alignment between billing operations and accounting outcomes.