Hierarchical Subtotal Rollup¶
Reporting procedure — instantiates Regroupable Aggregation
Rolls governed local subtotals up a reporting hierarchy so the total's meaning survives reorganizations, unequal groups, and empty branches — the parentheses move, the number doesn't.
Hierarchical Subtotal Rollup brings the archetype into finance, administration, and reporting: local totals become regional totals become an enterprise total by adding subtotals up a tree of organizational units. Its defining concern is that each subtotal carries its definition — period, currency basis, entity, inclusion rules, revision version — so that combining subtotals composes meanings, not just numbers. A subtotal that is arithmetically addable but semantically incompatible must be refused. When the definition and compatibility hold, reorganizing the hierarchy leaves the covered-record total unchanged; the tree is an execution partition, not part of the answer. It produces governed subtotals and their rollup; it does not audit them against an independent recomputation.
Example¶
A holding company consolidates revenue from 40 subsidiaries into a group figure. Each subsidiary reports a subtotal, but the subtotals are not naively addable: two subsidiaries book in euros, the rest in dollars; one uses a fiscal year offset by a quarter; a newly acquired unit reports under a revenue-recognition policy the others retired last year. Hierarchical Subtotal Rollup makes the consolidation legitimate by attaching a definition to every subtotal — currency basis, period, entity, and policy version — and by enforcing a compatibility rule at each merge: euros are converted to a common basis before addition, the off-cycle unit's period is aligned, and the stale-policy unit is refused until restated rather than silently summed.
A subsidiary that was dormant all year rolls up as a defined zero — genuinely no revenue, the empty-group identity — not as a missing row. When the group later reorganizes those 40 units into six new divisions, the rollup tree changes completely, yet the enterprise revenue is identical, because the meaning lived in the subtotals' definitions, not in the shape of the tree. The outcome is a consolidated figure that survives reorganization and unequal unit sizes.
How it works¶
- Define before you add. Each subtotal declares population, period, currency basis, entity, and policy version; the definition travels with the number.
- Check compatibility at every merge. Subtotals combine only if their definitions align; mismatches are converted through an explicit bridge or refused, never coerced by matching field names.
- Handle empty and singleton branches. A unit with no activity rolls up as a defined identity, distinguished from missing or suppressed data.
- Keep the tree meaningless. The hierarchy is an execution partition; changing it must not change the covered-record total.
Tuning parameters¶
- Definition richness — how much metadata each subtotal carries; more enables safe consolidation across differences but adds reporting burden.
- Compatibility strictness — fail-closed on any mismatch versus governed conversion; strict protects integrity, lenient eases migrations.
- Identity semantics — what an empty branch means (true zero, suppressed, not-yet-reported) and how it renders.
- Rollup depth — how many hierarchy levels are materialized versus computed on demand, trading storage against query cost.
- Restatement handling — whether a late correction re-rolls the whole tree or patches one branch, trading freshness against churn.
When it helps, and when it misleads¶
Its strength is stable totals across reorganizations and unequal group sizes — the number means the same thing before and after a restructure, because the definitions and compatibility rules, not the tree, carry the meaning. It is what lets an organization change its reporting hierarchy without re-litigating what its totals mean.
Its failure mode is the classic average-of-averages[n1] corruption when the "subtotal" is really a rate or ratio: adding or averaging regional percentages without their populations silently reweights the groups. Combining incompatible definitions because the columns share names is the other standard misuse. The guarding discipline is to carry sufficient state for the metric (numerator and denominator for a rate, not the rate alone) and to enforce compatibility at every merge — and, separately, to reconcile the rollup against an independent recomputation, which is Rollup Reconciliation Report's job, not this one's.
How it implements the components¶
aggregate_semantics_contract— each subtotal's declared population, period, currency, and policy is the contract that fixes what the total means before hierarchy enters.merge_compatibility_contract— the per-merge check that refuses or bridges definitionally incompatible subtotals.identity_and_empty_group_policy— the defined treatment of dormant and singleton branches as true identities, not missing rows.
It does not prove coverage against an independent baseline: partition_lineage_map and reference_computation_path belong to Rollup Reconciliation Report, which audits the rollup this mechanism produces.
Related¶
- Instantiates: Regroupable Aggregation — it is the archetype's rollup form for organizational reporting.
- Consumes: Mergeable Summary Object can supply the governed subtotal objects the rollup adds.
- Sibling mechanisms: Rollup Reconciliation Report · Versioned Merge Protocol · Mergeable Summary Object · Weighted Moment Accumulator · Tree Reduction · Map–Combine–Reduce Pipeline · Deterministic Pairwise Accumulation · Associativity Property Test · Randomized Partition Replay
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Hierarchical Subtotal Rollup operates as a repeatable ordered procedure or handoff sequence that coordinates action because it rolls governed local subtotals up a reporting hierarchy so the total's meaning survives reorganizations, unequal groups, and empty branches — the parentheses move, the number doesn't
Independent corroboration: The frozen evidence defines Hierarchical Subtotal Rollup as 'Rolls governed local subtotals up a reporting hierarchy so the total's meaning survives reorganizations, unequal groups, and empty branches — the parentheses move, the number doesn't', so its operative form is Protocol, Workflow & Routine.
Nearest alternative: Control, Automation & Runtime — The evidence specifies a repeatable governed rollup procedure without requiring automatic execution-time control.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Accounting & Auditing
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Governed subtotal aggregation across reporting hierarchies is an accounting and financial-reporting practice.
Related originating lineages:
- Mathematics — Associative aggregation and weighted-ratio laws supply the formal reason regrouping can preserve totals.
Review resolution: Both reviewers independently assign accounting_auditing as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry generalizes the established mechanism without creating a new composite lineage.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] The average-of-averages error combines group means as if they were equally weighted, ignoring that groups differ in size; the correct rollup carries numerator and denominator (or sum and count) and divides only at the end. It is the canonical failure the archetype exists to prevent. ↩