Customer Hierarchies & WhoPays

Customer Hierarchies allow parent / child relationships to be created between customers, allowing for more accurate mapping of your customer relationships.

WhoPays allows payment responsibilities to be reassigned up-the-chain so that the payer may be a separate entity from the customer.

Essentially, these features allow 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.

A customer with a parent who is responsible for paying their subscription.

Enablement & Settings

Customer Hierarchies and WhoPays are only available on sites using the new Relationship Invoicing feature. On a site with relationship invoicing enabled, Customer Hierarchies and WhoPays are enabled from the settings menu.

The features are separate, but connected, as follows:

  • Customer Hierarchies can be enabled without WhoPays. This is useful if you just want to define the relationships between your customer base (i.e. parent / child relationships) but are not interested in having anyone but the customer pay for themselves.
  • WhoPays requires that Customer Hierarchies also be enabled. This is because payment responsibility may only be assigned to another customer in the same hierarchy (i.e. an ancestor may be the payer, but another unrelated customer may not be the payer)

When enabling WhoPays, a “Default Payer & Consolidation” may be selected. This default is used for any subscriptions created for a customer that has a parent. This default will apply unless another responsible payer is chosen at the time of subscription creation.

  • Customer (separate invoices): The subscription will not be grouped and will be invoiced individually. This creates a normal, standalone subscription.
  • Customer (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 Ancestor: The subscription will be grouped with the eldest ancestor in the hierarchy.

Customer Hierarchies

Customer Hierarchies allow customers to be grouped into parent / child relationships, which can be used purely for organization or for setting payment responsibilities via WhoPays. Customer Hierarchies don’t necessarily require WhoPays, but it does open up the option to select the responsible payer when needed.

To create a hierarchy for 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 WhoPays 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.

Limitations

A parent customer record may have unlimited child customer records.

However, a hierarchy is limited to a depth of 10 customer records.

WhoPays

With a customer hierarchy created, it’s now possible to assign a different payer to new subscriptions being created via WhoPays. 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.

Selecting WhoPays

New Subscription Form

Choosing a 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”.

Subscription form with a parent payer selected

Once a child customer is selected, the “WhoPays” section will appear on the form below the customer with a list of options within the hierarchy:

  • The customer, on a separate invoice
  • The customer, on a consolidated invoice
  • A parent or ancestor, on a consolidated invoice (if a parent or ancestors exist)

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 separately on an individual invoice. Selecting the second option will behave differently depending on whether the customer already has subscriptions in a consolidated subscription group:

  • If the customer does not have any subscriptions in the consolidated subscription group, this one will be created as the first subscription in such a group and define the group paramters, such as which card/bank account to use and invoice timing.
  • If the customer does already have at least one subscription in the consolidated subscription group, this one will be added to that group and inherit the payment profile and invoice timing.

In this case, since payment will be collected by another customer, a payment profile is not needed for the subscription being created.

Invoice Consolidation Options

With a payer set, the new subscription will usually be added to a pre-existing consolidated subscription group. As such, you have access to a few options to choose how the new signup should be handled with respect to the consolidated invoice:

  • Accrue charges until the next consolidated invoice: Do not attempt to collect payment for this new subscription until the group renews next.
    • If selected, this will generate a pending invoice that will get paid on the group’s next renewal
    • If not selected, an invoice will be issued and captured immediately
  • Align the billing date with the consolidated invoice: 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 first partial period: If aligning the billing date with the subscription (i.e. the above option), prorate the amount being charged based on the group’s billing date.

Examples

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.

Accrue Charges

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.

Align Dates

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.

Prorate Billing

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.