Fixed costs in nouz have start and end dates as first-class fields, not afterthoughts. The reason: rent changes, suppliers come and go, leases end. If we tried to handle every change by editing the existing row in-place, every historical P&L would silently recompute every time you signed a new lease. The lifecycle pattern keeps the past honest.
01 The rule, in one line
When nouz computes a day's fixed-cost allocation, it iterates every fixed cost on your location and asks: was this cost active on this day? The answer comes from two fields — start date and end date — and one short comparison:
start_date <= date AND (end_date IS NULL OR end_date >= date)
No end date means "still active". An end date in the future means "active through that date, then retired". An end date in the past means "retired".
02 Retiring a cost
You're moving to a cheaper space on October 1st. Don't delete the old rent — set its end date to September 30th, then add the new rent with a start date of October 1st. The result:
- August and September P&Ls still subtract the old €2.800 rent.
- October onward subtracts the new amount.
- No retroactive surprises — historical numbers stay honest.
This two-step (end old, start new) is the standard pattern for any fixed-cost change: rent increase, salary bump, switching internet providers, the accountant raising their rate. End the old version on the day before the change; start the new version on the day of the change.
03 Future-dated starts
Adding a fixed cost with a start date in the future is the cleanest way to schedule an upcoming change. The cost shows up in the list immediately but doesn't affect EBIT until its start date arrives. Useful when you know a rent increase is coming in three months — set it up now and forget about it.
Same pattern works for known-end leases: sign a six-month equipment lease today, log it with the start date as today and the end date six months out. The cost slices off your EBIT for exactly those six months, then stops automatically.
04 Why we don't delete
Deletion is technically possible (the database doesn't physically stop you) but actively counterproductive in almost every case. The only legitimate delete is a cost you added by mistake and never actually paid — and even then, ending the cost on the same day you started it is usually cleaner.
Was this article helpful?
Your vote helps us decide what to write next.