Cycle Cost Overrides
Last updated: August 28, 2026
Your charge codes set base pricing at the system level — the rate every cycle uses by default. A cost override lets you change that pricing for one specific cycle without editing the underlying charge code. The base code stays exactly as it is; only the cycle you are editing sees the new behavior.
Reach for an override whenever a single term needs different pricing than the rest of the year: a summer rate, winter-break pricing, a promotional rate for a special population, or turning billing off for a term where a bed type or meal plan should not charge at all.
Overrides exist in two flavors — bed type and meal plan — and they work identically. Learn one and you know both.
What an override controls
Every override (bed type or meal plan) gives you the same three levers:
| Lever | Field | What it does |
|---|---|---|
| Swap the charge code | cost / costId | Bill this bed type or meal plan under a different charge code for this cycle — useful when summer revenue books to a different accounting code than the academic year. |
| Override the amount | overrideAmount | Charge a different amount than the code's default. |
| Disable billing | isDisabled | Turn billing off entirely for that bed type or meal plan in this cycle — no charge is generated. |
You can combine them: swap to a different code and set a custom amount on it. If you swap the code but leave the amount blank, the override falls back to that code's own default amount. When overrideAmount is null, the system uses the override cost's base amount.
Bed type overrides
Bed type overrides are scoped to an InventoryBedType. Use them for per-cycle room pricing — for example, a double that bills the standard rate during the academic year but a reduced rate in summer, or a bed type that should not bill at all during a break term (set isDisabled).
Meal plan overrides
Meal plan overrides are scoped to a MealPlan. Same three levers, same behavior — swap the code, change the amount, or disable billing for a meal plan within a specific cycle.
How pricing resolves
When the system computes a student's bed charge, it resolves pricing in a strict priority order:
- Cycle cost override — highest priority. If a bed type has an override, it completely replaces the default cost. A disabled override means no bed charge is added at all.
- Automated cycle costs — charges brought in by CycleCost and applied to students by tag.
- Default bed type cost — lowest priority. Used only when no override exists.
The practical takeaway: an override wins over everything. If you have set one and the price still looks wrong, the override is what is driving it — not the base code.
How overrides relate to cycle cost assignment
A related model, CycleCost, assigns a charge code into a cycle and controls which students it applies to via applicability tags (applicabilityTagsAnd, Or, and exclusionTags). Read the whole system as three layers:
- Base — the charge code's system-level amount
- Assign — CycleCost brings a code into a cycle and targets students by tag
-
Override — bed-type or meal-plan overrides change the amount, swap the code, or disable billing for that cycle
Scope and permanence
Overrides are cycle-scoped and non-destructive. Editing or removing an override never touches your base charge code, and other cycles keep the base pricing. To revert a cycle to standard rates, remove the override — the base code takes over again automatically.
Verify your override took effect
After saving, the bed charge will show the explanation From bed type override in cycle settings. The system tags overridden charges so you can see at a glance that pricing came from the override, not the base code.