This article discusses Customer Hierarchies, which is a new, opt-in feature available for sites using Relationship Invoicing. Please contact support to gain access.
Customer Hierarchy and Payment Mapping allows parent / child relationships to be created between customers, and payment responsibilities to be rolled up-the-chain to model hierarchical payment relationships.
This allows customers to be grouped together for organizational purposes, and / or for parent or other customers above in the hierarchy to be responsible for paying for subscriptions of their child customers. This becomes useful in scenarios like reseller models, multi-national organizations, or even simple cases where Grandma wants to pay for her Grandchildren’s subscriptions.
Customer Hierarchy and Payment Mapping is only available on sites using the new Relationship Invoicing feature. On a site with relationship invoicing enabled, Customer Hierarchies must be enabled from the settings menu.
When enabling the feature, a default payer is set for subscriptions created for any customer that has a parent. This default will apply unless another responsible payer is chosen at the time of subscription creation.
- Self (separate invoices): The subscription will not be grouped and will be invoiced individually. This creates a normal, standalone subscription.
- Self (consolidated invoices): The subscription will be grouped with other subscriptions for this same customer. This results in consolidated invoices for all subscriptions created with this setting enabled.
- Parent: The subscription will be grouped with it’s parent’s default subscription group and paid by the parent.
- Eldest Relative: The subscription will be grouped with the eldest ancestor in the hierarchy.
Customer Hierarchies allow customers to be grouped into parent / child relationships, which can be used purely for organization or for setting payment responsibilities for a subscription by a parent or older relative customer. Customer Hierarchies don’t necessarily require changing who is resposible for paying for a customer’s subscription(s), but it does open up the option to change the responsible payer if needed.
To create a hierarchy from existing customers, navigate to the customer that will be setup as the child in the relationship and select the option to “Choose Parent” from the Customer Hierarchy card. It is also possible to create a new customer and assign a parent directly from the new subscription form - learn more about that in the Payment Mapping & Responsible Payer section below.
From the following screen, choose a customer record to be the parent, preview the new relationship, and confirm. This will set the parent on the customer and will now also display any older relatives in the hierarchy (grandparents, great grandparents, etc).
It’s possible to also create new child customers for an existing customer by selecting the option to “Add Child” at the bottom of the section. This will display a new customer form and will set the current customer as the parent.
With a Customer Hierarchy created, it’s now possible to assign a responsible payer to new subscriptions being created. This makes use of Invoice Consolidation and Subscription Groups but now the responsible party can be set to any customer within the hierarchy, not just the subscription’s customer.
Example: If Grandma wants to pay for her Grandchildren’s subscriptions, she can be setup as the “parent” of each of the Grandchildren’s customers, and then each of the subscriptions can be grouped under her for payment.
Choosing a responsible payer for a new subscription can be done via the new subscription form. It requires that the selected customer, whether newly created or existing, has a parent set on it.
Existing customers can be edited directly as shown above to add a parent, or they can be selected in the subscription form and then edited from within the form. New customers are given the option of setting a parent under the “Advanced Customer Fields”.
Once a customer is selected with a parent, the “Responsible Party” section will appear on the form below the customer with the options:
- Payment will be handled by this customer.
- Payment will be handled by another customer.
The first option will be similar to creating a regular subscription where the customer is not grouped and is responsible for paying their own subscription. Selecting the second option will allow for the responsible party to be selected from the customer hierarchy.
In this case, since payment will be collected by another customer, a payment profile is not needed for the subscription being created.
With a responsible party set, this new subscription will be grouped with the selected party’s default subscription group. There are a few options that can be selected for this grouping:
- Accrue charges until the group renewal: Do not attempt to collect payment for this new subscription until the group renews next. This will generate a pending invoice that will get paid on the group’s next renewal.
- Align the billing date with the billing date of the group: Set the next billing date for the subscription to line up with the group’s next billing date rather than today’s date.
- Prorate billing for the current period: If aligning the billing date with the subscription, prorate the amount being charged based on the group’s billing date.
For example, let’s assume that the renewal date of the group is the 1st of the month, and it is currently February 15th. A $100/mo subscription is being created.
If unselected (no accrual), then an invoice for $100 will be created and paid immediately on February 15th. When the group renews on March 1st, no charges for this subscription will be included, since its next renewal is now March 15th. The March 15th invoice for $100 will be paid with the group on April 1st.
If selected (accrual active), then a pending invoice for $100 will be created and paid along with the group renewal on March 1st. The March 15th invoice for $100 will be paid with the group on April 1st.
Note: review Consolidated Invoice Timing to understand the billing dates of subscriptions in a group.
If unselected (no alignment), then the first invoice date for this subscription will be February 15th and the next will be March 15th, even though collection will occur on the group’s billing date of March 1st and April 1st.
If selected (alignment active), then the billing date for the subscription will be set to match the group, which is March 1st. Whether or not the partial period February 15 - March 1 is invoiced depends on the next setting for proration.
This option is only applicable when you have chosen to align dates.
If unselected (no proration), then there will be no charge for February 15th - March 1st, and the first invoice will be generated on March 1st and billed on the consolidated invoice.
If selected (proration active), then there will be a prorated invoice generated for the period February 15th - March 1st. Whether or not payment for this invoice is collected immediately on February 15th or pended until March 1st depends on the setting for accrual.