Contracts have different ways of expressing the same information. So in addition to capturing the raw information in your contracts, you need to also standardise it.
This is even more important if you’re doing calculations on top of that data, since you need a watertight model of how different pieces of information interact.
For example, imagine if we captured Execution Date, Effective Date, and Commencement Date as three separate types of data point. On the surface, that would be the right thing to do, since they don’t mean the same thing.
However, your database would suddenly be much noisier and you’d need to figure out which of those three to use in your calculations for when renewals happen or a certain term-related milestone is reached.
Instead, we compress the three into one data point: Active Date. We prioritise in order of Commencement, Effective, and Execution. We’ve thought about it in considerable detail and it works really well.
That was one of the simpler ones. Here’s our standard taxonomy that we include with all plans:
There is an extremely intricate network of relationships and logic between these data points, which we model in our product and can adapt on a per-customer basis. Some will never appear in the contract and can only be calculated (e.g. Active Status, which is dependent on whatever the current date is).
We also have taxonomies for other types of contract information, but you probably get the idea now. Hopefully you can see that every single data point you capture needs careful consideration. If you do it crudely you’ll end up with a mess.