Overview #
LogiSense Billing is designed to work as part of a broader quote-to-cash landscape. A CRM, CPQ platform, order-management system, or custom application can manage the sales process, while LogiSense Billing manages the billable product catalog, customer subscriptions, usage, invoices, and payments.
This guide presents a vendor-neutral approach to connecting those systems. It explains how information typically moves from an approved quote or order into LogiSense Billing and how billing results can be shared with the rest of the business.
In a typical integration:
- The CRM or CPQ system manages leads, opportunities, quotes, approvals, and the sales experience.
- LogiSense Billing manages the billable catalog, standard pricing, subscriptions, billing, invoices, and payments.
- The integration carries approved customer and order information between the two.
This separation allows sales teams to continue working in their preferred tools while keeping the rules used for billing in the system that applies them.
An approved quote and a billing order serve different purposes. A quote records the commercial agreement. Once approved, it can be used to establish customer-specific pricing, create an order for fulfillment and billing, or both.
For field-level request and response details, see the LogiSense API Reference and select an API version supported by your environment.
How LogiSense Fits into the Integration #
Before implementation begins, agree on which system owns each type of information. Clear ownership reduces duplicate records and prevents conflicting updates.
| Business information | Typical system of record | How the integration uses it |
|---|---|---|
| Prospects, opportunities, quotes, and approvals | CRM or CPQ | Determines when a customer or transaction is ready for billing. |
| Standard products, packages, services, price books, and usage pricing | LogiSense Billing | Makes billable offers available to the selling system. |
| Customer identity and sales contacts | CRM or customer master | Creates or updates the corresponding account and contacts in LogiSense Billing. |
| Billing settings, invoice relationships, tax information, and payment terms | LogiSense Billing | Applies the billing configuration associated with the customer and order. |
| Negotiated customer pricing | CRM or CPQ for approval; LogiSense Billing for billing | Records approved pricing as customer-specific or order-specific pricing. |
| Orders and requested effective dates | CRM, CPQ, or order-management system | Creates a draft order in LogiSense Billing and submits it when approved. |
| Customer subscriptions | LogiSense Billing | Creates account packages and services when the order is processed. |
| Invoices, payments, balances, and billing status | LogiSense Billing | Shares financial results with other systems when required. |
Choosing a Catalog Ownership Model #
The most common approach is to maintain the billable catalog and standard pricing in LogiSense Billing. The integration makes eligible products and prices available in the CRM or CPQ system, where sales teams can build quotes using the same catalog relationships that will later be used for billing.
This billing-led model helps keep package structure, service configuration, currencies, price books, recurring charges, and usage rates aligned with the way they are billed.
Some businesses prefer the CPQ system to own the product catalog. This model is also possible, but the integration must create and maintain all of the LogiSense catalog relationships needed for billing before a product can be ordered. A product that is ready to quote may still require billing, tax, usage-rating, or lifecycle configuration in LogiSense Billing.
A hybrid model is often a practical middle ground. LogiSense Billing owns billable products and standard prices, while the CPQ system controls product presentation, bundles, discount approvals, and negotiated terms. The approved result is then mapped to the corresponding LogiSense products and pricing.
Ways to Connect #
An implementation can combine several integration methods.
| Integration method | Common use |
|---|---|
| Versioned REST APIs | Create, retrieve, and update customers, pricing, orders, invoices, and payments. |
| Hierarchical requests | Submit an account with its contacts or an order with its packages, services, prices, charges, and shipping information as a single related structure. |
| Search and retrieval APIs | Match records across systems and support ongoing reconciliation. |
| Status and tracking APIs | Follow asynchronous work such as order processing. |
| Outbound webhooks | Notify other systems about supported account, service, invoice, payment, and other business events. |
| Data imports | Support migrations, backfills, and high-volume batch activity. |
REST APIs are normally used for interactive customer and order workflows. Data imports can complement them when large volumes of information need to be loaded or updated together.
Webhook delivery and order processing are asynchronous. The originating request can complete before all downstream work is finished, so integrations should track the resulting status rather than treating the initial response as the final business outcome.
Keeping Records Connected #
A reliable integration maintains a relationship between the identifier used in the selling system and the identifier returned by LogiSense Billing.
For example, the upstream customer identifier can be stored as the external account identifier in LogiSense Billing, while the LogiSense account ID is stored in the CRM or integration platform. The same approach can be used for orders and other records that provide an external reference.
External identifiers make records easier to match, but the integration remains responsible for preventing duplicates. A good identifier strategy includes:
- a stable customer and order identifier in the upstream system;
- the corresponding LogiSense identifiers;
- a lookup before creating a record;
- both identifiers in integration logs and reconciliation reports;
- a recovery check before repeating a create request when the original result is unknown.
This approach allows the integration to recover cleanly from interruptions without creating a second customer or order.
A Typical Integration Journey #
The exact sequence depends on the business process, but most CRM and CPQ integrations follow the same broad path.
1. Connect Securely #
The integration requests an access token from the Authorization Server and uses that token to call the Resource Server. Tokens are renewed or refreshed as required.
Integration credentials should be separate from interactive user accounts and limited to the roles and owner access needed by the integration.
2. Load Shared Reference Data #
Before creating customers or orders, the integration retrieves the reference values used by the target LogiSense environment. These commonly include:
- currencies;
- account types and statuses;
- bill groups and accounts receivable terms;
- contact types and address information;
- price books and regions;
- package frequencies, product codes, contracts, promo codes, and order statuses.
These values can be cached and refreshed on a schedule. Because identifiers can differ between environments, the integration resolves them separately in each environment instead of copying numeric IDs from one environment to another.
3. Create or Update the Customer #
When a customer becomes ready for billing, the integration checks whether a corresponding LogiSense account already exists. It then creates or updates the account with the required currency, billing settings, payment terms, invoicing relationships, tax information, and parent relationship where applicable.
Contacts, addresses, and contact points such as email addresses and telephone numbers can be included with the account. Sending the related information together allows LogiSense Billing to validate the customer hierarchy as one business operation.
The integration should also define how changes flow after the account is created. For example, the CRM may continue to own the customer name and sales contacts, while LogiSense Billing owns bill groups, invoicing relationships, and other billing settings.
4. Make the Catalog Available to Sales #
In the recommended billing-led model, the integration retrieves the active price books, packages, package frequencies, services, and pricing needed by the selling process.
The CRM or CPQ representation does not need to copy every internal billing object. It does need to preserve the relationships that affect ordering and pricing, including:
- the package and billing frequency;
- currency and price-book context;
- included, optional, and add-on services;
- quantity rules;
- recurring, one-time, transition, and usage pricing available to the seller;
- applicable contracts, product codes, promo codes, and regional rules.
The upstream system keeps the LogiSense identifiers it will need when the approved quote is converted into an order. Catalog data can be refreshed on a schedule or when administrators publish relevant changes.
5. Apply Negotiated Pricing When Needed #
An approved quote may establish pricing that should be used for future purchases or for a defined contract period. In this case, the integration can create an Account Price Plan in LogiSense Billing.
An Account Price Plan keeps customer-specific recurring, one-time, transition, discount, and usage pricing separate from the standard catalog. It can also define whether the pricing applies only to one account or can be inherited by child accounts.
When an approved price applies only to a single purchase, supported order-level pricing may be a better fit. The integration design should establish which option is used for each type of sales agreement so the result is predictable for both sales and billing teams.
6. Create the Draft Order #
Once the customer exists and the approved products have been mapped to the catalog, the integration creates a draft order. Depending on the sale, the order can include:
- the customer, price book, external order number, purchase order number, and account contract;
- package frequencies, quantities, product codes, and effective dates;
- service quantities, statuses, effective dates, add-ons, and attributes;
- eligible price changes;
- usage identifiers, rate plans, tax addresses, and other service details;
- manual charges;
- shipping contact and address information.
The order and its related details can be submitted as one hierarchy and validated together. Draft orders can be updated while the upstream order is still being finalized. Failed orders can be corrected when they remain eligible for editing.
After processing begins, changes are handled through the appropriate customer lifecycle operation or a new transaction rather than by rewriting the completed order.
7. Submit the Order #
When the upstream order has passed the required approvals, the integration submits it for processing.
The order can create the customer subscriptions without billing immediately, or it can start an immediate billing flow. When immediate billing is selected, the request can also include invoice delivery, payment collection, currency exchange, posting date, and payment-method options where applicable.
The submission response confirms that processing has been accepted. Subscription creation, billing, payment collection, invoice rendering, and delivery may continue after that response.
8. Follow the Processing Status #
The integration checks the order status and package-tracking information until processing reaches a final result. Tracking information connects each order package with the account package created for the customer and provides details when processing cannot be completed.
Order status is normally followed through the status and tracking APIs. Webhooks can complement this process for supported downstream events, but they should only be used when the required event is available in the target environment.
9. Share Billing Results #
After the order is complete, the integration can retrieve the resulting account packages and services for use by fulfillment, provisioning, support, or reporting systems.
If the order included immediate billing, invoices and payments are reconciled separately because each follows its own lifecycle. Supported outbound webhooks can notify other systems about events such as account changes, service-status changes, invoice posting or delivery, and payment activity.
API Sequence at a Glance #
The following paths show the main API families involved in the journey. They are not complete request definitions. Replace <api-version> with a version supported by the target environment and use the API Reference for required fields and response details.
| Step | Purpose | Representative request |
|---|---|---|
| 1 | Obtain an access token | POST /AuthorizationServer/api/<api-version>/Access/Login |
| 2 | Resolve reference values | GET /ResourceServer/api/<api-version>/Currency, AccountType, Account/StatusType, BillGroup, AccountsReceivable/Terms, and ContactType |
| 3 | Find, create, or update the customer | Search or retrieve Account; POST /ResourceServer/api/<api-version>/Account; POST /ResourceServer/api/<api-version>/Account/{id}/Patch |
| 4 | Retrieve the sellable catalog | GET /ResourceServer/api/<api-version>/PriceBook, Package, Package/Frequency, and related service and pricing resources |
| 5 | Record reusable customer pricing when needed | POST /ResourceServer/api/<api-version>/Account/PricePlan or patch the applicable plan |
| 6 | Create the order | POST /ResourceServer/api/<api-version>/Order with its related order details |
| 7 | Update an eligible draft or failed order | PATCH /ResourceServer/api/<api-version>/Order/{id} |
| 8 | Start processing | POST /ResourceServer/api/<api-version>/Order/Process |
| 9 | Follow processing | GET /ResourceServer/api/<api-version>/Order/{id}/Status and GET /ResourceServer/api/<api-version>/Order/{id}/PackageTracking |
| 10 | Retrieve financial results | Retrieve the related Invoice, Payment, account-package, and account-service resources. Download invoice output when required. |
Example Integration Journeys #
New Customer and First Order #
A sales team approves the first order for a new customer. The integration creates the LogiSense account and billing contacts, builds a draft order from the approved products, and submits it for processing. When processing is complete, the resulting subscription identifiers and billing status are returned to the systems that need them.
The customer and order are separate records. If customer creation succeeds but the order cannot be created, the existing account is reused when the order is retried.
Existing Customer with Negotiated Pricing #
A CPQ system approves customer-specific pricing for a defined period. The integration finds the existing account and records the agreement in an Account Price Plan. Future orders can then use the negotiated pricing while the standard catalog remains unchanged for other customers.
If the price applies only to one transaction, the integration can use supported order-level pricing instead of creating a reusable plan.
Multi-Entity or Multi-Currency Customer #
A CRM may represent one commercial customer even though billing needs separate accounts for different legal entities, currencies, or invoice recipients. The integration first creates the required LogiSense account hierarchy and invoicing relationships, then routes each order to the account that matches the approved transaction.
Maintaining a mapping between the upstream customer, its business context, and the correct LogiSense account allows this model to remain transparent to sales users.
Designing for Reliable Operations #
A production integration should plan for temporary outages, validation errors, and work that completes asynchronously.
Validation and Recovery #
LogiSense API responses include a tracking identifier and can return more than one validation error. Recording this information makes it easier to identify missing reference values, incompatible currencies, inactive catalog records, and invalid relationships.
When an account or order hierarchy fails validation, the integration can correct the source data or mapping and submit it again. If the outcome of a create request is uncertain because the connection was interrupted, the integration should look for the record before attempting another create.
Retries and Webhook Delivery #
Temporary transport and service errors can be retried with a bounded backoff. Authentication can be refreshed when a token expires. Validation and permission errors should be corrected before the request is repeated.
Webhook receivers should be designed to accept a repeated delivery safely. A common pattern is to authenticate the request, store it, return a successful response promptly, and process the business work asynchronously.
Reconciliation #
Scheduled reconciliation complements real-time integration. It can identify missing mappings, orders that remain in a non-final status, failed webhook deliveries, and financial results created after a temporary outage.
Useful reconciliation references include the upstream customer, quote, and order identifiers together with the related LogiSense account, pricing, order, subscription, invoice, payment, and API tracking identifiers.
Logging and Security #
Integration logs should contain enough business and tracking information to follow a transaction across systems. Credentials, bearer tokens, refresh tokens, payment details, and unnecessary personal information should not be logged.
The LogiSense JSON API log provides request, response, and tracking details that can help teams develop and support the integration. It can also be used to compare an integration sequence with the API calls made by a successful operation in the product interface.