---
title: The rate goes up – and the contract stays
description: 'Supplier contracts now have a change process: request new rates, payment terms or discounts – the supplier accepts or declines.'
author: Robert Reiz
published: '2026-08-28T12:14:12Z'
updated: '2026-08-28T12:40:09Z'
language: en
keywords:
- TimeRecording
canonical: https://zeit.io/en/blog/the-rate-goes-up-%E2%80%93-and-the-contract-stays
---

# The rate goes up – and the contract stays

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.**