November 2025: fixed-cost lifecycle dates (start, end, mid-cycle changes).
The biggest model change of the year — fixed costs now have start dates, end dates, and a clean way to handle a mid-cycle rent increase without lying to your historical P&L.
v2.0 shipped the single biggest model change since launch — every fixed cost now has a start date and an optional end date, the daily allocation respects both, and mid-cycle changes (like a rent increase six months in) finally model correctly without rewriting history.
Fixed-cost lifecycle dates
Until November, a fixed cost in nouz was a single recurring amount with no temporal bounds. The system assumed it had always existed and always would. If you took on a new insurance policy in March, you couldn't represent the fact that February's daily slice shouldn't include it. Owners ended up retroactively editing their fixed costs to "make the past look right" — which broke the next month's past data when they did it again.
v2.0 fixes this with two new fields on every fixed cost: start_date (required, defaults to today on create) and end_date (optional, null = still active). The daily allocation rule is now exactly this: a fixed cost contributes to a given day if start_date <= day AND (end_date IS NULL OR end_date >= day). Outside that window, it contributes zero.
Practically: if you signed a new equipment lease starting March 1, set start_date = March 1. February's P&L will not include it. If you cancelled a contract on June 30, set end_date = June 30. July onwards will not include it. The historical P&L from before the change is unaffected.
Mid-cycle changes (the rent-went-up case)
The most common scenario this fixes: your rent goes up on April 1 from €2.000 to €2.200. Before November, you had two bad options — edit the amount to €2.200 (and break all your January–March slices) or leave it at €2.000 (and underreport from April onwards).
The right pattern in v2.0: set end_date = March 31 on the original €2.000 cost, then add a new fixed cost with start_date = April 1 at €2.200. Both costs coexist in the database. The daily allocation rule pulls whichever is active for each day. January–March slices still see €2.000; April onwards see €2.200. Historical P&L is unchanged. See updating a fixed cost for the full walkthrough.
This pattern — end-date the old, start-date the new — applies to any change: insurance renewals at a different premium, contract switches, staff hires, equipment lease end-and-replace. The mental model is "a fixed cost is a thing that existed for a window of time", not "a fixed cost is a current setting." It matches how owners actually think about these things.
How we backfilled existing data
On the morning of November 26, every existing fixed cost in every nouz account got a start_date set to the date it was originally created in nouz, and end_date set to null. The intent: existing customers see no change to their historical P&L on day one. If a fixed cost was historically present, it stays historically present.
For shops that had been hand-editing fixed costs to model historical changes (about 30% of the active base, per a quick query we ran the week before), we sent a one-page email explaining the new pattern and offering a 20-minute call to help re-model. Nineteen shops took us up on it. The rest figured it out from the help article.
What we got wrong (on the first try)
Three corrections inside the month.
- The first version allowed overlapping costs with the same name. Meaning you could have two "Rent" costs both active on the same day, which double-counted. The fix: a soft warning at create time if a new cost overlaps an existing cost with a similar name, with one click to end-date the old one. Day 3 patch.
- End-date defaulted to "today" on the deletion flow. First version, deleting a fixed cost set end_date = today instead of removing the cost. Sounded clever — preserves history, stops future contribution. In practice owners who hit delete expected the row to disappear. We split the action: "End this cost" (sets end_date) and "Delete this cost" (removes the row entirely, undoes historical contribution). Day 6.
- The daily allocation query got slower for shops with hundreds of fixed costs. The lifecycle filter added an extra join. We didn't notice in testing because our largest test account had 12 fixed costs; one Pro customer with a complex multi-staff payroll model had 184. The fix was a partial index on (start_date, end_date). Day 11.
What's next (December 2025)
December is our annual code freeze — no new features ship between Dec 15 and Jan 5. The end-of-month December post will be a year-in-review with the four 2025 highlights and the four things on the 2026 roadmap.
Beyond December: the January release rewrites the product card and speeds up the COGS snapshot. February brings multi-currency support (CHF, GBP, DKK, and the rest of Europe's small-business currencies). The fixed costs overview stays the canonical reference for the new lifecycle model.
FAQ
Will my historical P&L numbers change after this release?
No. The backfill on Nov 26 set every existing fixed cost's start_date to its original creation date, so the daily allocation for every past day stays identical to what it was before v2.0.
Is lifecycle dating on Starter?
Yes. All plans get the new fields and the new daily allocation rule. Starter, Growth and Pro behave identically here — the only differences across plans are location count and revenue cap.
What about VAT and tax-rate changes mid-year? Same pattern?
Tax rates work differently — they're per-location settings, not per-cost. See tax rate changes mid-year for the right approach there. The end-date-and-recreate pattern is for fixed costs specifically.
Can I bulk end-date a bunch of fixed costs at once?
Not in v2.0. You end-date them one at a time. Bulk operations are on the list for v2.4 or later.
Where do I read about why this matters for accurate historical P&L?
The customer story at Hartmann & Söhne covers it from a multi-year-business angle, and the full changelog tracks how the model has evolved.