Home > Aria Crescendo Documentation > Parent-Child Account Best Practices

Parent-Child Account Best Practices


You can create parent‐child account relationships to group accounts together based on your business needs.


  • You have customers who want to add child accounts for individuals who will use services billed to the parent account or to the child accounts.
  • You are a reseller that wants to add your clients as child accounts that will use services billed to the parent account or to the child accounts.
  • You are a company that wants to add your departments as child accounts that will use services billed to the parent account or to the child accounts.


There are three different responsibility levels associated with child accounts as described in the table below:

Responsibility Level Description Usage Accrued by Child Account Recorded Under... Services Billed According To Whose Plan... Invoices Paid By...

Level 1

Standard self pay

Child account

Child account

Child account

Level 2

Parent pay 

Child account

Child account

Parent account

Level 3

Parent usage & pay

Parent account

Parent account

Parent account

You can assign payment responsibility to a master plan instance (MPI) from any account in a parent pay child account's ancestry:


Example: a parent pay child account can have a responsible MPI from a "grandparent" account.


Based on your business needs, set your chosen client parameters that apply to parent‐child accounts as described in Provisioning Setting Parameters. You can find these parameters in the Aria application under Configuration > Notifications> Provisioning Settings.

Important Notes

  • The responsible MPI from the parent account must be a self pay plan.
  • For simplicity, the words "parent" and "child" are used generically throughout Aria's documentation to refer to customers in a hierarchy of accounts. Example: the "parent account" responsible for a "child account's" plan may actually be a "grandparent" account.

    For any account in a hierarchy, you can identify the “chief” account, which is the ancestor at the highest level. This information is returned by the <chief_acct_info> output in these APIs: create_acct_complete_mget_acct_details_all_mget_acct_hierarchy_details_m, and update_acct_complete_m. Example: if you have a child account with a parent and "grandparent", you can identify the "grandparent" account as the “chief” account.

    In the Aria application, you can see a diagram showing any parent, children or "grandchildren" for an account by viewing the account hierarchy.
  • For more information please see the additional important notes about parent‐child accounts.

Best Practices

Parent and Child Billing Dates

The recommended practice is to make the child accounts’ billing dates the same as their parent accounts’ billing dates. Aria allows you to create child accounts whose billing dates are different from their parent account’s billing dates. If a child account’s billing date is different from the parent account’s billing date:

  • Aria will generate an invoice on the child account’s billing date.
  • Aria will not collect a payment for the child account’s balance until the parent account’s billing date.

Statement Presentation

Determine the pieces of child account information that you want to include in the parents’ statements and contact Aria Systems Customer Support to specify your statement template requirements:

  • All child invoice line items, or
  • Only the balance transfer amounts.

Account Statuses

Decide what should happen to a child’s account status when the parent’s account status changes. When a parent’s account status is updated, the child’s account can be updated to the same status assigned to the parent. Please contact Aria Systems Customer Support to set up your parent-child account status options.

Service Credits

Be sure to apply service credits to the correct account:

  • For credits that apply to a child account’s services, apply the service credit to the child account.
  • For credits that apply to a parent account’s services, apply the service credit to the parent account.

Cash Credits

  • For responsibility level 1 (self pay), cash credits should always be applied to the child account.
  • For responsibility levels 2 and 3 (parent pay), cash credits should always be applied to the parent account.


If you need to refund a payment for a child invoice that was paid by a parent account holder, you can issue the refund to the parent account and you can choose to also reverse one or more of the child invoice line items to which the refund applies.

Example: If a child account was charged in error you can issue a refund to the parent account holder, then
reverse one or more child invoice line items.

Parent and Child Account Currencies

If you create a child account with parent pay responsibility, the parent and child accounts must be assigned the same currency. This may reduce potential errors resulting from different currency balances being rolled up together at the parent level.

For additional best practices and preconditions related to account registration in general, please see Account Registration Best Practices.

Move Self/Parent Pay MPIs from Dunning when Paying Parent Account Charges 

The dunning functionality related to parent-pay master plan instances (MPIs) was changed in Release 41. It is now required that dunning groups are associated with MPIs. So, even if a dunning group is not provided by the client upon MPI assignment, an empty dunning group (one containing no attributes) will be created and assigned to the MPI automatically.

Use Cases

Click on any of the links below to see instructions for implementing a few basic parent-child account uses cases with APIs:

  1. Create a Child Account with Self Pay Responsibility
  2. Create a Child Account with a Parent Pay Plan and Aligned Billing Dates
  3. Create a Child Account with a Self Pay Order and a Parent Pay Plan

For additional rules that apply to parent-child use cases, please see the important notes about parent‐child accounts.


Last modified


This page has no custom tags.


This page has no classifications.