Skip to main content

​
What is RUBS?

RUBS (Ratio Utility Billing System) is an allocation method used in multifamily residential properties. The landlord or property manager receives a single master utility bill from the utility provider, then divides that cost among tenants using a predefined ratio — no individual meters required. RUBS is not a pricing structure. The utility company has already priced the electricity, water, or gas. RUBS is purely how you distribute that shared cost downstream. Common allocation bases include occupancy (number of residents per unit), square footage, and bedroom count.

​
The allocation formula

Every RUBS variant is the same shape — a tenant’s share of a denominator, applied to the master bill:

​
Choosing an allocation basis

This choice matters more than it looks, because it decides whether the denominator holds still. Bedroom count or square footage are building characteristics. A three-bedroom unit counts the same whether it holds one resident or five, and whether it is occupied or empty. The denominator changes only when the building does — a renovation, a unit split, units taken permanently offline. Actual occupant count moves every time someone moves in or out, so the denominator has to be recalculated and re-entered each period. If nobody updates it, the allocations quietly stop summing to the master bill and no error is raised.
Prefer a fixed basis. Billspree has no way to sum a value across every Subscription in a property at run time, so the denominator is always a number you supply, never one the engine derives. A basis that holds still is a number you set once; a basis that moves is a recurring operational task with a silent failure mode.

​
A worked example

Texas publishes a ratio scale for occupancy-based allocation that makes a good reference: a one-bedroom unit counts 1.6, a two-bedroom 2.8, and a three-bedroom 4. A four-unit property with a $1,120 master water bill for a 30-day month: The shares sum to the master bill because every numerator is a slice of the same denominator.

​
Proration

A tenant who was not present for the whole period should not pay a whole period’s share. Proration is expressed in the formula using the Active Days and Cycle Days variables described in Billing Formula — there is no separate setting to enable:
If unit D’s tenant moved in on day 21 of a 30-day month, they are billed as though present for the full period, then charged for the days they were actually there:
Units A, B and C are unaffected — they still pay 160,160, 280 and 280.Thepropertycollects280. The property collects 853.33 against a 1,120masterbill,andtheownerabsorbsthe1,120 master bill, and the owner absorbs the 266.67 difference. That shortfall is the intended outcome, not an error. Raising the other tenants’ charges to recover it would mean billing them for a unit they do not occupy, which is what these rules exist to prevent. Note also that only genuine vacancy loses money: had a departing tenant occupied days 1–20, they would be billed (20 / 30) × $400 = $266.67, and the two tenants together return the full $400.
Apply proration to the allocated charge only. Do not also prorate a metered component — consumption is billed from the delta between readings, so a partial period already bills less, and scaling it again discounts the same days twice.

​
Building it in Billspree

RUBS uses one Pricing Context and one Pricing Module per property. The context defines the calculation once; each module carries a single building’s numbers. Define these on the Pricing Context, in this Order: Unit Ratio is a Subscription Property, so each tenant carries their own unit’s ratio. Order 4 references Order 3 through Component Chaining, which is what allows proration to be applied to an already-allocated figure. The mandatory Subtotal, Late Payment, Net Total and Tax components follow. A Value declares only a name and an Order on the context; the number itself is entered when building a Pricing Module. That is what lets one context serve an entire portfolio — every property shares the structure, and each property’s module supplies its own Total Ratio Points and its own Master Bill. There is no cap on how many Pricing Modules a context can carry. Group each property’s tenants into their own Billing Group, so a bill run targets one property against one master bill.

​
The monthly cycle

  1. The master utility bill arrives.
  2. Update Master Bill on that property’s Pricing Module.
  3. Create and process the Bill Term against that property’s Billing Group.
  4. Review the drafts, then post.
Because Pricing Modules have no versioning, editing that Value applies to every subscriber on the module at the next rating — which is exactly the behaviour RUBS needs, since every tenant in the building is billed off the same master figure. Bills already posted keep the values they were rated at.
Changing the Order of any Value or Component breaks every rule in every Pricing Module built on that context. With one module per property, that means every building you bill, at once. Settle the component structure before scaling this pattern across a portfolio. See Component Rules and Constraints.

​
Multiple utilities

A single Pricing Context can cover electricity, water and gas together by defining a Master Bill Value and an allocation component for each, reusing the same denominator and the same Subscription Property. Each utility’s master bill is then updated independently on the property’s Pricing Module as those bills arrive.

​
Regulatory considerations

RUBS is regulated, and the rules vary by jurisdiction and by utility. Texas is a useful reference because the Public Utility Commission specifies the mechanics directly in 16 Tex. Admin. Code § 24.281. That section sits under Subchapter I — Water Utility Submetering and Allocation, so it governs water and wastewater only. Electricity and gas allocation fall under separate rules. Everything below applies to water and sewer:
  • Proration is mandated in the form shown above. Subsection (e)(3) requires the owner to “prorate the bill by calculating a bill as if the tenant were there for the whole month and then charging the tenant for only the number of days the tenant lived in the unit divided by the number of days in the month multiplied by the calculated bill.”
  • The bedroom scale is one permitted method, not the only one. Subsection (e)(2)(A)(iii) sets one bedroom = 1.6, two bedrooms = 2.8, three bedrooms = 4. Actual occupant counts, square footage, submetered hot or cold water usage, and combinations of these are also allowed. The example on this page uses the bedroom scale because it holds the denominator still.
  • Square footage may contribute at most 50% of the calculation when combined with occupancy.
  • Base charges are handled separately from the allocation under subsection (b), and follow their own rules rather than the ratio above.
Confirm the rules for the jurisdictions you bill in. This page describes how to model an allocation in Billspree, not which allocation you are permitted to use.

​
Key characteristics