CAM Reconciliation

Gross-Up Normalization Logic

Gross-up normalization scales the variable, occupancy-driven portion of a CAM expense pool up to a stated target occupancy before any tenant split occurs. It is the normalization stage of the calculation core described in expense allocation logic and rule engines, and it exists to solve a specific unfairness: when a building sits half-empty, occupancy-sensitive costs like janitorial and utilities arrive lower than they would at full occupancy, which — without correction — leaves the landlord recovering a thin slice of essentially fixed overhead from the tenants who did show up. Normalization rewrites those variable costs to the level they would have reached at a contractually agreed occupancy, so a tenant in a lightly let property still pays a share that reflects a working building rather than a discount subsidized by an accident of vacancy. Crucially, this stage runs before pro-rata distribution and touches only the variable component of a pool; fixed obligations such as real estate taxes and insurance pass through untouched. Getting the split right — which dollars are elastic to occupancy and which are not — is the entire craft of the stage.

The gross-up normalization stage An expense pool separates into a fixed portion, which passes through untouched, and a variable portion, which is scaled by a gross-up factor of target occupancy divided by actual occupancy. An occupancy-floor clamp bounds that factor. The two portions recombine into a grossed pool that then feeds the pro-rata allocation stage. Expense pool Fixed portion Variable portion Gross-up factor Grossed pool Pro-rata allocation taxes · insurance janitorial · utilities × target ÷ actual Occupancy floor clamp passes through
The fixed portion passes through untouched while the variable portion is normalized to the target occupancy, then both recombine before distribution.

Prerequisites & Data Contracts

Normalization is a transformation, not a source of truth, so it depends entirely on the quality of four inputs arriving in a defined shape. If any one of them is wrong, the stage will produce a plausible number that is quietly indefensible, which is the worst failure mode in reconciliation.

The first input is a per-expense variable/fixed classification. Every pool that reaches this stage must carry a flag — or, more usefully, a split — declaring how much of it is elastic to occupancy and how much is not. This is the input teams most often get wrong, because they conflate it with a different axis. Whether an expense is variable is not the same question as whether it is controllable. A management fee computed as a percentage of collections is controllable in the sense that the landlord influences it, yet it may be treated as fixed for gross-up purposes if the lease says so; a snow-removal contract is largely non-controllable weather-driven cost, yet it barely moves with occupancy. The distinction that governs this stage is elasticity to occupancy, and it must be sourced deliberately rather than inherited from the controllable registry maintained for controllable vs non-controllable expense segregation, which answers a related but separate question about which costs a cap constrains. Variable is not a synonym for controllable, and a rule engine that treats the two flags as interchangeable will gross up the wrong pools.

The second input is the actual occupancy for the period, expressed as a fraction of rentable area that was leased and generating recovery obligations over the reconciliation window. In practice this is a time-weighted figure — a suite vacant for four months and occupied for eight contributes a fraction, not a binary — and the occupancy denominator used for normalization must be reconciled against the same rentable-area basis that the downstream allocation uses, or the two stages will disagree about how full the building was.

The third input is the gross-up target percentage, the occupancy the lease directs the landlord to normalize to. Ninety-five percent is the market-standard figure and appears in a large share of institutional office leases, but the number is a negotiated lease term and the engine must read it per pool from the abstract rather than hard-coding it. Some leases specify 100%, a handful specify 90%, and a pool with no gross-up clause carries no target at all and skips this stage entirely.

The fourth input is the occupancy floor, a contractual lower bound on the occupancy figure used in the denominator. Its job is protective: without it, a building at 15% occupancy would produce a gross-up factor large enough to multiply a tenant’s variable share several times over, which few leases actually permit and which invites a dispute. The floor caps how aggressively the denominator can shrink.

All four inputs presuppose that the expense line items have already been classified into recoverable pools upstream. Pools arrive at this stage already GL-mapped by GL code mapping for CAM expenses, so normalization never has to guess which ledger account a dollar came from; it receives a clean pool with a stable identity and operates on its fixed and variable components.

Algorithm or Rule Design

The core operation is a single multiplication applied to one slice of the pool. Let the variable component of a pool be the occupancy-elastic spend for the period, let the gross-up target be the occupancy the lease normalizes to, and let actual occupancy be the time-weighted fraction the building achieved. The normalized variable amount is:

grossed_variable=variable×occupancy_targetactual_occupancygrossed\_variable = variable \times \frac{occupancy\_target}{actual\_occupancy}

The factor is a ratio of occupancies. When actual occupancy sits below the target, the ratio exceeds one and the variable spend is scaled up; the further below target the building fell, the larger the correction. The full pool that leaves the stage recombines the untouched fixed portion with the normalized variable portion:

grossed_pool=fixed+(variable×occupancy_targetactual_occupancy)grossed\_pool = fixed + \left( variable \times \frac{occupancy\_target}{actual\_occupancy} \right)

The reason only the variable term is scaled is physical, not merely conventional. Occupancy-elastic costs behave the way the factor assumes: a building at 78% occupancy runs fewer cleaning hours, consumes less common-area electricity, and buys less consumable supply than the same building full, so its recorded variable spend genuinely understates what a full building would incur. Multiplying that understated spend by the occupancy ratio reconstructs the full-occupancy figure the tenant’s share is meant to reflect. Fixed costs do not behave this way. Real estate taxes are assessed on the property regardless of how many suites are dark; the insurance premium on the structure does not fall because a floor is vacant. Applying the same factor to a fixed cost would invent recovery that the landlord never had to fund — an over-recovery that an auditor reads immediately as an error. So the fixed term stands outside the parentheses, unscaled, and the correctness of the whole stage rests on the classification that decided which dollars sit inside them.

The occupancy floor enters as a bound on the denominator. Rather than dividing by raw actual occupancy, the engine divides by the greater of actual occupancy and the floor:

effective_occupancy=max⁡(actual_occupancy, occupancy_floor)effective\_occupancy = \max(actual\_occupancy,\ occupancy\_floor)

If the building achieved 78% and the floor is 50%, the floor is irrelevant and the denominator is 78%. If the building collapsed to 22% and the floor is 50%, the denominator is held at 50%, so the factor cannot exceed the target divided by the floor. The floor therefore ceilings the correction without the lease having to state a maximum dollar figure.

A worked example makes the arithmetic concrete. Consider a single reconciliation period at a suburban office property, Cedar Hollow Commons, that averaged 78% time-weighted occupancy against a lease-standard 95% gross-up target. The janitorial pool for the year recorded $184,000.00 of variable spend. The gross-up factor is 0.95 divided by 0.78, or about 1.21795, so the normalized janitorial figure is $184,000.00 multiplied by that factor, which comes to $224,102.56. That $40,102.56 uplift is the amount the sitting tenants collectively carry that they would otherwise have escaped purely because neighboring suites were empty. The property’s real estate tax pool of $96,000.00, classified fixed, is not touched: it enters the grossed pool at exactly $96,000.00. The combined pool leaving the stage is the sum of the two, $320,102.56, and only then does it become the numerator that pro-rata distribution divides across the tenant roster.

Python Implementation

The data contract models an expense as an explicit fixed-plus-variable split rather than a single total with a flag, because the split is the auditable artifact — a reviewer needs to see exactly which dollars were eligible for scaling. Every monetary field is a Decimal; occupancy fractions and the target are Decimal too, so the division that produces the factor never touches a binary float.

from __future__ import annotations

from decimal import Decimal, ROUND_HALF_UP

from pydantic import BaseModel, Field

CENTS = Decimal("0.01")


class OccupancyExpense(BaseModel):
    """One recoverable pool split into occupancy-elastic and fixed components.

    fixed_component is spend that does not move with occupancy (real estate
    taxes, structural insurance) and is never scaled. variable_component is
    occupancy-elastic spend (janitorial, common-area utilities) that the
    gross-up clause normalizes to gross_up_target.
    """

    pool_id: str
    fixed_component: Decimal = Field(..., ge=0)
    variable_component: Decimal = Field(..., ge=0)
    actual_occupancy: Decimal = Field(..., gt=0, le=1)   # time-weighted fraction
    gross_up_target: Decimal = Field(..., gt=0, le=1)    # e.g. Decimal("0.95")
    occupancy_floor: Decimal = Field(Decimal("0"), ge=0, le=1)
    gross_up_cap: Decimal | None = None                  # optional ceiling on grossed variable


class GrossUpResult(BaseModel):
    """The outcome of normalizing one pool, ready to hand to allocation."""

    pool_id: str
    fixed_component: Decimal
    variable_grossed: Decimal
    grossed_pool: Decimal
    factor: Decimal

The gross_up function is deliberately small. It computes the effective denominator against the floor, refuses to scale a building that already met or exceeded the target, applies the optional cap, and recombines the parts. Quantization to cents happens once per money value, at the point each figure becomes a payable amount.

def gross_up(expense: OccupancyExpense) -> GrossUpResult:
    """Normalize the variable component of a pool to the target occupancy.

    The fixed component passes through untouched. The variable component is
    scaled by target / effective_occupancy, where effective_occupancy is bounded
    below by the contractual occupancy floor so a thinly let building cannot
    produce a runaway factor.
    """
    # Never divide by an occupancy below the negotiated floor.
    denominator = max(expense.actual_occupancy, expense.occupancy_floor)

    # Gross-up normalizes UP only. At or above target there is nothing to
    # normalize, so the factor is exactly one — the engine never grosses down.
    if denominator >= expense.gross_up_target:
        factor = Decimal("1")
    else:
        factor = expense.gross_up_target / denominator

    variable_grossed = (expense.variable_component * factor).quantize(
        CENTS, ROUND_HALF_UP
    )

    # An optional gross-up cap ceilings the normalized variable spend so
    # recovery cannot exceed a contractually agreed maximum.
    if expense.gross_up_cap is not None:
        ceiling = expense.gross_up_cap.quantize(CENTS, ROUND_HALF_UP)
        variable_grossed = min(variable_grossed, ceiling)

    fixed = expense.fixed_component.quantize(CENTS, ROUND_HALF_UP)
    grossed_pool = fixed + variable_grossed

    return GrossUpResult(
        pool_id=expense.pool_id,
        fixed_component=fixed,
        variable_grossed=variable_grossed,
        grossed_pool=grossed_pool,
        factor=factor,
    )

Running the Cedar Hollow janitorial pool through gross_up with variable_component=Decimal("184000.00"), actual_occupancy=Decimal("0.78"), and gross_up_target=Decimal("0.95") returns a variable_grossed of Decimal("224102.56") and a factor of roughly 1.2179, matching the hand calculation to the cent. Because the fixed component is quantized and added rather than scaled, a pool that is entirely fixed returns its input unchanged, which is the property the validation fixtures assert against.

Validation Rules & Edge Cases

Normalization has a small number of failure modes, and each one produces a number that looks reasonable, so the engine has to catch them by rule rather than by eyeball. A configuration validator runs before any pool is grossed.

class GrossUpConfigError(ValueError):
    """Raised when a gross-up configuration violates a lease or arithmetic rule."""


def validate_gross_up(expense: OccupancyExpense) -> None:
    """Reject configurations that would produce an indefensible normalization."""
    if expense.gross_up_target > Decimal("1"):
        # A target above 100% occupancy is physically meaningless and would
        # gross up beyond a full building — almost always a data-entry slip.
        raise GrossUpConfigError(
            f"gross_up_target {expense.gross_up_target} exceeds full occupancy"
        )
    if expense.occupancy_floor > expense.gross_up_target:
        # A floor above the target would force the factor below one and gross
        # the variable spend DOWN, which no gross-up clause authorizes.
        raise GrossUpConfigError(
            "occupancy_floor above gross_up_target would reduce recovery"
        )
    if (
        expense.gross_up_cap is not None
        and expense.gross_up_cap < expense.variable_component
    ):
        # A cap below the un-grossed spend claws back real cost, not just the
        # occupancy normalization — a mis-keyed ceiling, not a valid limit.
        raise GrossUpConfigError(
            "gross_up_cap below actual variable spend clips recoverable cost"
        )

The first edge case is a gross-up target above 100%. Occupancy cannot exceed the building, so a target above one is always a slip — usually a percentage typed as 1.05 or a whole number that skipped its decimal. The validator rejects it rather than letting the factor invent recovery.

The second is actual occupancy at or above the target. When a building is fuller than the gross-up target, the raw factor drops below one, and blindly applying it would gross the variable spend down — reducing recovery below what the landlord actually spent. Gross-up is a one-directional adjustment, so the implementation clamps the factor to one whenever the effective occupancy reaches the target. A full building simply passes its variable spend through, exactly like its fixed spend.

The third is the gross-up cap ceiling. Some leases pair the target with an explicit maximum on the grossed figure, either a dollar amount or a multiple of the un-grossed spend, to reassure tenants that a catastrophic vacancy year cannot balloon their share. The cap is applied after scaling and clips the normalized variable component down to the ceiling. Distinguishing this occupancy-driven ceiling from the recovery caps that constrain controllable spend across a fiscal year is the subject of the sibling guide on handling gross-up caps and occupancy floors.

The fourth, and the most dangerous because it hides, is a mis-classified fixed expense that gets grossed up. If a real estate tax line is tagged variable by mistake, the engine will happily multiply $96,000.00 by 1.22 and add $21,000 of recovery the landlord never funded. Nothing in the arithmetic is wrong; the classification is. This is a genuine audit risk because the resulting statement is internally consistent and only a reviewer who checks the fixed/variable split against the lease will catch it. The defense is to keep the split explicit in the data contract, log the classification source per pool, and add a conformance check that flags any pool whose taxes or insurance accounts carry a nonzero variable component.

A subtler interaction arises when a lease also carries a base-year or expense-stop structure. In a base-year lease, the tenant pays only the increase over a reference year’s expenses, and the reference year itself must be grossed up to the same target occupancy — otherwise a base year measured in a full building is compared against grossed-up current years and the tenant is overcharged, or vice versa. The order of operations matters: normalization has to be applied consistently to both the base year and the current year before the stop is computed. That coordination is developed in modeling expense stops and base-year clauses, and the normalization stage exposes its per-pool factor precisely so the base-year machinery can reuse it.

Integration Points

Normalization is a middle stage, and its value depends on clean handoffs on both sides. Upstream, it consumes pools that have already been GL-mapped and classified into fixed and variable components; it never reaches back into the ledger. Downstream, the grossed pool it emits is the number the rest of the engine treats as the recoverable amount for the period.

The immediate consumer is the pro-rata allocation algorithm. Normalization deliberately runs before distribution, because grossing up after splitting would require re-scaling every tenant’s share individually and would make the reconciliation invariant — that shares sum to the pool — far harder to preserve. By normalizing the pool first, the engine hands allocation a single grossed figure and lets the pro-rata factor divide it cleanly across the roster. The grossed_pool field of GrossUpResult maps directly onto the recoverable amount the allocation stage expects.

After allocation, the tenant-level results flow into cap enforcement. The grossed figure a tenant receives is still subject to the recovery limits tracked by managing expense caps and controllable limits, which apply cumulative and annual ceilings across fiscal boundaries. The ordering is intentional and worth stating plainly: gross-up decides how large the pool should be given occupancy, allocation decides each tenant’s slice, and caps decide the maximum that slice may bill. A gross-up cap and a controllable cap are different instruments applied at different stages, and conflating them is a common source of double-limiting a tenant’s charge.

Testing & Verification

The stage earns trust through fixtures that pin each behavior a lease depends on. Three assertions matter most: fixed spend never moves, variable spend scales to the exact target figure, and the floor clamps a runaway factor.

from decimal import Decimal


def test_fixed_component_never_scales() -> None:
    """A tax pool at 78% occupancy must leave the stage unchanged."""
    exp = OccupancyExpense(
        pool_id="cedar-hollow-taxes-2025",
        fixed_component=Decimal("96000.00"),
        variable_component=Decimal("0"),
        actual_occupancy=Decimal("0.78"),
        gross_up_target=Decimal("0.95"),
    )
    result = gross_up(exp)
    assert result.factor == Decimal("1")
    assert result.grossed_pool == Decimal("96000.00")


def test_variable_scales_to_target() -> None:
    """Janitorial spend normalizes to the 95% target, to the cent."""
    exp = OccupancyExpense(
        pool_id="cedar-hollow-janitorial-2025",
        fixed_component=Decimal("0"),
        variable_component=Decimal("184000.00"),
        actual_occupancy=Decimal("0.78"),
        gross_up_target=Decimal("0.95"),
    )
    result = gross_up(exp)
    assert result.variable_grossed == Decimal("224102.56")


def test_floor_clamps_runaway_factor() -> None:
    """At 20% occupancy the 50% floor holds the factor to 0.95 / 0.50."""
    exp = OccupancyExpense(
        pool_id="cedar-hollow-utilities-2025",
        fixed_component=Decimal("0"),
        variable_component=Decimal("50000.00"),
        actual_occupancy=Decimal("0.20"),
        gross_up_target=Decimal("0.95"),
        occupancy_floor=Decimal("0.50"),
    )
    result = gross_up(exp)
    assert result.factor == Decimal("1.9")
    assert result.variable_grossed == Decimal("95000.00")

Beyond per-pool assertions, the stage needs a tie-out at the period level: the sum of every grossed pool’s fixed component must equal the sum of the input fixed components exactly, proving that no fixed dollar was scaled anywhere in the run. A second tie-out reconciles the total uplift — the difference between grossed and un-grossed variable spend across all pools — against an independent recomputation, so a silent factor error in one pool cannot hide inside a portfolio total. Property-based tests round out the suite: for any actual occupancy at or above the target, the grossed pool must equal the input pool; for any occupancy below the target, the grossed pool must be strictly greater; and for any classification with a zero variable component, gross-up must be an identity. The mechanics of building these adjustment cases across a range of occupancies are worked through in calculating gross-up adjustments for variable occupancy.

Frequently Asked Questions

Why gross up expenses at all instead of just recovering what was actually spent? Because recovering only actual variable spend in an under-occupied building shifts the cost of vacancy onto the tenants who leased space. Occupancy-elastic costs fall when suites are empty, but the building’s fixed obligations do not, and the landlord signed leases on the expectation of a normally occupied property. A gross-up clause restores that expectation: it recovers the variable cost the building would have incurred at the agreed occupancy, so a sitting tenant’s share reflects a working building rather than a discount created by neighboring vacancy the tenant did not cause.

Why is gross-up applied only to variable expenses and never to fixed ones like taxes or insurance? Because the adjustment assumes the cost moves with occupancy, and fixed costs do not. Real estate taxes are assessed on the whole property regardless of how many floors are dark, and structural insurance premiums do not drop because a suite is vacant. Multiplying a fixed cost by an occupancy factor would manufacture recovery the landlord never had to fund, which is over-recovery and an immediate audit finding. Only costs that genuinely understate their full-occupancy level when the building is empty — janitorial, common-area utilities, some occupancy-driven management effort — are eligible.

What gross-up target percentage is typical, and where does it come from? Ninety-five percent is the most common figure in institutional office leases and is the market default, but it is a negotiated lease term rather than a rule of thumb. Some leases specify 100%, a few use 90%, and the engine must read the target per pool from the lease abstract. A pool with no gross-up clause carries no target and skips normalization entirely, passing through at actual spend.

Can gross-up ever cause a landlord to over-recover? Yes, in three ways, which is why the stage is bounded. If a fixed cost is misclassified as variable it will be grossed up wrongly; if the target is mis-keyed above 100% the factor inflates; and if occupancy is very low without a floor the factor can multiply a share several times. The controls that prevent each — an explicit fixed/variable split, a target ceiling of 100%, and an occupancy floor with an optional gross-up cap — exist precisely so normalization corrects for vacancy without becoming a source of excess recovery.

Where Normalization Sits in the Engine

Gross-up normalization is the quiet stage that decides how large a recoverable pool ought to be before anyone’s share is computed. It reads a fixed-plus-variable split produced during GL code mapping for CAM expenses, scales only the occupancy-elastic portion to the lease’s target, holds that scaling within an occupancy floor and an optional cap, and hands a single grossed figure to the pro-rata allocation algorithm before managing expense caps and controllable limits applies the final recovery ceilings. Kept disciplined — with an explicit split, a validated target, and a tie-out proving no fixed dollar ever moved — it turns the unfairness of an under-occupied building into a defensible, reproducible number rather than a negotiation.