The rate goes up – and the contract stays
Robert Reiz | August 28, 2026 | 12:14 UTC Nadja Weber has been freelancing for you for a year and a half. The framework contract is running, the collaboration works, and at the turn of the year you talk about rates. The outcome of that call: the hourly rate goes from €95.00 to €102.00, and since your accounting has moved to a longer payment run anyway, the payment term is extended from 30 to 45 days.
Two numbers. An eight-minute phone call. And then the actual work begins: the existing contract has been accepted and is therefore frozen in its essential fields. So you create a new contract, retype every condition, terminate the old one, send the new one out for signature, and hope nobody forgets the project assignments. All for a difference of seven euros an hour.
That is over. Supplier contracts now have a change process – the same way employment contracts have had one for a while.
What's new
You request the change, your supplier reviews it and decides. No second contract, no duplicate data entry, no break in the history.
Concretely: every supplier contract now has a Changes tab. There you create a change request, enter the new values and save. Your supplier receives an email, sees the old and the new values side by side, and clicks either Accept changes or Decline changes.
If they accept, the new values are in the contract immediately. If they decline, everything stays as it was – and you get an email about it.
What can be changed
| Field | Example |
|---|---|
| Payment term in days | 30 → 45 |
| Early payment discount 1–3: term in days | 10 → 14 |
| Early payment discount 1–3: discount in % | 2.00 % → 1.50 % |
| Hourly or daily rates | €95.00 → €102.00 |
On contracts with several rates, every category appears as its own row – under your label. If the contract says „Frankfurt Data Center" instead of „On site 2", that is what the change request says too. And only the categories actually configured on that contract show up. A contract with two rates in use shows two rows, not ten.
What is deliberately absent: your billing rates. A change request covers the purchase side only – what you pay your supplier. What you charge your client for the same hour stays where it belongs: with you. Your margin is not a negotiating position.
The compensation model itself cannot be changed either. A change request will not turn an hourly-rate contract into a daily-rate contract – for that, a new contract is the right instrument.
The Nadja Weber case, step by step
1. You create the request. Open the contract, go to the Changes tab, click Request change. You get a table with three columns: field, current value, new value. The right-hand column is pre-filled with the current values – you only touch what actually changes:
| Current value | New value | |
|---|---|---|
| Payment term in days | 30 | 45 |
| Discount 1 – term in days | 10 | 10 |
| Discount 1 – discount in % | 2.00 % | 2.00 % |
| Hourly rate | €95.00 | €102.00 |
Save. And if you accidentally changed nothing at all, ZEIT.IO says so – an empty request is never created.
2. Nadja gets an email. Subject: Change request for contract Framework Agreement Development 2025, with a link to the review page. In case the email gets lost in her inbox: while the request is open, her contract page carries a notice banner with a Review changes button.
3. Nadja reviews. She sees exactly the two rows that change – payment term and hourly rate. Rows without a change are not shown at all. Two buttons below: accept or decline.
4. Nadja accepts. From that moment the new values are in the contract. The next credit memo calculates with €102.00, the next payment term is 45 days. You receive an email: Change request for contract Framework Agreement Development 2025 was accepted.
5. The history is on record. The contract's audit log then holds:
created change_request 6512ab…
accepted change_request 6512ab…
change_request 6512ab… - payment_term from `30` to `45`
change_request 6512ab… - hourly_wage from `95.0` to `102.0`
One entry per field that actually changed, with the old and the new value, a timestamp, and the person who acted. Anyone who needs to know two years from now since when €102.00 applies, and who agreed to it, finds the answer in one place.
How this differs from employment contracts
Both contract types now have a change process, and both live in the same tab. Two things set them apart – for good reason.
On an employment contract you schedule a change. You give it an effective date, and ZEIT.IO applies the change on that date automatically. A salary increase effective 1 April is entered in February. Target working hours, vacation days and hour reports are then recalculated from that date onwards.
On a supplier contract you request a change. There is no effective date, because there is something else instead: consent. A supplier is a contractual partner on equal footing, not someone who takes instructions. A unilaterally scheduled rate change would be the wrong mechanism in that relationship. So the change takes effect exactly when it is agreed to – and not a day earlier.
| Employment contract | Supplier contract | |
|---|---|---|
| Who decides | the organisation | the supplier |
| Effective from | the scheduled date | the moment of consent |
| Typical fields | salary, vacation, working hours | rates, payment term, discounts |
| Can be declined | no | yes |
The rules behind it
A few decisions that rarely surface in daily use, and matter precisely for that reason:
- Only one open request per contract. As long as your supplier has not decided, no second request can be created. Otherwise two versions of the truth would be up for approval at once – and nobody would know which one counts.
- Edit and delete only while open. Made a typo? Edit the request and your supplier gets a fresh notification. Once answered, the request is immutable.
- An answer is final. A second click on Accept – by mistake or through a double page load – changes nothing. And a declined request cannot be turned into consent after the fact.
- Own contracts only. Opening someone else's request page ends in a 404, not in a look at someone else's rates.
- Permissions stay as they are. Whoever has write access to supplier contracts can raise requests. Whoever does not sees the history and nothing more.
Why this is more than convenience
The effort you save is the obvious part: no second contract, no retyping, no migrating project assignments.
The more valuable part is traceability. Until now a rate adjustment lived in an email thread and ended up in a contract document that says nothing about what applied before. Now the whole process sits in the system: who proposed what, when, with which values – and who agreed to it, and when.
For invoice review that means: when one credit memo calculates with €102.00 and last quarter's still used €95.00, the reason is two clicks away instead of buried in a mailbox.
At a glance
| Before | Now |
|---|---|
| An accepted contract is frozen | Conditions adjustable through a change request |
| A new contract for seven euros' difference | Change two values, submit, done |
| Consent in an email thread | Consent documented on the contract |
| Rate history: compare contract documents | Rate history: one entry per changed field |
| Change process for employees only | Change process for every contract type |
The Changes tab is available on every supplier contract as of today. For running contracts nothing changes for now – until the next conversation about rates.
Because an agreed change belongs in the contract. Not in your inbox.