Shared-cost allocation chain

Pool: amount, period, and scope

Driver: weight, revenue, labor, or activity

Bridge: target grain and weight

Result: allocation and residual

Interpretation: versioned management assumption

A normal join cannot turn a shared invoice into order cost

A freight invoice may cover warehouses, parcels, and order lines. Platform service, media, storage, and head-office costs often live above transaction grain. Joining them by date or store duplicates value as detail expands.

Define a cost_pool, eligible scope, driver, and target grain, then produce an allocation bridge or fact. Every row retains source pool, target key, weight, amount, version, and residual treatment so totals return to source.

Separate direct attribution from allocation

Parcel charges with order IDs and item-level commissions should be posted directly. Only costs that cannot be economically traced, but need a management view, should enter a pool. Record ledger account, period, entity, channel, warehouse, currency, and allowed targets.

Allocating everything by revenue creates false precision. If no defensible driver exists, retain an unallocated layer. Honest incompleteness is preferable to an exact-looking SKU margin built on an arbitrary rule.

Declare one target grain and eligible scope

A target may be order, line, SKU-store-day, customer, or profit center, but one run must state one grain. Restrict eligibility by entity, warehouse, channel, campaign, or service relationship before computing weights.

Cancellation, refund, gifts, internal trades, and cross-period orders require explicit policy. If an order-level amount must reach lines, execute a second governed allocation with parent-child lineage rather than repeating the header amount.

Choose drivers related to resource consumption

Freight may use chargeable weight, volume, distance, or parcel count; storage may use pallet-days; service may use case minutes. Revenue is convenient but may poorly represent consumption.

Document business rationale, source, completeness, owner, and fallback. Compound drivers are possible when their added complexity produces testable value. Do not select the driver after seeing which department benefits.

Enforce weight and amount conservation

For pool p and eligible target i, weight_i equals driver_i divided by the driver total, and allocated_i equals pool_amount times weight_i. Require weights to sum to one and allocations plus explicit unallocated amount to equal the pool.

When the driver total is zero, send the pool to unallocated, use an approved fallback, or apply a documented equal split. Retain fallback_reason. Silent divide-by-zero or dropping the pool is unacceptable.

Persist versioned input and run evidence

Store pool_id, target_key, driver value and total, weight, allocated amount, currency, policy_version, input_watermark, run_id, status, and creation time. Create a new version when invoice, population, or policy changes.

A final amount alone cannot explain whether a change came from a late order, refund, driver correction, or algorithm. Draft and approved allocations should have different publication status.

Make rounding residual deterministic

Currency rounding creates a residual. Use a documented method such as largest remainder or assign it to the greatest weight under a stable tiebreaker, then retain rounding_residual.

Never depend on unordered last-row behavior. Multistage allocation should carry approved precision through each stage and reconcile only under a defined final rule.

Keep management allocation separate from causality

Direct cost is traceable evidence; allocated cost is a policy-based management view. Publish contribution_before_allocation, allocated_cost, and profit_after_allocation with policy version. Changing the driver changes segment margin but not group profit.

The result does not prove an order caused head-office cost. Use it for planning and responsibility discussions with sensitivity analysis, not as sole causal evidence for closing a product or penalizing a team.

Accept through edge cases, replay, and reconciliation

Test zero drivers, credits, negative pools, partial refunds, late targets, cross-period invoices, deleted targets, currency mismatch, extreme weights, and duplicate runs. For every pool, validate eligible uniqueness, weight sum, amount conservation, and lineage.

Replay a historical month under the original policy, then restate under a new one. Both versions should coexist and explain the difference. Reconcile ledger, invoice, and order samples rather than approving a plausible dashboard total.

BuildTable.ai boundary

Pilot one well-defined pool, remove directly attributable cost, freeze scope and driver, build the bridge and residual rule, publish before-and-after contribution, and obtain finance and business approval. Monitor unallocated share, fallback use, restatement impact, and reconciliation.

BuildTable.ai may be evaluated for cost-pool, driver-bridge, and result-table modeling. This article does not establish automatic driver selection, accounting allocation, or correct profitability decisions. Connectivity, orchestration, approval, versioning, and permissions must be verified for the actual project.

How should shared freight and platform fees reach order profitability?