Obliga · guide
Almost every organization starts here, and starting here is correct. A spreadsheet costs nothing, everyone can already use one, and for a handful of contracts it is genuinely enough. This is how to build a good one, and the four things it will never do no matter how well you build it.
One row per contract. Columns for the counterparty, what the contract is for, the owner, the start date, the expiry date, the notice period in days, and the annual value. Freeze the header row, format it as a Table so the formulas extend when you add rows, and put the signed PDFs in one folder named to match a reference column.
Add a notice deadline column and let Excel work it out rather than typing it by hand:
=[@[Expiry date]] - [@[Notice period (days)]]
Then a days-remaining column, and conditional formatting so anything inside ninety days turns amber and anything inside thirty turns red.
That is a decent contract register. It took twenty minutes and it is better than what a lot of organizations have.
This is the whole problem and everything else is detail. The file is passive. Conditional formatting turns a cell red beautifully, and it turns it red whether or not a human being is looking at it. A renewal you needed to act on in March goes red in March, stays red through April, and is still red in July when somebody finally opens the file to add a new row. The spreadsheet was correct the entire time. Nobody was told.
People work around this with a calendar entry, which is a second copy of the date that now has to be kept in step with the first. When the expiry moves, the spreadsheet gets updated and the calendar does not.
Most registers track the expiry date. By the time it arrives, the window to give notice has usually closed. A lease with a ninety day notice clause expiring March 31 has a real deadline of December 31. The formula above handles it, but only if somebody knew to add that column in the first place, and only if the notice period was read out of the contract correctly for every row.
A spreadsheet cannot tell you it was wrong. A number typed into the notice period column is indistinguishable from a number read carefully out of clause 14.2. Nothing checks it. Nothing flags the row where somebody left it blank.
Type a date on a machine with different regional settings and 03/04/2027 is either
March or April. Paste from a PDF and you often get text that looks like a date, sorts
alphabetically, and silently breaks every formula pointing at it. Sort one column without selecting
the others and the rows scramble, quietly, with no warning and no undo once the file is saved and
closed.
None of these announce themselves. The register still opens. The colours still work. It is simply describing contracts that are not the ones you have.
OneDrive version history will tell you the file changed on a Tuesday. It will not tell you that the renewal date moved from March to June, who moved it, or whether anyone was notified. When an insurer asks why a policy lapsed, or a buyer's lawyer asks during due diligence how renewals were managed, "we had a spreadsheet" is a true answer and not a good one.
Access is the same shape of problem. You can protect a sheet, and anyone who wants the file can have it. There is no way to let a department head see their own contracts and not everyone else's.
Under a dozen contracts owned by one organized person who opens the file every week, a spreadsheet is fine and I would not try to sell you anything else. The point where it stops working is not a number of contracts. It is the moment the file stops being somebody's actual job, because the register only ever worked as a prompt for a person who was already paying attention.
That gap is why I built Obliga. The record still lives in one place, but it is the software that watches the dates, tells the right person in time to act, and keeps a note of who was told and when.
← All Obliga guides