Maria leads customer support at a small software company. One morning a customer files a complaint. He says the cancellation rule the company is now applying was never in the terms he agreed to when he signed up. Maria goes to check. The company has updated its terms three times this year. So which version did this customer accept, and on what date? The sign-up record shows the day he joined, but the terms text from that day was replaced months ago. Right now, the company cannot prove what he actually saw.
The question behind every terms dispute
When a customer challenges your terms, you have to show the exact version they agreed to.
Most web and software businesses ask users to accept terms and conditions at sign-up. That text changes over time. You add a clause, fix a mistake, or change a notice period. Each change makes a new version. If a customer later disputes a term, the real question is simple. Which version was live on the day they clicked accept, and what did it say? If you only keep today's terms, you cannot answer that. A refund rule, a notice period, or a limit of liability can all shift between versions. The clause you are relying on today may not be the clause they accepted.
What Swiss law actually asks
A contract forms when both sides agree, and the side that relies on a term must prove it.
Under Article 1 of the Code of Obligations (OR), a contract needs the parties' mutual and matching expression of intent. That intent can be express or implied, so a click on an accept button can count. Under Article 11 OR, a contract needs a special form only where the law prescribes one. For ordinary terms and conditions, no signature is required, so an online acceptance can bind. But there is a catch. Under Article 8 of the Civil Code (ZGB), whoever derives a right from alleged facts must prove those facts. In plain words, if you want to rely on a term, you carry the duty to show it was part of the deal.
Why "we updated our terms" is not enough
Your current terms page does not show what a past user saw when they clicked accept.
A live terms page shows one thing: the text as it is today. When you publish a new version, the old text is usually gone. A screenshot in someone's inbox is easy to question. A line in a change log is just a note you wrote yourself. None of these fix the moment in time. In a dispute, the other side can say the text was different, or was added later. Without a dated record, it is your word against theirs.
Dating each version of your terms
Sealing each version creates a dated record of the exact text that existed at that time.
When you seal a document, the platform sends a cryptographic hash of it, a short fingerprint, to a trusted timestamp authority under RFC 3161. You get back a timestamp that ties that exact text to that moment. Change one character and the fingerprint changes. So a sealed version of your terms is locked to its date. If you seal each version as you publish it, you build a simple timeline. Version one from January. Version two from April. Version three from September. Each one is dated, and each one can be checked by anyone through a public link, with no account needed.
What a seal shows, and what it does not
A seal shows which text existed at a given time, not who wrote it or who clicked accept.
Be clear about the limits. A seal shows that a specific version of your terms existed on a specific date, and that it has not changed since. It does not show who wrote the text. It does not, on its own, prove that one named user clicked accept. For that, you still need your own sign-up logs, which record the user and the version they were shown. The seal does the part those logs cannot do well. It proves the terms text from that date is genuine and unaltered. The two work together. Your logs link the user to a version. The seal fixes what that version said.
A simple routine for every update
Seal each version before you publish it, and store the dated record next to your sign-up logs.
A short routine keeps you covered:
- Before you publish a new version, seal the final text.
- Save the public verification link with that version in your records.
- Make sure your sign-up flow records which version each user accepted, and when.
- Keep old sealed versions. Do not delete them when a new one goes live.
This takes a few minutes per release. It turns a future dispute from guesswork into a dated record you can show.
Back to Maria
Maria's company now seals every version of its terms on the day it goes live. The next time a customer asks which rules applied when they signed up, support can point to the sealed version from that date and a public link anyone can check. The dispute that once would have been a guess is now a short answer backed by a record. The work happens at publish time, not during the argument. Seal each version before you publish it, so the text and its date are fixed while they are still easy to prove. You can start at swisstrustlayer.com.
