Billing Support

Generally, your business model and the nature of your products determine how to set up JustOn's billing engine:

  • If you want to bill recurring items, usage data, etc. on a regular basis, we recommend to create subscriptions and, consequently, to produce invoices based on them.
  • If you sell one-time products, however, you do not need subscriptions - you can directly create invoices from arbitrary objects.

Subscriptions

See the subscription as a "blueprint" for the future invoice: It combines the account information (buyer name, address, etc.) with the details of the products to be charged, like product name and description, price, price model, applicable discounts, etc. In this sense, subscriptions represent contracts or "billing plans".

A subscription is the main "trigger" for an account to be considered in an invoice run - that is, each account for which you want invoices being created automatically is to be assigned a subscription. The invoice run will create one invoice for each active subscription.

In the context of subscriptions, the following concepts are important.

Status

Unless otherwise defined upon creation, new subscriptions have the status Draft. To be considered in an invoice run, they must be set Active.

Activating Subscriptions

Cloning

Cloning a subscription creates a copy of the current subscription, including the attached items. In addition, the following information is set by default:

  • the subscription name Autogenerate,
  • the status Draft,
  • the account, invoice template, contact data etc. as copied from the original subscription.

Upon cloning, you can modify this data as required.

Cloning a Subscription

Subscription Filter

To limit the scope of subscriptions that are subject to an invoice run, you create one or more subscription filters.

With respect to subscription filters, be aware of the following specifics:

  • For subscription filters, the field Use Case is empty.
  • If there is no subscription filter, JustOn considers all active subscriptions with active items whose start date is within the invoice run period for the invoice generation.
  • If there is one subscription filter, it is always applied in the invoice run.
  • If there are multiple subscription filters, you can select one of them for the invoice run.
  • If there are filter groups, you can select a filter group to preselect relevant filters, narrowing down the number of available filters.

Configuring Subscription Filter

Automatic Subscription Build/Update

Automatic subscription building helps managing subscriptions if your business requires to deal with a large or variable (increasing) number of subscriptions.

The way to set up the subscription builder depends on the nature of your products and the representation of your source data in Salesforce.

Automatically Building Subscriptions
Enabling Subscription and Subscription Items Update

Parent-Child Relationship

Used to bill an account-specific set of products under some account-specific conditions

To allow for individually configured items when building subscriptions, you can use objects that are in a parent-child relationship, like orders with order products. If set up accordingly, the subscription builder takes the parent object ( order) to produce the subscription, and the child objects ( order products) to produce the subscription items.

In order to create price tiers for items, JustOn also supports subchild relations. You can configure custom objects to hold the price tier information and relate them to the child objects via lookup or master-detail relations. The subscription builder then takes the subchild records to produce the price tiers for the subscription items.

subscr_build_ON_field
Building subscriptions based on accordingly configured objects

Note

When creating price tiers from subchild records, be aware of the following limitations:

  • Some Salesforce objects are not allowed to be the target of a lookup relation, including, for example, Opportunity Product or Order Product. When using one of these objects to create subscription items, it is not possible to configure a subchild object for creating price tiers.
  • When updating subscriptions automatically, any created price tiers are not included.

Master Subscriptions

Used to bill identical products on equal conditions to multiple accounts.

A master subscriptions is a subscription "model" that is copied for each target. The target is the object whose records are the basis for subscriptions, like accounts, contracts, cases, quotes, etc. If set up accordingly, the subscription builder can generate an individual subscription for each new account, contract, case, quote, etc. that you create.

subscr_build_master_subscr
Building subscriptions based on a master subscription

Data Mapping

Used to create or update subscriptions based on additional data or custom objects

Data mappings allow for retrieving the data required for creating or updating subscriptions and their items from virtually any fields of any objects. Generally, you can apply mappings to get data

  • in addition to the configured fields when using master subscriptions or objects in a master-detail relationship, or
  • from customized source objects whose records hold all (variable) information for creating subscriptions and items.

subscr_build_mapping Building subscriptions based on a mapping

Subscription Builder Use Cases

The subscription builder supports three different use cases for the subscription building:

Use Case Description
NEW Creates a new subscription.
REORDER Creates new items and adds them to an existing subscription. If there is no existing subscription, it builds a new subscription.
UPGRADE Creates a new subscription, sets an end date on the existing subscription and sets its status to Upgraded. Certain items (active, not already available, not excluded, matching service period) of the existing subscription are cloned and added to the new subscription.
Use cases example

To illustrate the use cases, assume the following example: You sell phone contracts, and you keep track of your deals using opportunities. For each opportunity you generate a subscription, which is finally invoiced.

When you close a deal with a new customer, the new (or updated) opportunity triggers the creation of a new subscription. This is covered with the use case NEW.

Now an existing customer orders an additional service, which you add as a new opportunity product on a new opportunity. This opportunity product becomes a new subscription item on the existing subscription. This is the use case REORDER - you add new subscription items, leaving the existing in place.

If, however, the customer decides to upgrade the calling plan, you must refund the amount that is already paid for the rest of the current contract term. This is where you apply the use case UPGRADE: you create a new subscription that includes items for any new products, but also credit items for products to be refunded, and the existing subscription terminates.

Use Cases

Installments

Certain business use cases require staged payment plans for invoices. To this end, JustOn allows for setting up installments, which represent models for intended payment plans.

JustOn implements installments (or payment plans) using the custom setting Installment. Each installment custom setting represents a model for the intended payment plan.

If this feature is enabled, you can define an installment type for a subscription. When executing an invoice run, JustOn consequently produces an invoice with the payment plan (installments) set up.

Depending on your business requirements, you can also make the installment settings available for use with accounts or objects based on which you create invoices using the generic invoice run. When selecting an installment on the account or the accordingly configured source object, JustOn copies it to the invoice when creating an invoice for this account or from this object.

Enabling Installments
Setting Up Installments

Auto-Renewal

Generally, subscriptions represent contracts. As contracts usually apply for a certain period of time, may involve automatic renewal and define cancellation terms, JustOn allows for applying these criteria to subscriptions.

Auto-Renewal Concepts

You can configure a subscription that has an end date to be extended before it expires. If you enable the automatic subscription renewal, JustOn schedules a job that will run daily and extend all auto-renewal subscriptions when the corresponding date is reached.

The following settings control the automatic subscription renewal:

Field Description
Auto-Renewal Defines the number of days or months to extend the subscription, setting up the subscription for automatic renewal.
Cancellation Terms Defines the cancellation period in days or months for a subscription. If empty, a value of 0 is taken by default.
Renewal Date Specifies the next renewal date. If the subscription is set up for automatic renewal, the date is automatically calculated like:
End Date - Cancellation Terms + Grace Period.
If the subscription has no end date, the field is empty.

The grace period is controlled via the corresponding global setting. In Setup, open Custom Settings > Global Settings > Manage > Edit, and set a value for Grace Period. If left empty, 0 is used by default.

For the automatic subscription renewal to run, the following conditions must be met:

  • Subscription is set Active.
  • End Date is set.
  • Auto-Renewal is set.
  • Renewal Date is set and less or equal to the current date.

Item Merge on Renewal

Optionally, the renewal process will merge items where suitable. Think, for example, of the following scenario: You sell licenses, and a customer orders additional licenses of the same kind. In this case, you want the quantity of the resulting invoice line item for licenses to increase instead of adding a new invoice line item for identical licenses.

Technically, the merge operation terminates the merged items, setting an end date, and creates a new item. It determines the End Date of the merged items like Next Service Period Start - 1 day, and sets the Deactivation Reason field to Merged.

Upon creating the new item, the merge operation derives the Start Date from the merged items' Next Service Period Start. To set the Quantity value, it totals up the individual quantities of the merged, terminated items.

The following conditions must be met for merging:

  • The two items must have identical OrderNo values and the billing type Recurring.
  • The existing item must be active.
  • The Next Service Period Start date is after the Start Date and before the End Date.
  • The following item properties must also be identical:
    • Next Service Period Start
    • End Date
    • Price
    • Billing Period
    • Billing Unit

Configuring Subscription Auto-Renewal
Enabling Item Merge

Cancellation

Canceling a subscription clears the renewal date and updates the end date if

  • the old end date is empty - the new end date will be

    Cancellation Date + Cancellation Terms

  • the cancellation date is after or equal to the renewal date - the new end date will be

    old End Date + Auto Renewal

Info

JustOn continues to process canceled subscriptions in the invoice run until their end date is reached. Canceled subscriptions without end date, however, are ignored.

Canceling a Subscription

Items

Subscriptions include items. They represent the products to be charged and will figure as invoice line items on the created invoices.

Depending on the nature of the product, you can define a specific price model or billing type for an item.

  • Recurring: The item is billed with the given amount in each invoice run.
  • One-Time: The item is billed only once. After the item has been billed for the first time, JustOn sets its status to Inactive so it will not be included in subsequent invoices.
  • Transactional: There is no quantity defined for the item. Instead, the information (quantity or quantity + price) is provided by usage data that match the subscription item.
  • Recurring Prorated: The item is billed with the given amount in each invoice run, with support for the partial calculation of billing units. Must be enabled specifically, see Enabling Partial Billing Units.

Managing Subscription Items

Item-Specific Billing Periods

For recurring subscription items (with the billing type set to Recurring), the following settings control the billing recurrence:

Field API Name Description
Billing Period BillingPeriod__c Defines the time interval (in days, months or years) after which the item is considered in the invoice run
Billing Unit BillingUnit__c Defines the time unit for the billing period to be displayed on the invoice (Day, Month or Year) and which is used for the price calculation of the billing period
Next Service Period Start NextInvoice__c Specifies the date of the next billing date for that item. If no value is defined, it will be substituted by the maximum of the invoice run start date, subscription start date or item start date. When the invoice is set Open, it is incremented to the current invoice line item's
service period end date + 1 day

For the resulting invoice line items, there are:

Field API Name Description
Billing Factor BillingFactor__c Factor resulting from the billing period and the billing unit that is applied to the invoice line item calculation. The billing unit Month combined with the billing period 3, for example, results in a billing factor of 3, that is, the item is invoiced every three months with the price multiplied by three.
JustOn recommends to include the billing factor in the invoice template through adding the field Billing Factor to the invoice line item table. For details, see Adjusting Invoice Line Item Table.
Billing Unit BillingUnit__c Defines the time unit for the billing period to be displayed on the invoice (Day, Month or Year) and which is used for the price calculation of the billing period
How does JustOn determine the billing behavior for recurring items?

There are two settings that control the billing behavior for recurring subscription items: The billing period specifies the interval after which an item is considered in the invoice run, and the billing unit is the time unit applied for this period. Based on this data, JustOn determines the billing factor, which is then applied to the resulting invoice line item - as a multiplier for the specified price.

The billing unit Year combined with the billing period 1 results in a billing factor of 1, that is, the item is invoiced once a year with the specified unit price.

The billing unit Month combined with the billing period 3 results in a billing factor of 3, that is, the item is invoiced every three months with the price multiplied by three.

The billing unit Month combined with the billing period 3 results in a billing factor of 3, and with an item quantity of 2, the item is invoiced every three months with the price multiplied by six.

The billing unit Day combined with the billing period 10 results in a billing factor of 10, that is, the item is invoiced every ten days with the price multiplied by ten.

For the subscription item to be considered in the invoice run, the item's next invoice date and the subscription's start date must be within the invoice run period.

How to control the service period of invoices and invoice line items?

JustOn automatically determines the service period of an invoice based on various conditions:

Generally, the earliest service period start date of all included invoice line items defines the service period start of the invoice. Consequently, the latest service period end date of all included invoice line items defines the service period end of the invoice.

Invoice Service Period Condition
Start The earliest (minimum) service period start date of all invoice line items.
End The latest (maximum) service period end date of all invoice line items.

The dates are recalculated when invoice line items are inserted, updated or deleted. Empty date fields on line items are ignored.

If set, the subscription end date forces the service period end of the invoice.

With respect to invoice line items, the billing type of the item usually determines how the service period is calculated.

Item Billing Type Service Period Start/Service Period End
One-Time The start date/end date of the corresponding item, or, if not available, the start date/end date of the invoice run period
Recurring The start date/end date of the invoice run.
Recurring with Billing Factor Start date: Next Service Period Start
End date: Next Service Period Start + Billing Period - 1 day
Transactional Start date: earliest (minimum) service period start date of the transactions
End date: latest (maximum) service period end date of the transactions

For recurring items, the start date and end date set as the invoice run period usually represent their service period. If, however, JustOn determines a billing factor (as given by a billing period and a billing unit), the service period start of the invoice line item is set using the subscription item's Next Service Period Start field. The service period end is then calculated as follows: Next Service Period Start + Billing Period - 1 day.

If Next Service Period Start is not set, JustOn uses the invoice run start date instead.

Other settings that force an item's service period end include:

  • the subscription item's activation end date, and
  • the end date of the last price tier defined for the subscription item.

Using the custom placeholders ServicePeriodStart and ServicePeriodEnd, you can display the items' service period in the invoice PDF. For details, see Adjusting Invoice Line Item Table.

Defining Item-Specific Billing Periods

Billing Period Synchronization

For recurring subscription items, you can set up JustOn to synchronize the billing period to start with

  • the start of the next year (for a billing period of 12 months),
  • the start of the next fiscal year (for a billing period of 12 months), or
  • the start of the next month (for a billing period of one month and with the billing unit Day).
  • the start of the next quarter
  • the start of the next fiscal quarter

Using the Sync With option adjusts the invoicing cycle to the defined period. The remainder of the billing period, that is, the rest of days or months until the defined sync period starts, is calculated partially.

Assume the following example configuration:

Record Field Value
Item Billing Type Recurring
Next Service Period Start empty
Billing Period 12
Billing Unit Month
Sync With Start of next year
Invoice Run Period Start 2016-09-01
Period End 2016-09-30

This will result in the following invoice line item data:

Field Value
Service Period Start 2016-09-01
Service Period End 2016-12-31
Billing Factor 4
Billing Unit Month

When setting the corresponding invoice to Open, the Next Service Period Start field of the item is set to 2017-01-01, synchronizing the item billing period with the calendar year.

Synchronizing Recurring Items

Item-Specific Billing Practice

For non-transactional subscription items (with the billing type set to Recurring, Recurring Prorated, One-Time or Minimum Fee), JustOn allows for defining the preferred billing time - either as soon as the the item service period coincides with the invoice run period, or at the end of the service period. To cover this requirement, you use the field Billing Practice on the item, selecting one of the following picklist values:

Value Description
Invoicing in advance Makes JustOn bill the item as soon as possible, that is, when the item service period coincides with the invoice run period. This is the default setting, and is also applied when the field is empty.
Invoicing in arrears Makes JustOn bill the item at the end of its service period, that is, when the service period end date of an item is before the invoice run period end date.
Invoicing in arrears requires at least one of Start Date or Next Service Period Start to be set.

Info

The billing practice support is available as of JustOn 2.58.

For example, assume a subscription with the following item configuration:

Field Value
Billing Unit Month
Billing Period 3
Next Service Period Start 2019-01-01

This item has a service period of three months and is to be billed every three months.

Now assume a monthly invoice run. Consider the resulting invoice line item for the different billing practices:

Invoice Run Period Resulting Item:
Invoicing in Advance
Resulting Item:
Invoicing in Arrears
2019-01-01 2019-01-31 2019-01-01 2019-03-31 -
2019-02-01 2019-02-28 - -
2019-03-01 2019-03-31 - 2019-01-01 2019-03-31
2019-04-01 2019-04-30 2019-04-01 2019-06-30 -

As you see, in arrears delays the billing of the item: It will not be invoiced until an invoice run covers the last third of its service period.

Defining Item-Specific Billing Practice

Item-Specific Lead Time

For non-transactional subscription items (with the billing type set to Recurring, Recurring Prorated, One-Time or Minimum Fee), JustOn allows for defining a lead time (in months). This enables an item to be included in an invoice run before the actual service period of the item is reached.

Info

The lead time support is available as of JustOn 2.58.

Note

When defining a lead time, the following item information must be set:

  • Billing Unit
  • Billing Period
  • Start Date or Next Service Period Start

The Billing Type must be one of Recurring, Recurring Prorated, One-Time or Minimum Fee.

For example, assume a subscription with the following item configuration:

Field Value
Billing Type Recurring
Billing Period 1
Billing Unit Month
Next Service Period Start 2019-03-01
Lead Time 1

Now assume a monthly invoice run, starting with January (01 - 31). Consider the resulting invoice line item:

Invoice Run Period Invoice Line Item
Service Period Start
Invoice Line Item
Service Period End
January - -
February 2019-03-01 2019-03-31

With a lead time of one month, the invoice line item will be created one month before service period starts.

Defining Item-Specific Lead Time

Item Pricing

Depending on the nature of the product, you can define a specific price model or billing type for an item.

  • Recurring: The item is billed with the given amount in each invoice run.
  • One-Time: The item is billed only once. After the item has been billed for the first time, JustOn sets its status to Inactive so it will not be included in subsequent invoices.
  • Transactional: There is no quantity defined for the item. Instead, the information (quantity or quantity + price) is provided by usage data that match the subscription item.
  • Recurring Prorated: The item is billed with the given amount in each invoice run, with support for the partial calculation of billing units. Must be enabled specifically, see Enabling Partial Billing Units.

The actual price of an item can be of two types.

  • Flat: With a flat price, the item's quantity is assumed as 1 and the item's subtotal equals the configured flat price.
  • Default: When specifying a default price, the item's subtotal is determined by the specified default price multiplied by the actual item quantity.
General billing settings

The following details control the item's general billing behavior:

Section Field Description
Generic Billing Values Billing Type Specifies the general billing behavior
Recurring - item is billed with the given amount in each invoice run
One-Time - item is billed only once, then it is deactivated
Transactional - there is no quantity defined for the item, it is calculated based on usage data records instead
Recurring Prorated - item is billed proportionally to a partial billing unit (must be set up specifically)
Price Specifies the item price, is ignored when using price tiers
Price Type Specifies the item's price type, is ignored when using price tiers
Default - using a default price, the item's subtotal is determined by the specified default price multiplied by the actual item quantity
Flat - using a flat price, the item's quantity is assumed as 1 and the item's subtotal equals the configured flat price
Charge Model Defines the commission calculation type for specific pricing scenarios
Mark Up - the invoice run creates an additional invoice line item for which the price is calculated based on the original invoice line item total multiplied by the percentage that is defined in the commission field
Mark Down - the invoice run creates an additional invoice line item; the prices for the two items are re-calculated such that the sum of the item totals equals the original total, and the price for the additional invoice line item is based on the percentage in the commission field of the original item
Discount Specifies a percentage discount rate that is applied to all prices of the item
Commission Specifies a percentage commission that calculates the line item total based on the unit price and the defined percentage
Recurring & One-Time Billing Values Billing Period Specifies the time interval (in days, months or years) for the item to be considered in an invoice run
Billing Unit Specifies the time frame (Day, Month or Year) used for the price calculation of the billing period
Next Service Period Start Specifies the next billing date for the item
Sync With Specifies a time with which the next invoice date of a recurring item is to be synchronized
Transactional Billing Values Order No. Specifies the key to match source data to a subscription item
Transaction Price Field Specifies the source field for the item price when calculating transactions
Transaction Quantity Field Specifies the source field for the item quantity when calculating transactions
Transaction Aggregation Fields Specifies additional fields to be aggregated for calculating transactions
Timed Quota Specifies the quantity that triggers the timed quota functionality: If the quantity over all line items within a year from the start date of the item is greater than the timed quota, JustOn applies the alternate price (set in the Price field) instead of the standard price (taken from a price tier).
Timed Quota Period Specifies the aggregated quantities of the invoice line items per period. The period is updated when an invoice is finalized.
This field is not intended to be displayed, as it is used for internal calculation purposes.

Price Models

Price Tiers

You can set price tiers. These are a means to specify multiple prices for an item, each being valid for a defined quantity range.

price_tier
Price tiers without defined validity period

You can set up price tiers to be valid for a defined time, specifying a start date and an end date. In this case, JustOn arranges the prices with the same start date and end date into one price tier group.

price_tier_group
Price tiers grouped by validity period

Note

Price tier groups must not overlap.

With multiple price tier groups, JustOn selects the matching price of a subscription item during the invoice run based on

  • the quantity and
  • the transaction date for transactional items or
  • the service period for recurring items.

That is, transactions that have taken place in the time of one price tier group are aggregated, but separated from those that have taken place in the time of another price tier group. This results in multiple individual invoice line items, each based on one price tier group.

If the price tier group changes within the service period of a recurring item, JustOn separates the service period into multiple parts. The item price for each service period part is calculated using a split billing factor that corresponds to the split period. This also results in multiple individual invoice line items, each based on one price tier group.

Info

As long as you do not define start date and end date for a price tier, there will be only one valid price tier and no item separation will take place.

Using Price Tiers

Timed Quota

When billing usage data, your business may require to apply different prices after an allocated usage quota is exceeded. To this end, you can define a timed quota for a transactional item. Once set, JustOn selects an alternate price for a transactional item if the achieved quantity is larger than the quota defined for the given period.

Info

The timed quota support is available as of JustOn 2.59.

For the feature to work, you need two prices - a (standard) price to apply for quantities within the quota, and an alternate price for quantities that exceed the quota.

  • The price for invoice line items within the defined quota is taken from a price tier. That is, you create at least one price tier to define the standard price(s) to apply.
  • To set the the price for invoice line items that exceed the quota, you use the Price field of the item. With the timed quota set and filled, JustOn bypasses the price tier and applies the price defined here.
  • To set a different title and description for invoice line items that exceed the quota, you can use the item fields Additional Title and Additional Description.

With respect to the timed quota functionality, the following specifics apply:

  • The period considered for the quota is one year starting with the item start date. If there is no start date set on the item, the subscription start date is used as fallback.
  • The service period start date of a transaction is used to determine the quota quantity period. If there is no service period start on the transaction, the transaction date is used as fallback.

    Example period definition
    Item Start Date Transaction Start Date Timed Quota Period
    2018-03-01 2018-03-01 2018-03-01 - 2019-02-28
    2018-03-01 2018-02-28 2018-03-01 - 2019-02-28
    2018-03-01 2019-07-01 2019-03-01 - 2020-02-29
    Example periods with leap years
    Item Start Date Timed Quota Periods
    2019-02-28 2019-09-28 - 2020-02-27
    2020-02-28 - 2021-02-27
    2021-02-28 - 2022-02-27
    2020-02-29 2020-09-29 - 2021-02-27
    2021-02-28 - 2022-02-27
    2022-02-28 - 2023-02-27
  • If the quantity of a transaction exceeds the timed quota, JustOn splits the transaction into two invoice line items: one for the price below the quota and one for the price above the quota.

  • If the timed quota is set for an item, JustOn aggregates the transactions by the quota period.

    Transaction aggregated by quota period

    Transactions for an item with the start date 2018-03-01 before the aggregation:

    Transaction Start Date Quantity
    2018-03-01 2
    2019-02-28 3
    2019-03-01 7

    The same transactions after the aggregation:

    Transaction Start Date Quantity
    2018-03-01 5
    2019-03-01 7
  • If an invoice is cancelled, the quantities of the cancellation line items are removed from the timed quota of the related item.

  • In case of a partial credit, the quantity of the cancellation line item is removed from the timed quota of the related item if the partial credit has been created by quantity. Partial credits based on an amount refund do not affect the quota quantity.

    If a partial credit has been created by quantity, JustOn first reduces the quantity above the quota. Only when this quantity is used up, JustOn starts to reduce the originally priced quantity below the quota.

Using Timed Quota

Commission Tiers

Certain business use cases require commissions to be charged as a remuneration for some brokerage. For calculating a commission, you can define a fixed commission percentage for an item as part of the Generic Billing Values (see General Billing Settings). For more complex scenarios, JustOn features commission tiers, a means to calculate different commissions for an item based on the sales volume.

Using Commission Tiers

Minimum Fees

Certain business models require invoicing a minimum fee, usually on a monthly base, irrespective of the actually incurred costs.

With JustOn, you can put such scenarios into practice as follows: You create a subscription item with the billing type Minimum Fee. The price of this item represents your base charge. The subscription items that you intend to charge up against this minimum, like usage data items, for example, must be marked as included accordingly.

Now if the sum of the included items is lower than or equal to the minimum price, only the minimum fee item shows up on the invoice as a single invoice line item. If, however, the sum of these grouped items is larger than the minimum price, the individual items appear on the invoice as individual invoice line items. Any items not marked as included in the minimum are not subject to this calculation.

For transactional items, there are two modes for applying the minimum comparison:

  • Global minimum: Compares the sum of all included items to the minimum
  • Group minimum: Compares the sum of included items that are grouped by a transaction criterion to the minimum

The corresponding calculations are performed on net prices.

Enabling Minimum Fees

Subscription Price Increases

Certain business use cases require the prices for subscription items to be increased automatically on a regular basis.

The following subscription details control this behavior:

Field Description
Price Increase Specifies the percentage value by which to increase the prices of this subscription. Note that the price increase affects all items equally.
Price Increase Date Specifies the date (MM-dd) on which the price increase is made effective.

The subscription price increase feature makes use of price tier groups. If set up accordingly, a scheduled job duplicates the latest price tier group and increases the price of all subscription items by the defined percentage value once a year at the defined date.

For the date, the following options are available by default:

Value Description
01-01 January 1st
06-01 June 1st
Start Date Month and day of the subscription start date
End Date Month and day of the subscription end date

You can add more month/day combinations to the picklist. For details, see Adding Price Increase Date Options.

The price increase considers subscriptions and items if the following conditions are true:

  • The subscription status is Active
  • The corresponding price increase settings at the subscription are set
  • The subscription end date is empty or after the current date
  • The item status is Active
  • The item end date is empty or after the current date
  • The item has price tiers whose

    • End date is empty
    • Start date is empty or at least nine months in the past

JustOn creates the new price tier groups at the earliest nine months before the price increase becomes valid.

Configuring Subscription Price Increases

Usage Data Billing

Usage data represent product consumptions (volume or traffic data, service coverage, etc.) that are to be invoiced. To this end, usage data include the following information:

  • the date and time the consumption took place,
  • the quantity for the consumption, like a number of worked hours, or a number of consumed units, etc.,
  • an identifier, which is used to assign the usage data to a subscription item.

In broad strokes, usage data billing (aka metered billing, usage-based billing or pay-per-use) works as follows:

JustOn retrieves raw usage data (for example, via data import or a third-party integration) and usually saves it to custom objects. The transaction builder converts this data to transactions. During the invoice run, JustOn matches the transactions against the defined subscription items, evaluates the provided quantity information and calculates the item's subtotal. This data then makes up the according invoice line item.

transaction_build
Itemizing usage data with the transaction builder

The continuous invoice run creates invoices and invoice line items directly out of objects that hold usage data. It uses the transaction builder functionality to itemize the consumption data, but does not generate "tangible" transaction records.

Usage data billing usually involves

  • Custom object: Set up to hold both the usage data and the controlling data
  • "Target" subscription and corresponding items: Holds the items set up to match the transactions for the invoice generation
  • Transaction filter: Defines which objects and records to include in the transaction build process
  • Continuous invoice run: Set up to create invoices and invoice line items directly out of the objects that hold usage data
  • Minimum fee: Optionally, set up to bill a fix base charge, irrespective of actually incurred costs

Usage Data Billing
Enabling Minimum Fees

Individual Price and Quantity Fields

Certain business use cases require individual (account-specific) prices, price tiers or quantity information for transactions. To this end, you can add multiple price and quantity fields to the source object. An (account-specific) subscription item can then retrieve the intended value from the specified source field.

Price and Quantity Fields

Transactions

When billing usage data, you usually create invoices and invoice line items directly out of objects that hold usage data. The continuous invoice run uses the transaction builder functionality to itemize the consumption data, but does not generate "tangible" transaction records. Certain use cases, however, may require to do so.

There are two ways to invoke the transaction builder to generate "tangible" transaction records:

  • Selecting a transaction filter when executing an invoice run
  • Using a transaction build job

Building Transactions

Transaction and Transaction Details

Usually, each transaction results in an individual invoice line item. Certain business use cases, however, require transactions to be aggregated but still keeping individual records for transaction tables. To this end, JustOn supports transaction details, which are in a master-detail relationship with transactions.

For aggregating values, JustOn makes use of roll-up summary fields that sum up specific fields over all transactions details that belong to a specific transaction.

Transaction and Transaction Details

Transaction Tables

Your business use cases my require to include the list of transaction records with the invoice. To this end, you can configure JustOn to

  • Directly print a table of transaction records on an invoice, or
  • Generate CSV files for transaction records to be attached to invoices.

Displaying Transaction Records on Invoices
Attaching Transaction CSV to Invoices

Billing Arbitrary Objects

You can create invoices from arbitrary objects that are configured accordingly, "bypassing" the subscription.

To this end, JustOn allows for configuring virtually any Salesforce object to hold the required invoicing data. This may include orders, contracts, opportunities or custom objects. Using custom filters, you then define which objects and records to include in the invoice run.

Billing Arbitrary Objects

The way to set up the generic invoice run depends on the representation of your source data in Salesforce.

When executing the generic invoice run, JustOn writes information about the billed source object to the generated invoice line items, setting the following fields:

Field Label API Name Data Type Description
Source Id SourceId Text(18)(External Id) The ID of the source object.
Filter Filter Text(255) The name of the invoice run filter.

Parent-Child Objects

You can generate invoices based on source objects that are in a parent-child relationship, like orders with order products. If set up accordingly, the invoice run takes the parent object ( order) to produce the invoice, and the child objects ( order products) to produce the invoice line items.

ir_ON_field
Creating invoices based on accordingly configured parent-child objects

Single Objects

You can generate based on single source objects that hold all invoicing data using, like, for example, specifically customized contracts. If the object records are marked as the single source, and based on the appropriate configuration, JustOn can produce both invoices and invoice line items from these records.

ir_ON_field_single_o
Creating invoices based on one accordingly configured object

Data Mapping

There may be data in addition to the configured fields for source objects in a parent-child relationship or for single source objects. If you need to create invoices based on data that is not accessible otherwise, you set up specific data mappings to retrieve it.

ir_mapping
Creating invoices based on a mapping

Invoice Run From Parent

You can set up JustOn to allow for starting the generic invoice run from a parent of the actual source object. Think, for example, of an account that has multiple contracts (or orders with order products) set up as source objects - now you want to generate an invoice for this account that covers all related contract (or orders).

ir_ON_field_single_o_parent
Invoking invoice creation from a parent object

Tenants

Certain business use cases require a Salesforce organization (the "virtual space" that includes all data and applications of an individual business) to hold specific billing-relevant information or to be further divided in subdivisions. To this end, JustOn has introduced tenants.

The tenant can hold billing-relevant information of your company or company subdivision, like address data or bank data. When using tenants, you can automatically assign a tenant to an invoice during the invoice creation. Consequently, the tenant information can be printed to the invoice via custom placeholders, like [TenantName] or [TenantIBAN].

Invoices and subscriptions can specify a tenant. If the information is available, JustOn automatically populates the Tenant field on the invoice or subscription when creating these objects. You can, however, later override the tenant manually.

Info

Make sure to check that the spelling exactly matches the tenant name as defined in the custom setting. JustOn performs an exact match on the tenant name when retrieving the corresponding information.

When determining the tenant for an invoice, JustOn tries to retrieve the information in the following order:

  • Copy tenant from subscription
  • Determine tenant from account via tenant mapping
  • Use default tenant
  • Leave Tenant field empty

Similarly, when determining the tenant for an invoice, JustOn proceeds as follows:

  • Determine tenant from account via tenant mapping
  • Use default tenant
  • Leave Tenant field empty

Tenant

Filters

JustOn uses filters to selectively narrow down the set of records included in bulk operations. Filters are implemented using the custom setting Filters.

Info

A filter returns all objects that match the filter, it does not filter them out.

Filter Use Cases

Filter use cases indicate the supported operations. These include:

Filter Groups

A filter group specifies an arbitrary criterion for grouping invoice run-relevant filters, used to narrow down large filter lists. Assigning a group to all filters for a specific context (tenant, region, etc.) allows for pre-selecting this group in the UI (New Invoice Run, New Invoice From Subscription), which then displays only the relevant filters, accelerating the invoice creation.

Invoice Criterion

Your business may require to group and separate invoice line items along a specific criterion - only invoice line items with the same criterion are to be included in one invoice, others are invoiced separately. To support this, JustOn makes use of invoice criteria, which are a means for controlling the distribution of invoice line items.

Example: Recurring items

The following subscription configuration

Item Billing Type Quantity Price Invoice Criterion
Fee 1 Recurring 2 5,00 A
Fee 2 Recurring 3 7,00 B

produces two invoices with the following line items:

(1) invoice for criterion A

Invoice Line Item Quantity Price
Fee 1 2 5,00

(2) invoice for criterion B

Invoice Line Item Quantity Price
Fee 2 3 7,00
Example: Transactional items

The following subscription configuration

Item Order No. Billing Type Quantity Price
Fee 3 PROD3 Transactional 10,00

with these custom object records to be matched with the transactional item

Invoice Criterion Order No. Quantity
A PROD3 3
A PROD3 5
B PROD3 7

produces two invoices with the following invoice line items:

(1) invoice for criterion A

Invoice Line Item Quantity Price
Fee 3 8 10,00

(2) invoice for criterion B

Invoice Line Item Quantity Price
Fee 3 7 10,00
Example: Generic invoice run

In one generic invoice run, the following custom object records

Account Title Invoice Criterion
My Company Product 1 A
My Company Product 2 A
My Company Product 3 B

produce two invoices with one service period for "My Company" with the following invoice line items:

(1) invoice for criterion A

Invoice Line Item
Product 1
Product 2

(2) invoice for criterion B

Invoice Line Item
Product 3

Distributing Items to Multiple Invoices when billing subscriptions
Applying Invoice Criterion when billing arbitrary objects

Multiple Party Billing

Generally, JustOn is set up to issue invoices to one recipient, usually via the account associated to the corresponding source record. Certain business use cases require billing to multiple parties, however - like, for example, in a marketplace scenario.

In a typical setup, the marketplace operator connects merchants (the providers of the traded products) and the buyers (the recipients of the products), processing all transactions between these players. Consequently, the marketplace operator bills the same products to multiple parties: they issue credits to merchants for payouts, and invoices to buyers to receive payments.

marketplace
Billing products to merchants and buyers

JustOn supports multiple party billing in the following contexts:

Multiple party billing usually involves

  • Recipient-specific sets of controlling fields: Allocate the correct data to the different recipients
  • Recipient-specific filters: Retrieve the correct data to be included in the recipient-specific invoice run
  • Recipient-specific invoice templates: Hold recipient-specific texts and table definitions

Once having set up multiple billing, you can execute two different invoice runs - one for each filter in order to create individual invoices for the merchant and the buyer.

Enabling Multiple Party Billing
Best Practice: Marketplace

Multi-Currency Support

Certain business use cases require support for multiple currencies. Administrators can enable multiple currencies in their Salesforce orgs.

Note

Be aware of the following implications:

  • Once multi-currency support is enabled for an organization, it cannot be disabled.

  • Even though you have enabled multiple currencies, JustOn recommends to use one currency per account, that is, to use the account currency for all operations and records related to an account.

    For some functions, Salesforce and JustOn operate with plain values without regard to currencies. In these cases, simply combining values of different currencies without conversion would produce wrong records.

Enabling Multi-Currency Support

Currency Conversion

With multiple currencies enabled, you can create invoices and other records in your organization's default currency as well as in foreign currencies. By default, any converted amounts in your organization rely on the conversion rates as defined with your active currencies. Conversion rates must be set and updated manually. Changing the exchange rate automatically updates converted amounts on all records.

Salesforce allows to use dated exchange rates by enabling advanced currency management. Dated exchange rates set a conversion rate for a specific date range. For details, see About Advanced Currency Management and Edit Dated Exchange Rates in the Salesforce Help.

Since conversion rates are subject to change in the course of time, JustOn stores the conversion rate upon invoice generation in the field Conversion Rate. Doing so allows for creating reports or formulas for custom fields based on the saved value.

JustOn selects the conversion rate from the Salesforce currency management by the date of the invoice upon finalization. After the invoice is set Open, changes are no longer allowed, and the conversion rate on the invoice is fixed. That is, once the value is stored, it does not change any more, even if the organization wide conversion rates has changed since.

Payment Matching With Multiple Currencies

Currencies of imported payment entries may differ from the currencies of their matching records. When converting payment entries to balances, JustOn transfers the corresponding amounts.

The following payment entry fields hold the conversion-related data:

Field Label Description
Payment Amount The amount for the payment balance. If the currency is different from the match currency, the amount is converted using the exchange rate of the booking date.
Currency The currency of this payment entry.
Foreign Amount If the foreign currency fields are set and have the same currency as the match, they are used instead of the Payment Amount.
Foreign Currency Code The foreign currency code.
Foreign Conversion Rate The conversion rate for converting the payment amount to the foreign amount. Is copied to the Conversion Rate field on the balance.

After JustOn has converted the payment entry to a balance, the amount and currency information is kept in the following fields on the balance:

Field Label Description
Amount Shows the balance sum.
Currency The currency of this balance.
Original Amount The original amount of the payment entry before the conversion.
Original Currency Code The original currency code.
Conversion Rate The conversion rate.

Depending on the use case and the original data, the information is transferred or, respectively, converted as described below.

One currency, no conversion

If the payment entry and the balance use the same currency, no conversion takes place.

Payment Entry Source Field Balance Target Field
Payment Amount Amount
Currency Currency
Two currencies, payment entry includes all data

If the payment entry includes all information, no conversion takes place. JustOn only populates the balance fields with the given source data.

Payment Entry Source Field Balance Target Field Notes
Payment Amount Original Amount
Currency Original Currency Code
Foreign Amount Amount
Foreign Currency Code Currency
Foreign Conversion Rate Conversion Rate If there is no conversion rate given, JustOn calculates it based on the given payment amount and foreign amount.
Two currencies, payment entry includes one amount and currency

If the payment entry includes only an amount and currency, JustOn converts the amount to the target currency using the conversion rate determined by the system (see Manage Multiple Currencies | Salesforce Help).

Payment Entry Source Field Balance Target Field Notes
Amount Calculated based on the payment amount using the conversion rate determined by the system.
Currency
Payment Amount Original Amount
Currency Original Currency Code
Conversion Rate Determined by the system, based on the given payment entry currency and the balance currency.