How to compute a notice deadline backwards from term end and notice period, why an on-time reminder still misses it, and the exceptions that break the schedule.
Key takeaways
- Two fields generate the entire reminder schedule: term end and notice period. If either is typed by hand per contract, the error surfaces on the contract where it costs the most.
- A reminder that was sent on time and never answered is equivalent to a reminder that was never sent. What closes that gap is a named acknowledgement, not another address on the distribution list.
- Term end must be stored as a calendar date, not a timestamp. A UTC end-of-year timestamp renders as the following day in Israel's timezone, which is enough to make the notice late.
- A contract with a rolling auto-renewal has a completely different cost of failure: not one extra month, but one extra full term, usually a year.
- What breaks is the exceptions, not the reminder. An addendum that changed the end date, a master agreement whose work order ends on a different date, and a notice recipient who has left since signing.
The notice deadline on a contract is not a date somebody types into a calendar. It is a computed value: term end minus notice period, moved earlier if it lands on a non-working day. Every reminder derives from that computed deadline, and every exception in the contract changes it.
Two fields that generate the whole schedule
The notice deadline is computed as term_end minus notice_days, and everything else derives from it. Worked through on service contract SVC-2024-118:
term_endis 2026-12-31.notice_daysis 60, on a calendar-day basis.- Computed notice deadline: 2026-11-01.
- The reminder ladder, counted backwards from the computed deadline: 60 days before at 2026-09-02, 30 days before at 2026-10-02, 14 days before at 2026-10-18, and 3 days before at 2026-10-29.
Note that reminders count backwards from the notice deadline, not from the end date. Counting from the end date is a common mistake that fires the first alert a month after the window has already shut. Note also the notice_basis field: 60 calendar days and 60 business days are two dates nearly three weeks apart, and a contract that does not say which forces you to choose. When the system computes rather than accepting a typed date, correcting one field is enough when an addendum turns up.
Why does a reminder sent on time still miss the deadline?
Because sending is not deciding. The obstacle is almost never technical: the alert went out, landed in a shared mailbox, and nobody took ownership of it. The structure that closes the gap has three parts.
- A named recipient rather than a shared mailbox. An
owner_user_idon the contract, not a contracts@ address. - An acknowledgement recorded as an event: who acknowledged, when, and what the provisional decision is.
- Escalation when no acknowledgement arrives inside a pre-agreed window, say 72 hours, to a manager named in a field rather than to "everyone".
The decision itself lives in a decision field holding one of renew, renegotiate, terminate or undecided, alongside decision_by and decision_at. The undecided value is the most important of the four, because it is the only one that makes it possible to ask one morning: which contracts still have no decision and a deadline inside thirty days? That list is the entire value of the system. The stage after the decision, producing and signing the renewal document, is covered in automating contracts and e-signatures.
The contract fields that let you compute instead of guess
| Field | Example value | What it determines |
|---|---|---|
contract_id | SVC-2024-118 | stable identifier, survives renewal |
term_end | 2026-12-31 | a calendar date, not a timestamp |
notice_days | 60 | notice period taken from the contract text |
notice_basis | calendar | calendar days or business days |
auto_renew | true | whether silence renews or ends the engagement |
renewal_term_months | 12 | length of the next term if it renews |
price_basis | cpi_linked | fixed, index-linked or negotiated |
notice_recipient | name and role from the contract | who the notice is actually served on |
owner_user_id | u_2261 | who on your side owns the decision |
parent_contract_id | MSA-2023-004 | links a work order to its master document |
auto_renew is the single field that turns a miss from a small error into an expensive one. When it is false, silence ends the engagement and you discover in January that the service stopped. When it is true, the same silence commits you to another full term. One forgotten reminder produces two opposite outcomes, which is why this value has to appear inside the alert body and not only on the contract card.
The exceptions that break every simple reminder schedule
| Exception | How it looks in the system | What prevents it |
|---|---|---|
| An addendum changed the end date | the original contract still carries the old date | every addendum updates term_end on the parent record |
| Master agreement plus work order | two different end dates for the same vendor | parent_contract_id and a separate computation for each |
| The notice recipient has left | notice served on somebody who is not there | review notice_recipient at the first reminder |
| Index linkage | the renewal amount differs from the current one | recompute before the reminder, not after |
| Rolling renewal | a miss costs a whole term | surface auto_renew in the alert body |
| Channel specified in the contract | an email sent where the contract named registered post | check notice_channel before sending, not after |
The first exception is the most common and also the quietest. An addendum is signed, filed in a folder, and nobody touches the record. The system keeps computing from a date that is no longer true and sends a perfectly punctual reminder for the wrong deadline. The only rule that holds: signing an addendum is an event that requires a field update, not just a file upload. Where the price is index-linked, recomputation happens before the send so the decision is made on the real number; that mechanism is described in linking contracts to the consumer price index.
How do you store an end date so it does not move?
Store it as a calendar date only, in a full-date form with no time and no offset. RFC 3339 defines the full-date production, written 2026-12-31, separately from a complete timestamp. The difference is not theoretical: 2026-12-31T22:00:00Z is 1 January 2027 at 00:00 in Israel's timezone, and any computation built on it shifts the notice deadline by a day.
- Store
term_endas a date rather than a timestamp, even where the database supports a time component. - If alerts are generated on a server in another timezone, set the business timezone explicitly from the IANA database, for example
Asia/Jerusalem. - Do not assume a fixed offset. Israel moves between winter and summer time, and the offset from UTC changes inside the reminder window of a contract ending at year end.
- Run the reminder generator at a fixed local hour, and stamp every alert with the date it was computed from.
- Where the contract also drives recurring payments rather than only a renewal, the billing calendar is documented separately in automating invoices and payment reminders.
Sources
Frequently asked questions
How many reminders should go out before the notice deadline?
Four points cover most cases: 60, 30, 14 and 3 days before the computed deadline. The first opens a negotiation, the second gathers usage data, the third forces a decision, and the fourth warns that the window is closing. A fifth reminder without an acknowledgement mechanism adds noise rather than a decision.
What if the notice period in the contract is written in months?
Convert to a date, not to days. Three months back from a 2026-12-31 end date is 2026-09-30, whereas ninety calendar days is 2026-10-02. The gap is small but real, so `notice_basis` needs a months value too, and the computation has to walk the calendar rather than multiply by thirty.
Should expired contracts that were already renewed still be tracked?
Yes, but as one record with a term history. A renewal creates a new term under the same `contract_id` rather than a new contract, so you can see how the price moved across years and notice that the current term is already the fourth. Creating a fresh contract at every renewal destroys exactly that information.
Who should receive the alert, the manager or the finance lead?
The decision owner, named in a dedicated field on each contract. Escalation to a manager is a second stage rather than a parallel recipient, because two primary recipients produce a mutual assumption that the other one handled it. Finance receives the alert only once a decision exists, in order to update forecast and payments.
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.