Conga Billing is a cloud-based, independent application built on the Conga Advantage Platform. It manages billing and invoicing for orders created in Conga CPQ, CLM, eCommerce, and even external systems like ERP or other CPQ solutions.

The following points list the various sources from where orders can be created:

• Orders are created upon accepting a Conga CPQ quote, activating a Conga CLM Agreement, or from a Conga purchase agreement.
• Direct orders can be created from other Conga sources like eCommerce.
• Orders can originate from external CPQ, Order, or Commerce applications to use the services that Billing offers. For such orders, Billing again creates orders inside the Conga framework and refers them back to the source ID, enabling the exchange of Conga-generated information with the source.

Because orders can originate from multiple sources, a common starting point for processing is necessary. Order Line Item (OLI) is the central starting point for all billing processes. Whether the order comes from Conga or an external system, Conga Billing creates an internal order and processes billing from the OLI.

The following diagram summarizes the concept of order line-driven architecture of Billing on the Conga Platform:

Three-Layered Data Model:

When billing is initiated, Billing will create three layers of data - Billing Header, Billing Schedule Record, and Billing Schedule Details.

• The Billing Header serves as a placeholder for customer, product, and pricing information. Pricing can be sourced from either the OLI or Asset Line Item (ALI), depending on your configuration (for existing Conga CPQ customers).
• Based on the information drawn from the billing header, the engine creates the billing schedule records (BSR). They represent a cascade of records equivalent to a billing schedule without the fee amount. The actual fee amount is not auto-calculated; instead, it rolls up fee amounts from the Billing Schedule Details.
• The billing schedule details (BSD) contain the granular level data for every billing period. The BSD reads the un-billed amount from BH and creates the records with Fee Amount and this information is rolled up to BSR. The BSD allows for adjustments and manual overrides, which are then rolled up to the BSR.

Salient Features:

• Since the billing header can fetch the price info from both OLI as well as ALI, you have the liberty to bill the customer based on the order pricing information or the asset pricing information as a reference.
• Calculating the fee amount at the BSD level provides more flexibility for adjustments at the billing level. All the adjustments will then roll up to the corresponding BSR.
• This architecture enables you to track all billing variations throughout the subscription lifecycle.
• It lets you control how much to bill. For example, billing a partially fulfilled order for the corresponding amount.
• It empowers you to make monetary adjustments manually for a specific period without modifying the engine-generated billing amount.
• It enables you to take snapshots of manual adjustments and send them for approval, promoting transparency.
• It provides granular billing information across the subscription lifecycle through a single reference point, such as a Conga ALI, Order, Opportunity, or Contract Agreement Number.
• It supports clear reporting.
• It applies intelligence to the first two layers to generate the business insights needed for a successful Revenue-Operations cycle.