How Parent-Child Billing, Bill-To Behavior, and Invoice Rollup Work in Recurly

Sometimes merchants encounter confusion around parent-child account structures, especially when merchants expect all child charges to collapse into one parent invoice or want reporting that clearly identifies who is being billed.

What parent-child relationships control

Parent-child structures are used to model related accounts, including cases where one account is responsible for billing while other accounts represent separate business units, teams, or subscriber groups.

That relationship can affect who pays, how invoices are grouped, and how merchants need to interpret reporting fields.

What "Bill to Parent" means

When a child account is configured to bill to a parent account, the parent is the billing target. That does not automatically mean every child subscription will be rendered on one identical invoice layout in every scenario. Invoice grouping can still be influenced by the broader billing setup and the attributes of the child subscriptions involved.

Why invoice rollup may not produce one single invoice

Merchants expect multiple child subscriptions to roll into one invoice, only to see the system create separate invoices instead. Common reasons include:

• different billing context across subscriptions
• differences in address or tax treatment
• configuration combinations that do not behave the way the merchant expected
• renewal or invoice-generation timing that is close, but not effectively identical

If multiple shipping addresses are involved, invoice grouping and tax outcomes may become more complex rather than more consolidated.

Why tax and shipping details can complicate rollup

Some merchants want invoice aggregation while also preserving child-level shipping distinctions. In those cases, the tax outcome may reflect billing and address rules differently than the merchant expects. If a merchant's requirement depends on both consolidated invoicing and separate shipping or tax treatment, that combination should be validated carefully before rollout.

How to think about reporting and "Bill-To"

Merchants often look for a simple field that tells them who was billed in a hierarchy. In practice, reporting usually works better when the merchant considers both:

• the parent-child relationship itself
• the billing ownership logic for the invoice or account

If you are exporting data, fields such as the parent account reference may help identify the relationship, but they may not fully answer every "who is the bill-to party?" reporting question on their own.

What to check before troubleshooting

• Whether the child account is explicitly configured to bill to the parent
• Whether the subscriptions share the same renewal timing and invoice expectations
• Whether multiple shipping addresses are involved
• Whether tax should be based on billing details, shipping details, or a more complex configuration
• Which export fields the merchant is using to identify parent relationships and bill-to ownership

Best practices

• Validate hierarchy behavior with a realistic test case before large migrations.
• Do not assume invoice rollup and bill-to-parent behavior solve every reporting need automatically.
• Test tax outcomes whenever shipping addresses and consolidated billing are both important.
• Document how your finance team will identify billed parties in exports before you rely on those feeds operationally.