Which Contract Applies?

The Folder

One supplier. Four documents.

Four files in one supplier folder

Vertrag_final.pdf	modified 12 March
Vertrag_final_v2.pdf	modified 14 March
Vertrag_final_echt.pdf	modified 2 May
Nachtrag_neu_scan.pdf	modified 17 September

Anyone who has worked in procurement recognises this folder, and nobody defends it. The usual answer is a naming convention, and it is worth being precise about why that does not fix anything.

These files were not named badly out of carelessness. They were named by four people at four different moments, each of whom knew exactly which document was current at the time. The fourth is a scan — an addendum that arrived on paper and was photographed. It has no connection to the three documents above it beyond sitting in the same folder.

What Is Actually at Risk

The question is rarely which file is newest. It is: what is the notice period, when does the term end and which document says so.

In this folder that answer lives in whichever of the four happens to contain it, possibly amended by a scan nobody has opened since September. If the notice period is in the original and the term was extended in the addendum, the two halves of the answer sit in two different files, and nothing connects them.

A notice period that nobody is watching does not simply pass. In most supply and service agreements it renews the contract for another term. The cost of this folder is not confusion. It is a contract that continues because the deadline was attached to a document instead of to a process.

One Record, Every Version

In a process model the contract relationship is the record, not the folder:

Contract record

Contract party	Muster GmbH
Notice period	3 months
Term until	31 December
Current version	Version 3 plus one addendum

All four documents are still there. They are attached to the record rather than ordered by filename, and which one is in force is a property of the contract rather than of the directory listing. The scanned addendum is no longer a loose object: it is a version of something.

The Alarm Comes Before the Deadline

A deadline that announces itself on the day it expires has announced nothing. In the model the notification is a step of its own, at ninety, sixty and thirty days — and it goes to the role responsible in the model, not to whoever happened to create the file.

It says what it is, what happens if nobody acts and by when: the notice period for the maintenance agreement ends on 30 September; after that the contract renews. Every alarm, and every decision taken on it, is recorded.

The Next Ninety Days

Because the deadline is a property of the record, the portfolio can be read as a whole — two deadlines inside thirty days, two in review, eight on plan:

Contracts expiring in the next ninety days

Contract	Notice by	Status
Maintenance agreement, building 4	30 September in 14 days	Urgent
Lease, Lager Nord	15 October in 29 days	Urgent
Fleet leasing	30 November in 75 days	In review
SLA, data centre	5 December in 80 days	On plan
Framework agreement, procurement	15 December in 90 days	On plan

Example data, extract from a portfolio of twelve contracts.

What This Is Not

This is not a document management system that files more neatly. A document management system stores the four files tidily, probably with version numbers. It still does not know that 30 September is a date on which somebody has to do something, who that somebody is or what follows if they do not.

A deadline is a process state, not a file attribute. That is the whole of the difference. And because the state lives in the model, changing it is a change to the model: a different notice period, an approval step before any termination goes out, a second reviewer above a certain contract value.

How do you keep the overview when the third addendum to a framework agreement arrives?