Start by defining billing ownership before account relationships: a parent-child model only works when each child has a clear payer, role scope, and traceable handoff from invoice to ledger to reconciliation. Use parent-paid for centralized collections, child-paid for local budget control, and mixed ownership only with written rules by subsidiary type. Then enforce checkpoints on invoice state, idempotent posting, payout evidence, and role inheritance during reorgs so month-end close does not turn into manual cleanup.
Start with financial responsibility, not the org chart. In a parent-child billing setup, the real design question is simple: which accounts are structurally related, and which account is financially responsible when invoices, ledger entries, reconciliation, settlement, and payout records start moving.
Have four things in hand before you model anything. You need a legal entity map, the proposed billing owner for each parent and child account, the role list for who can view and approve charges, and the evidence you expect to retain after posting and payment activity. You can build a hierarchy without that prep, but you will struggle later to prove who owed what and why.
Define the hierarchy and the billing owner as separate decisions. An account hierarchy is the structured relationship between parent and sub-accounts inside one organization. A billing hierarchy is different. It is the configuration where one account is financially responsible for another account's bills.
That distinction matters because many implementations need two setups, not one. You need the structural parent-child designation and the role or visibility setup around it. Your first checkpoint is to verify that every child account has both a parent assignment, if applicable, and an explicit billing owner. One failure mode to watch for is assuming that if a child rolls up to a parent for reporting, the parent should also pay. Sometimes that is true. Sometimes it is not, and that can create invoice disputes.
Tie your transaction records to the ownership model early. Payment reconciliation compares your internal records, such as invoices and fees, with external records like settlement files, payout files, and bank statements. Payment settlement is the stage where a transaction is finalized and funds are transferred.
For operators, that means deciding what evidence must exist at each handoff. At minimum, keep the invoice record, the payer assignment, the ledger posting reference, and the settlement or payout file identifier that lets finance trace the movement of funds. Use one practical check here: after posting, can your team match customer-facing amounts to ledger balances and then to external settlement and payout records without manual guesswork?
Use this guide to force explicit choices, not to chase a perfect hierarchy model. Hierarchy design is useful because it helps coordinate billing, accounting, and reporting across complex multi-entity customers, but it only works if permissions and financial accountability line up.
If you are using a subscription management platform, confirm whether hierarchy support covers both account structure and user visibility, not just one of them. If you are building on a custom stack, decide now how you will preserve the evidence pack finance needs when records are posted, reconciled, and reviewed later. That operating discipline is what keeps parent-child billing from turning into a month-end cleanup project.
This pairs well with our guide on Additional Child Tax Credit for U.S. Expats on Form 8812.
Decide who pays before you decide who reports to whom. A hierarchy can look clean in the admin UI and still fail operationally if billing ownership is unclear.
Use this as a starting point, not a universal rule: start parent-paid when collections and invoicing are centralized; start child-paid when business units manage their own spend and payment responsibility. Use mixed ownership only when subsidiary types have stable, documented differences.
| Model | When it usually fits | Main upside | Main risk | Verification point |
|---|---|---|---|---|
| Parent account as billing owner | Centralized billing where one account is financially responsible for another; regional headquarters overseeing branches or franchise locations | Cleaner collections path and a single parent invoice trail | Child-level charge context can get lost if rollup detail is weak | Confirm whether invoices are parent-summary or include child breakdown, then test traceability from child activity to parent invoice to ledger posting reference |
| Child account billing | Separate business units or entities that manage their own budgets and payments | Clear local accountability and cleaner local invoice ownership | Collections and payment methods fragment across many accounts | Confirm each child has explicit payer assignment, invoice recipient, and payment method before charges post |
| Mixed ownership by subsidiary type | Different subsidiary classes need different billing treatment | Better fit to real operating structure | Exception handling grows quickly when rules are vague | Confirm a written ownership rule per subsidiary type and an effective date for each rule |
Use parent-paid when money is controlled centrally. Hierarchy implementations can assign invoicing and payment ownership, and parent-paid is a standard model where one account pays another account's bills. If headquarters funds usage across branches, make the parent the billing owner.
Then choose invoice shape up front: parent invoice with child-level breakdown, or summarized parent line items. The first helps allocation and dispute work; the second reduces invoice volume but shifts detail requests later.
Checkpoint: run a sample branch charge and verify finance can trace child activity to the parent invoice and into the ledger posting record used for reconciliation.
Keep billing local when accountability is local. If a child owns budget approval, payment responsibility, and invoice handling, child-paid is usually safer. This is a common fit for organizations operating as separate business units, even when reporting rolls up centrally.
A common failure mode is assuming parent visibility means parent payment ownership. It does not. Record payer assignment explicitly for each child account.
Use mixed ownership only when you can state the rule clearly for each subsidiary type. It works when entity classes truly differ; it fails when used as a workaround for unresolved ownership decisions.
Before go-live, define four non-negotiables for each billing path:
Do not leave these implied by hierarchy structure alone. Store them with the account setup artifacts, alongside billing owner, invoice recipient, and rollup rule. Add a product gate so a new child account cannot become billable until those ownership fields are complete; this reduces wrong-party invoicing risk.
You might also find this useful: Subscription Billing Platforms for Plans, Add-Ons, Coupons, and Dunning.
Define boundaries around durable business identity and reporting needs, not the current org chart. Your Company account, child account, and payer setup should still be clear after names, managers, or regional structures change.
Start with legal-entity identity, then map hierarchy. A legal entity is the unit that can enter contracts and prepare financial statements, so use that to decide whether something should be its own Company account or sit under a shared parent account.
Give each entity a stable internal ID that is independent of display name changes. That ID should still map to the same legal-entity record, invoice recipient, and payer setup over time. This is critical when billing rolls up, because payment responsibility can be determined by bill-unit payment configuration, not just the account record. Treat hierarchy placement and payer ownership as separate checks.
Verification point: for any child, confirm quickly from your setup sheet what legal entity it represents, who pays, and how it rolls up for reporting.
Set hierarchy depth and exception rules before growth forces ad hoc structures. Some systems support nested child relationships, and child entities can remain independently configured, but some billing platforms also enforce that a child can belong to only one parent account.
Write a short operating rule: standard depth, who approves exceptions, and what must be documented for a new subsidiary. Design this for auditability and reporting changes across departments, cost centers, and countries, not just for today's org chart.
Red flag: if finance cannot explain why a node exists without a custom diagram, the boundary is likely too complex.
Create a boundary prep pack before creating records. Keep it explicit and reviewable:
Confirm platform constraints early. In B2B Edition-style setups, hierarchy support can vary by store, and preview features may have restricted functionality. Verify your environment supports the hierarchy shape you want, confirm child configuration behavior, and confirm payout responsibility where funds accumulate in connected account balances.
Final checkpoint: run one parent, one child, and one reorg scenario before go-live. If reporting rollup changes would blur payer, tax, or payout ownership, tighten boundaries before launch.
If you want a deeper dive, read Reverse Trials for B2B Platforms: Why Giving Full Access First Converts More Paid Accounts.
Set permissions by financial accountability, not by org-chart position. In parent-child setups, hierarchy can enable subsidiary visibility, but approval and billing actions should be granted explicitly by role.
Define roles by billing action before assigning hierarchy access. In a hierarchy-enabled Buyer Portal, parent-layer users can access subsidiary portals only when roles are configured for that access, so do not treat parent-child structure as automatic permission.
| Role | Must be able to see | Can do | Must not do by default |
|---|---|---|---|
| Buyer Portal operator | Own account orders, invoices, payment history | Pay, download invoice, raise billing issue for scoped entity | Approve charges for subsidiaries they cannot view |
| Company account admin | Users, subsidiary access scope, account settings for assigned entities | Assign scoped access, manage local operators | Grant finance authority to themselves without review |
| Finance reviewer | Invoice history, payment status, relevant child rollups | Review, reconcile, approve within assigned billing scope | Operate outside assigned billing profile or invoice section |
Checkpoint: test one child record per role and confirm the user can see the invoice and payment history required for each allowed action.
Use fine-grained billing permissions (for example, custom roles) instead of broad top-level finance access. When someone only needs a billing profile or invoice-section scope, grant at that scope to avoid over-privileging through inherited higher-level roles.
Watch for two common misses:
Handle inheritance explicitly whenever a child account moves to a new parent account. In some models, higher-level billing permissions inherit downward and cannot be removed at lower levels, so reorgs need a controlled permission-change workflow.
Use this move checklist:
invoice history, payment history, and approval paths with local and parent users.If you want a related workflow lens, read Credit Insurance for B2B Sales to Manage Unpaid Invoices.
Run this flow as a gated sequence, not an automatic handoff after a successful charge: invoice created and finalized, payment confirmed, ledger posted once, reconciliation completed, then settlement and downstream payout execution.
| Stage | What must be true before moving forward | Evidence to keep |
|---|---|---|
| Invoice | invoice status is correct for collection and payer assignment is correct | invoice ID, status transition record, payer assignment snapshot |
| Payment | payment outcome is clearly classified (success, failed, incomplete) | payment event ID or processor reference |
| Ledger | exactly one posting exists for the intended economic event | journal reference, posting timestamp |
| Reconciliation | invoice, payment, and posting align, or the item is routed to exception handling | reconciliation result, export file, exception ticket if needed |
| Settlement and payout | release target matches approved payer relationship and batch inclusion is confirmed | settlement batch ID, payout export or payout-linked transaction list |
Create the invoice only after billable inputs are complete, then verify status before collection. In a common lifecycle, invoices start as draft (editable) and become open when finalized, so a draft invoice should not be treated as collectible.
Subscription and metered paths diverge at this stage. In a subscription billing engine, verify the account, term, and billing owner before finalization. In usage-based billing, verify usage ingestion first because metered billing is billed in arrears from measured consumption; if ingestion is incomplete, the invoice is not settlement-ready. For architecture context, see How to Build a Subscription Billing Engine for Your B2B Platform: Architecture and Trade-Offs.
Check at least one sample invoice per payer pattern: draft to open, payer assignment, and amount source (plan charge vs usage records). Also gate stale state: if async processing is delayed, do not treat a stale snapshot as settlement-ready. Stripe documents a 72-hour fallback before it attempts invoice finalization and sending when webhook success responses are not received.
Confirm payment, then post to the ledger once. A paid invoice without a matching posting is incomplete, and duplicate postings from retries create reconciliation risk.
Use idempotent requests for retryable posting operations to prevent duplicate side effects. Stripe supports idempotency for safe retries and documents reuse of the same idempotency key within 24 hours. Operationally, enforce one payment event to one journal reference; if one event maps to multiple journal references, stop and resolve before settlement.
Handle non-success outcomes explicitly. If payment fails or remains incomplete, the invoice can stay open and later move to void or uncollectible. Do not let unpaid open invoices enter a posted-and-settled path.
Run reconciliation before settlement, and release payout execution only after reconciliation and payer-assignment checks pass. Reconciliation should confirm invoice-to-payment alignment, payment-to-ledger alignment, and settlement target alignment with the approved payer relationship.
Apply these failure gates before release:
The parent-child gate is critical: some hierarchy models require prerequisite checks for child-to-parent assignment and do not allow direct relationship overrides. If settlement targets a parent stream while the invoice payer is the child, verify reassignment approval and effective timing before release.
For automatic payouts, keep payout-level proof that settled transactions were included in the payout batch. A payout reconciliation report is built for this, and Stripe also documents listing payout-linked balance transactions via the payout parameter. Preserve the artifacts your stack exposes (event IDs, journal references, reconciliation exports, payout files) so each invoice can be traced through settlement.
Related: Usage-Based Billing Explained: How Consumption Pricing Works for B2B SaaS Platforms.
Your close pack is finance-ready only if one invoice can be traced from subsidiary statement to parent account rollup to payout evidence. Start by defining outputs by audience, then lock reconciliation checks and exception ownership to those outputs.
Define three reporting views that trace back to the same source records: child-level reporting, parent-level reporting with child detail, and parent summary reporting. Avoid separate team exports that create conflicting versions of truth.
| Audience | Required output | Verification point |
|---|---|---|
subsidiary operator | Entity-level statement for that child account | Statement totals tie to that entity's finalized invoices and ledger postings |
parent account finance lead | Rollup with child breakdown | Parent total equals the sum of included child totals for the period |
| Central finance | Period-close pack | invoice, ledger, reconciliation, settlement, and payout evidence reference the same population |
For month-end defensibility, retain the exact report export used for close, the period definition, and the entity-mapping snapshot for that close period.
Set reconciliation checkpoints in money-flow order: invoice total vs ledger postings, parent rollup vs child totals, then settlement status vs payout status. Include bank-to-general-ledger cash reconciliation in the pack.
A common benchmark is monthly reconciliation within 30 days of receiving the bank statement. For payouts, automatic payouts simplify reconciliation because transaction-to-payout association is maintained; with manual payouts, your team must reconcile each payout against transaction history. Include a transaction-level settlement file (for example, a settlement details report) so reviewers can verify settled-and-paid-out activity directly.
Run an exception queue with named owners, explicit status transitions, and close deadlines. Route exceptions to a user worklist or email, and on rejection, return ownership to the preparer with reviewer comments.
Keep unresolved items visible in the close pack with owner, due date, and current evidence. Supporting workpapers should be detailed enough for an independent reviewer to follow the reconciliation, corrective actions, and signoff path without relying on oral context.
Related reading: How to Determine the Maximum Value of a Foreign Bank Account for FBAR.
Protect your close process during reorgs by applying hierarchy changes forward from an effective date, not backward into closed periods. Keep historical records intact: do not rewrite old invoice ownership or retrofit closed invoices to match a new org chart.
| Rule | Detail | Checkpoint |
|---|---|---|
| Define the change first | Record the old parent, new parent, effective date, affected entities, and approver before updating any Company account or child account links | Verify with a before-and-after mapping file; keep the pre-change export if using CSV reassignment |
| Preserve history | Treat finalized invoices as historical records and keep prior invoices and ledger lineage tied to the original business event | Use future-dated finalization for upcoming invoices instead of editing closed invoices when cutover timing is needed |
| Split mid-cycle changes | Use proration for the remaining billing-period portion to create a clean old-owner segment and new-owner segment | Pre-change segment should reconcile through the old parent path and post-change segment through the new parent path, with no single invoice crossing both owners after the effective date |
Define the change before updating any Company account or child account links. For a merger, spinout, or payer reassignment, record the old parent, new parent, effective date, affected entities, and approver. If you run a hierarchy model that supports bulk parent reassignment by CSV export-update-import, keep the pre-change export as part of your evidence.
Verify with a before-and-after mapping file showing exactly which companies moved. Review hierarchy-aware roles in the same change window, since parent-child designation and subsidiary visibility controls are linked.
Preserve history by treating finalized invoices as historical records. Once finalized, most invoice details are locked, and finalized invoices cannot be moved back to draft. Keep prior invoices and related ledger lineage tied to the original business event, then apply the new hierarchy only from the effective date forward.
If you need controlled cutover timing, use future-dated finalization for upcoming invoices instead of editing closed invoices.
For mid-cycle ownership changes, use period splitting as your operating rule instead of retrofitting a closed invoice. Mid-term changes are commonly handled with proration for the remaining billing-period portion, which creates a clean old-owner segment and new-owner segment.
Checkpoint: the pre-change segment should reconcile through the old parent path, and the post-change segment through the new parent path, with no single invoice crossing both owners after the effective date.
For a step-by-step walkthrough, see Fair Credit Billing Act for a Business-of-One: How to Dispute Credit Card Billing Errors.
Fast recovery comes from treating hierarchy breaks as control failures, then fixing source records before normal billing flow resumes.
| Failure mode | Immediate action | Correction |
|---|---|---|
| Wrong-party invoicing | Pause new charges on the affected billing-owner path | Review finalized invoices from the error point forward; void an invoice sent by mistake or use a credit note to adjust the amount |
| Approval gaps | Tighten role scopes where parent visibility was granted too broadly | Capture current role assignments before changes and retest the approval path so parent reviewers and local users only see what policy allows |
| Reconciliation drift | Compare subledger balances to the matching general-ledger balances | Match transactions to accounting entries, replay journal derivations, identify the out-of-balance transactions, and regenerate close reports after postings are corrected |
| Vendor feature assumptions | Treat vendor feature pages as starting points, not final proof | Validate ownership logic, role behavior, export fields, and parent-child reporting in your own tenant before rollout |
Contain wrong-party invoicing by pausing new charges on the affected billing-owner path and reviewing finalized invoice records from the error point forward. If an invoice was sent by mistake, voiding is a supported correction and keeps a paper trail; if you only need to adjust the amount, use a credit note instead of recreating the full invoice. Resume settlement only after corrected invoices map to the approved ownership records.
Close approval gaps by tightening role scopes where parent visibility was granted too broadly. In BigCommerce B2B Edition, these controls sit in the Buyer Portal, and custom user roles with specific permissions are supported. Capture current role assignments before changes, then retest the approval path so parent reviewers and local users only see what policy allows.
Fix reconciliation drift from the ledger outward, not from reports backward. Compare subledger balances to the matching general-ledger balances, then match transactions to accounting entries where they do not tie. Replay journal derivations from source records, identify the transactions behind the out-of-balance position, and regenerate close reports only after postings are corrected.
Treat vendor feature pages from Recurly or BigCommerce as starting points, not final proof for your process. BigCommerce notes that some capabilities are requirement-dependent, and its Account Hierarchy announcement framed availability as request-based for eligible stores starting on March 5. Validate ownership logic, role behavior, export fields, and parent-child reporting in your own tenant before rollout.
We covered this in detail in How to Handle Taxes for a US Citizen Child Born Abroad. If you want a quick next step, Browse Gruv tools.
The design that holds up is the one you can trace end to end. If a parent-child rule does not produce a clear invoice owner, a visible ledger effect, and a reconciliation check before settlement, it is still a diagram, not an operating model.
Make that your standard. Reconciliation checks that your internal records match what appears on statements. Settlement is the stage where funds move from buyer to seller. Treat them as connected but separate controls. If ownership is unclear at either point, stop and fix it before money moves.
| Check | What to confirm | Key check |
|---|---|---|
| Billing ownership | Write down the billing owner for each parent account, child account, and exception case | For any sample invoice, one team should be able to answer who receives it, who approves it, and who is financially responsible for payment |
| Role permissions | Test one parent user and one child admin and confirm exactly what each can see and change under the configured roles | Parent visibility should follow money responsibility, not exceed it |
| Transaction sequence | Confirm explicit stage or status transitions through invoice, reconciliation, payment, and settlement | Retain invoice status, payment document status, journal or ledger reference, and the record showing when settlement was released |
| Reconciliation outputs | Confirm entity-level detail, parent rollup, and consolidated close support | Child totals should roll up cleanly to the parent view and ledger entries should compare back to source statements during reconciliation |
| Failure owners | Assign named owners for misbilling, access issues, and rollup drift | If the wrong party is invoiced or parent and child totals do not match, freeze the affected path, correct the ownership or access rule, and regenerate the reconciliation output before settlement continues |
Write down who is the billing owner for each parent account, child account, and exception case. Your verification point is simple: for any sample invoice, one team should be able to answer who receives it, who approves it, and who is financially responsible for payment. If you cannot answer that in one line per entity, your hierarchy is not ready.
Parent visibility should follow money responsibility, not exceed it. If you allow parent users to view subsidiary data, test one parent user and one child admin and confirm exactly what each can see and change under the configured roles. The red flag is familiar: payer status quietly turning into broad edit access, which creates approval gaps and disputed changes later.
Your stack needs explicit stage or status transitions through invoice, reconciliation, payment, and settlement, not a loose set of updates hidden across tools. Check one real transaction and retain the evidence pack: invoice status, payment document status, journal or ledger reference, and the record showing when settlement was released.
Finance typically needs three lenses: entity-level detail, parent rollup, and consolidated close support. The key checkpoint is that child totals roll up cleanly to the parent view and that ledger entries can be compared back to source statements during reconciliation. If the rollup only works in a dashboard but not in an export the team can review, that is not sufficient evidence.
Assign named owners for misbilling, access issues, and rollup drift. If the wrong party is invoiced, or parent and child totals do not match, freeze the affected path, correct the ownership or access rule, and regenerate the reconciliation output before settlement continues. That response path matters as much as the original design.
That is the real finish line: not a polished org tree, but a repeatable, auditable chain from invoice through settlement that your finance team can defend at close. If you want to confirm what's supported for your specific country/program, Talk to Gruv.
It is a feature that creates a parent and child relationship between accounts so billing responsibility and visibility can be managed intentionally, not ad hoc. In practice, it answers one core question: which account is financially responsible for which bills. If your team cannot point to the billing owner for each child, the hierarchy is not really defined yet.
Use parent-paid when finance wants centralized payment responsibility and one consolidated payment path across subsidiaries. SAP’s hierarchy example supports this model directly, where the parent administrator can pay for all subsidiaries’ subscriptions in a single payment. Keep child-paid when local entities need their own charge responsibility, budget control, or dispute handling. Some platforms, including Recurly, support either parent or child responsibility, so the right answer depends on your operating model, not a universal rule.
Yes, but only if you separate billing ownership from operating permissions. A child can remain locally managed for day-to-day activity while the parent pays. Keep local admins scoped to their own records, and give the parent only the cross-entity visibility policy requires. A failure mode to avoid is assuming payer status should automatically grant broad edit rights, because that is where approval and access errors start.
Start with view access to the subsidiary data needed for review, approval, invoice checking, and payment follow-up. Then add edit rights only where the parent actually owns the financial outcome. In BigCommerce B2B Edition, this is handled through explicit role setup, including roles that let parent-company users view subsidiary data. Your checkpoint is simple: test one parent user and one child admin, then confirm access changes are explicit rather than inherited by accident.
A common pattern is a parent division or headquarters overseeing branches or regional entities. Another practical pattern is to preserve parent-child structures that already exist in your ingested customer data instead of inventing a new tree inside billing. If franchises or regional units operate with different payers, use mixed ownership carefully and document where rollups stop. Unclear depth is a red flag because finance closes tend to break at the exception edge.
Confirm whether the capability is generally available in your tenant or still effectively limited, because some hierarchy features can be preview-only and not meant for production use. BigCommerce’s own rollout language included request-based access starting on March 5, which is a good reminder not to treat vendor pages as proof of readiness. Before go-live, verify parent or child payer assignment, parent and child designation, role behavior, and one full invoice to ledger trace. Then save screenshots and sample exports as your evidence pack.
A former tech COO turned 'Business-of-One' consultant, Marcus is obsessed with efficiency. He writes about optimizing workflows, leveraging technology, and building resilient systems for solo entrepreneurs.
Includes 1 external source outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
If you are designing a B2B subscription billing engine, get the close and reconciliation model right before you chase product flexibility. A durable sequence is to define recurring billing scope (plans, billing periods, usage, and trials), then map settlement and payout reconciliation to transaction-level settlement outputs, and finally tie that discipline into month-end close controls. The real test is simple: finance should be able to trace invoices, payments, and payouts from source events through settlement records into reconciled close outputs without ad hoc spreadsheet rescue.
Treat a reverse trial as a monetization decision, not a short-term growth play. If your B2B platform cannot support a clean downgrade, clear plan boundaries, and reliable billing and entitlement changes, more full-access signups may not help much.
Usage-based billing works best when customer value rises with measurable consumption rather than with a fixed license. It can improve pricing fit, but only if pricing logic, billing data, and finance controls are designed together from the start.