← Back to ERP system builders
See how it helps
Allocate shared costs
Distributes shared infrastructure costs with explicit drivers while preserving direct costs and reconciling allocated totals.
shared-cost-allocation
Team members using this skill
When is it useful?
Use when tenant profitability needs a defensible share of common infrastructure.
What does it help you do?
- Keeps directly measured charges separate from allocated overhead.
- Chooses allocation drivers related to actual resource consumption.
- Handles zero usage and rounding without creating or losing cost.
Try asking this
Allocate shared database costs by measured usage and reconcile the result exactly to the original bill. Allocate a bill across active and zero-usage tenants using the approved rule. Show rounding adjustments separately so all shares sum exactly to the invoice.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Shared Cost Allocation
Not every cost arrives neatly stamped with a single tenantId. Base database clusters, reserved GPU pools, shared vector indexes, CDN base fees, and platform background services must be allocated transparently so unit economics and tenant margin calculations reflect full cost.
Workflow
- Keep direct costs and allocated shared costs strictly separate:
- Never overwrite or mutate a tenant's direct attributed cost with allocated overhead.
- Store allocated overhead in distinct ledger or rollup columns (
directCostMicros,allocatedSharedCostMicros,totalFullyLoadedCostMicros) linked to an explicitallocationRuleIdandallocationRunId.
- Choose an allocation driver that matches resource causality:
- Proportional to direct usage (telemetry-driven):
- Allocate shared database compute in proportion to each tenant's query CPU time or row operations.
- Allocate shared worker pool base cost in proportion to each tenant's
cpuCoreMsorgpuMs. -$$\text{AllocatedCost}{\text{tenant}} = \text{SharedPoolCost} \times \frac{\text{DriverMetric}{\text{tenant}}}{\sum_{k} \text{DriverMetric}_{k}}$$
- Fixed / tier-weighted split: Allocate base platform readiness costs across active workspaces by plan tier weight or equal split when usage is zero.
- Hybrid (committed + burst / idle capacity):
- Attribute utilized capacity directly by usage.
- Track unused commitment / idle capacity (
idlePoolCostMicros) explicitly in a platform capacity bucket (or allocate by reserved quota share) so an empty cluster does not make a single active tenant appear to cost$5,000for one request.
- Proportional to direct usage (telemetry-driven):
- Guarantee conservation and zero-division safety:
- Handle zero total driver volume gracefully (when $\sum \text{DriverMetric}_k = 0$, route
100%of the shared pool toplatform:idle_capacityrather than dividing by zero). - Reconcile rounding remainders deterministically (e.g., largest-remainder method) so $\sum \text{AllocatedCost}_{\text{tenant}} + \text{IdlePlatformCost} \equiv \text{SharedPoolCost}$ to the exact microdollar.
- Handle zero total driver volume gracefully (when $\sum \text{DriverMetric}_k = 0$, route
Anti-Patterns to Avoid
- Distorting per-unit marginal cost with idle cluster overhead: Charging a tenant's single API call the entire cost of an otherwise idle 8-GPU node hides true marginal cost and breaks pricing analysis.
- Opaque "magic multiplier" markups: Multiplying direct costs by
1.35xwithout recording the underlying shared pool total and driver formula prevents finance and engineering from auditing infrastructure efficiency.
Included files 1
SKILL.md