Core Data Model Guide: How Billing Objects Relate

Last verified with: 10.8.6.0

Overview #

LogiSense Billing is designed as a connected operating model. At a high level, the platform starts with customer and catalog structure, links that structure to pricing, rates and bills activity, and then carries the financial result through invoicing and payment.

That relationship is what gives the platform its flexibility. Businesses can reuse catalog objects across many customers, while still creating customer-specific subscriptions, pricing, billing schedules, usage behavior, and financial outcomes.

The Core Flow #

The simplest way to understand the model is as a flow:

Account -> Package -> Service -> Rate Plan -> Usage -> Invoice -> Payment

It is helpful to think about the flow in two connected layers.

Catalog layer

Package = the reusable commercial offer that a business brings to market. It defines the subscription or bundle structure being sold, and acts as the container that groups related billable components into one customer-facing offering.
Service = the reusable billable component inside a package. Services are the individual elements that carry recurring pricing, one-time pricing, usage behavior, taxation behavior, and service lifecycle behavior.
Usage Rate Plan = the reusable usage pricing logic attached to usage-based services. It determines how measured consumption is evaluated and charged, so the same rating approach can be reused across multiple packages, services, or customer scenarios.

Customer layer

Account = the customer relationship, including the billing, tax, and receivables context that drives downstream behavior.
Account Package = the customer’s subscribed package, created when a catalog offer is assigned to that customer.
Account Service = the customer’s subscribed service within that package, representing the actual billable component held by that customer.
Usage = the activity generated by that subscribed service and priced according to the applicable rating logic.
Invoice = the receivable created from recurring charges, one-time charges, usage charges, taxes, credits, and balances.
Payment = the cash collected and applied against that receivable.

Put together, the model works like this:

A business defines reusable Packages, Services, and Usage Rate Plans in the catalog.
A customer is created as an Account.
A catalog package is sold to that account, creating an Account Package.
The services inside that package are instantiated as Account Services.
If the service is usage-based, the applicable Usage Rate Plan prices the customer’s consumption.
Recurring charges, one-time charges, and rated usage flow onto the Invoice.
Payments are then collected and applied against the resulting balance.

This view shows both the catalog side and the customer-instance side of the model.

Package and Service are reusable catalog definitions.
Account Package and Account Service are the customer-specific instances created from those catalog definitions.
Usage Rate Plans provide the reusable usage pricing logic that can be attached to the customer-facing service structure.
Invoices bring together recurring charges, non-recurring charges, usage charges, taxes, credits, and balances.
Payments are then collected and applied against those invoice balances.

Start With The Account #

The Account is the main customer record in the billing system.

It holds the business relationship and operational defaults that drive downstream billing behavior, such as currency, bill day, usage bill day, bill group, receivables terms, tax context, and invoicing relationships.

This matters because billing does not start at the price. It starts with who is being billed, under what terms, on what schedule, and in what commercial relationship.

Invoicer Versus Account #

One of the most important relationship concepts in LogiSense Billing is the difference between the operational account and the invoicing account.

The Account is the customer or service-holding entity.

The Invoicer is the account that financially receives the invoice.

In many simple scenarios, they are the same. In more advanced B2B, channel, parent-child, or consolidated billing scenarios, they can be different.

That distinction allows businesses to:

hold services on one account,
consume usage on one account,
and still invoice a parent, partner, or consolidated bill-to entity.

This is especially valuable when the service relationship and the financial relationship are not identical.

Packages And Services #

Packages and Services work together, but they solve different business problems.

A simple way to remember the distinction is:

Package = what you sell.
Service = what you bill within that sale.

What A Package Represents #

A Package is the commercial bundle, offer, or subscription structure.

It defines the offering that is sold to the customer, including package behavior such as billing cadence, package category, activation behavior, and the overall commercial container for included services.

A package answers the question:

What is the customer buying as an offer?

What A Service Represents #

A Service is the individual billable component inside that offer.

A service is the thing that can actually carry recurring pricing, non-recurring pricing, status behavior, usage behavior, taxation behavior, and in many cases operational meaning.

A service answers the question:

What specific component are we charging for inside the offer?

Why The Distinction Matters #

This separation is one of the platform’s biggest catalog strengths.

It allows businesses to:

reuse the same service across many packages,
create multiple offers from common service building blocks,
vary commercial packaging without rebuilding every billable component,
and keep the catalog cleaner as pricing options grow.

In simple terms:

Package is the commercial wrapper.
Service is the billable component inside the wrapper.

Account Packages And Account Services #

Once a package is sold to a customer, it becomes an Account Package.

Once the services inside that package are instantiated for that customer, they become Account Services.

This is where the model shifts from reusable catalog design to customer-specific billing operations.

This is often the point where the model becomes clear:

the catalog defines what is possible,
and account-level objects define what this specific customer actually has.

Account Package #

An Account Package is the customer’s actual subscription instance.

It carries customer-level values such as:

the account relationship,
effective and cancellation dates,
next bill and last billed tracking,
billing and usage bill day behavior,
quantity,
price book context,
contract linkage,
and package-level billing status.

This is the object that says:

This customer has this package, under these dates and billing rules.

Account Service #

An Account Service is the customer-specific version of a service inside that account package.

It ties the service definition to the customer and the customer’s package instance, and it carries customer-level timing and service billing details such as:

which service it is,
which account package it belongs to,
effective and cancellation timing,
billing history,
usage billing history,
amount overrides where applicable,
and service-level tax behavior.

This is the object that says:

This customer has this specific billable service inside this specific subscription.

Why Customer-Level Instances Matter #

If the platform only had catalog objects, every customer would have to behave exactly like the default catalog definition.

By creating Account Packages and Account Services, LogiSense Billing can preserve catalog reuse while still supporting customer-specific lifecycle management, pricing overrides, contracts, usage buckets, share plans, status changes, and billing history.

That is a major reason the platform can support both standard offers and highly negotiated enterprise billing models without duplicating the catalog.

Where Rate Plans Fit #

For usage-based charging, the Usage Rate Plan is the pricing layer that turns measured consumption into billable amounts.

A rate plan is a reusable pricing construct that groups together the usage pricing logic needed to rate activity for a service.

From a business perspective, that means:

the Service defines what is being sold,
the Account Service defines who has it,
and the Usage Rate Plan defines how its consumption should be priced.

This separation makes it possible to reuse the same service with different pricing strategies, or reuse the same rating logic across many services and packages.

How Usage Connects To The Model #

Usage enters the platform as a structured record, is mediated into a normalized usage event, and is then rated against the applicable pricing logic.

At the rated stage, usage is explicitly tied to the customer service context. In practice, rated usage is associated to an Account Service, a resolved usage classification, and the Usage Rate Plan that produced the charge.

That means usage is not just floating activity. It is financially connected to:

the customer,
the subscribed service,
the applicable pricing logic,
and ultimately the invoice outcome.

This is what allows the platform to support sophisticated usage pricing while still keeping billing traceable back to a customer-facing subscription structure.

How Charges Reach The Invoice #

The Invoice is where the different billing outcomes are brought together into a customer receivable.

An invoice can contain charges generated from:

account packages,
account services,
rated usage,
taxes,
discounts,
prior balances,
credits,
and payment application history.

This is one of the most important things to understand about the model: invoices are not standalone financial documents created in isolation. They are the result of the relationships built earlier in the model.

Catalog setup becomes customer subscriptions. Customer subscriptions become billable events. Billable events become invoice balances.

How Payments Complete The Flow #

The Payment object represents money collected against the customer’s receivable position.

Payments are tracked at the account level and can then be attached, disbursed, applied, reversed, refunded, or otherwise processed according to the payment lifecycle.

From a data model perspective, payment is the financial step that follows invoicing. It does not replace the invoice relationship. It operates against it.

That distinction is important because a payment event and an invoice balance are related, but they are not the same object and they do not play the same role.

Key Relationships To Understand #

There are a few relationships that make the whole model easier to understand.

1. Account To Account Package #

An account can have many account packages.

This allows one customer relationship to hold multiple active subscriptions or offers at the same time.

2. Package To Account Package #

A package is the reusable catalog definition.

An account package is the instantiated version of that package for one specific customer.

3. Account Package To Account Service #

An account package contains the customer-specific services that were instantiated as part of that package.

This is how the platform knows which billable components belong to which subscribed offer.

4. Service To Account Service #

A service is the reusable billable component definition.

An account service is the customer-specific instance of that service.

5. Account Service To Usage Rate Plan #

For usage-based services, the account service can be associated with the rate plan logic that prices consumption.

This is the connection between subscription structure and usage monetization.

6. Account Service To Usage #

Rated usage is linked to the customer service that generated or owns that usage charge.

This is what keeps usage billing attributable and traceable.

7. Account Package, Account Service, And Usage To Invoice #

Invoice items are produced from package-level, service-level, and usage-level billing outcomes.

This gives the invoice a clear lineage back to the commercial and operational objects that created it.

8. Account And Invoice To Payment #

Payments exist at the customer financial level and then affect invoice balances through attachment, disbursement, and application behavior.

A Simple Example #

It can help to see the model as one complete story.

Imagine a business sells a connectivity package with one recurring access service and one usage-based data service.

The business creates a Package called Business Connectivity.
Inside that package, it uses two Services: one recurring access service and one usage-based data service.
The data service uses a reusable Usage Rate Plan that defines how data consumption is priced.
A customer is created as an Account.
The package is assigned to that customer, creating an Account Package.
The two services inside the package are instantiated as Account Services for that customer.
During the month, the customer generates Usage on the data service.
At billing time, the platform combines recurring charges and rated usage onto an Invoice.
When the customer pays, a Payment is recorded and applied to the invoice balance.

That single example shows how the objects are related:

catalog definitions become customer instances,
customer instances generate billable activity,
and billable activity becomes receivables and payments.

Why This Model Is Important #

The value of this model is not just technical organization. It directly supports better commercial flexibility.

Because LogiSense Billing separates reusable catalog definitions from customer-specific instances and financial outcomes, businesses can:

build reusable product and service catalogs,
avoid duplicating setup for every customer,
support parent-child or consolidated invoicing,
apply different pricing logic to similar services,
trace usage back to the subscribed customer service,
generate invoices from clear billing lineage,
and manage payments against the resulting receivables.

In other words, the platform is structured to let businesses reuse what should be reusable, specialize what needs to be customer-specific, and still keep the whole billing lifecycle connected end to end.

A Simple Way To Think About It #

If you want a practical mental model, think of the objects this way:

Account = who the business relationship belongs to.
Invoicer = who financially receives the bill.
Package = the offer being sold.
Service = the billable component inside the offer.
Account Package = that customer’s subscribed package.
Account Service = that customer’s subscribed service within the package.
Usage Rate Plan = the reusable pricing logic for measured consumption.
Usage = the metered activity being priced.
Invoice = the receivable created from charges and balances.
Payment = the cash event that reduces or settles that receivable.

That is the core data model of how billing objects relate in LogiSense Billing.

Still stuck? How can we help?