What becomes possible once your system knows what kind of contract it's reading

Good contract software does two things successfully: storing agreements and helping you find them again. Ask for anything more active and it tends to stall.

Remind me before this specific kind of agreement auto-renews. Flag any agreement that's missing a jurisdiction clause. Pull out the terms that actually matter for this category and ignore the rest.

None of those are hard features to build. They stall for a more basic reason. Every one of them depends on a question most contract systems can't answer: what kind of contract is this?

Storage is solved. Action isn't.

A flat contract database treats every signed agreement as the same kind of object. You can search it, sort by value, filter by date. What you can't do is anything that depends on the agreement's category, because the category isn't there to act on.

The information exists. It's in the document, and it was in the head of the person who created it. It just never got captured as something the software could use.

That's the ceiling most teams hit. Not a missing feature, but a missing structure underneath the features.

Classification is the structure

Custom Contract Types is how you give the system that structure.

You define the contract categories your business actually uses. NDAs, purchase orders, employment agreements, partner contracts, whatever fits. For each one, you attach the data fields that matter: jurisdiction and confidentiality scope for an NDA, payment terms and delivery date for a purchase order, salary and start date for an employment agreement.

Some of those fields the rep should fill in before the contract goes out, while they still have the answer in front of them. Mark those as required and they're collected in the create flow. The rest are left to AI Contract Management, which extracts them after signature.

The type is set on the template, so none of this becomes extra work for the rep. They pick a template, and the contract carries the right category and the right fields from the start.

What it changes right away

Extraction gets targeted. AI Contract Management now reads an NDA for the terms that belong in an NDA, and a purchase order for the terms that belong in a purchase order. It isn't scanning every document for every possible field and returning whatever it finds.

Confidence goes up as a result. GetAccept has surfaced per-field confidence scores for a while, so teams can see where the AI is certain and where it isn't. Those scores get better when extraction is scoped correctly, because the AI is looking for terms that genuinely appear in that kind of agreement. Less uncertainty in, fewer flagged fields out, less to review.

Reporting starts working by category. Every contract view can be filtered by type. You can look at renewals separately from NDAs, report on the value of active partner agreements, or audit one population of contracts without opening any of them.

Data arrives complete. The fields you marked as required were captured at creation, not reconstructed from a PDF six months later.

The actual point

The gap between a contract archive and a contract system that works on your behalf isn't more AI. It's structure the software can act on.

Extraction was the obvious first problem to solve, and it got solved. The less obvious one is that a system which can't tell an NDA from a purchase order will always be limited to handing you information and waiting. Giving it the categories your business runs on is what changes that.