Your contract data model needs to be extremely flexible.
Different organisations care about different types of information within the same types of contract.
Different contracts within the same organisation contain different types of information. Sometimes this information is specific to the organisation. Sometimes this information is specific to individual contracts (usually complex ones).
A relationship with a single counterparty can extend to many contracts, each with many documents, all grouped and interconnected in an elaborate network.
Different teams and individuals need to see certain kinds of information but definitely shouldn’t see others.
Contracts change over time, so organisations with long-running agreements need to support multiple contractual structures at once.
Any one of these is hard enough to tackle alone. Because they are connected, together they create a problem even tougher than the the sum of its parts.
The only solution is an extremely flexible underlying contract data model. It needs to accommodate every permutation of the scenarios outlined above (and the many more not mentioned).
The downside of flexibility is complexity. Flexibility and features both draw from the same complexity budget. If the budget is blown, expect a bad product.
Better to focus on greater flexibility and fewer features. Those features are useless if the data isn’t in the correct shape.