← Back to Product overview

The record

One record, not a shared drive full of copies

Type, status, counterparty, signing entity and business unit, value, and every key date — effective, expiry, auto-renewal, cancellation deadline — live together on one contract record, visible at a glance instead of scattered across folders and email threads.

Intake

Start from the document, not a blank form

Upload a contract while creating one, and Contrayo reads the title, counterparty, effective date, and value out of it — each shown beside the exact sentence it was read from, so you can check the source rather than take our word for it.

Grounded, never guessed

Every extracted value has to appear, verbatim, in the document itself. A value with no source in the text simply isn't offered — there's no confidence score standing in for evidence you can read yourself.

Nothing saved until you say so

Reading the document writes nothing. The extracted values sit above the ordinary contract-creation form, fully editable, until you submit it — abandon the form and nothing was ever recorded.

English-language documents only, and only the first part of a long one.Extraction is reliable for English-language contract content only, and reads roughly the first ten to twelve pages of a document — a missing value on a long contract usually means it fell past that point, not that it wasn't there.

A woman reviewing paperwork at a desk with multiple monitors in an office

Statuses your org defines, not ours

Contrayo doesn't force your contracts through a fixed pipeline of stages. Your org defines its own status names and their order. Behind the scenes, each status carries a few semantic tags — is it terminal, does it count as active for renewal tracking, does it count as an approved parent for inheritance — so the system can reason about what a status means without assuming what it's called. Your vocabulary, not a vendor's.

Value

Value with provenance

A contract's value can be entered manually, extracted but unconfirmed, or confirmed — Contrayo tracks that distinction on every record. Routing today reads whatever value is on the record regardless of which of those three states it's in; gating routing on a confirmed value is real, supported groundwork the schema was built for, not a check the engine enforces yet.

Custom fields

Fields your org defines, not a fixed schema

Beyond the built-in record fields, every org can add its own text, number, date, boolean, or single-select fields — configured once on a dedicated settings page, then available on every new contract's creation form and on every existing contract's own record.

Set up once, used everywhere

Define a field's name and type in Settings, and it shows up on the contract-creation form and on the contract record itself — no per-contract setup required.

Retired fields stay readable

Archive a field you no longer need and its already-recorded values stay visible, read-only, on every contract that has one — nothing about the past disappears.

Structure

Two hierarchies, because a company has two structures

A real company's legal structure and its internal department structure don't line up 1:1. Contrayo models them as two genuinely independent, arbitrary-depth trees, not one combined org chart.

Legal entities

Subsidiaries signing under a parent company, modeled to whatever depth you need.

Business units

Departments and cost centers, defined and nested independently of the entity tree.

Both feed the delegation-of-authority engine's routing directly — a rule written against a parent entity or business unit matches everything under it.See how ancestry-aware routing works →

Parent and child contracts

A contract can reference a governing parent — an SOW under an MSA, for example — and inherit routing treatment from an already-approved parent, rather than being routed as if it stood alone. That's an input the approval engine's routing criteria can read, not something that sets the child's own status automatically — see the DoA engine page for how routing treatment actually works.

Dates

Dates that mean what they say

Effective date, expiry, auto-renewal, cancellation-notification deadline — genuinely calendar dates, stored and shown as calendar dates rather than timestamps. A contract expiring on a given date expires on that date, regardless of what timezone the person reading it happens to be in.

Obligations

What a contract commits you to, tracked after it's signed

"Renew the insurance certificate by March," "deliver the SOW milestone by Q2" — real commitments a contract creates, tracked as their own obligations: assigned to a person, due-dated, and optionally recurring. Tracked independently of the approval workflow that got the contract signed in the first place, not a repurposed approval step.

On the record, and in one place

Add and track obligations right on the contract's own record, or see everything assigned to you across every contract on a dedicated "My obligations" page.

Notified automatically

The same in-app notification system that alerts approvers watches obligation due dates too — a due-soon and an overdue notification, each sent once, no extra setup required. See how notifications work →

Recurring, without re-entering it every time

Complete a recurring obligation — weekly, monthly, quarterly, or annually — and the next occurrence is created automatically, due date advanced correctly even across short months.

Renewals

A worklist of what's coming due

Every contract's auto-renewal or expiry date, triaged into one sorted worklist instead of a column you have to remember to check. Overdue contracts sort first, then everything due within the next 90 days, closest date first.

The date that governs

When a contract carries both an auto-renewal date and an expiry date, the worklist uses the auto-renewal date — the one you'd need to act on to stop an unwanted renewal — not whichever date happens to be earlier.

Filter and sort on demand

Narrow to overdue-only or due-soon-only, and re-sort by days until, on a real table at desktop width and a card list on mobile. This worklist is a page you check, not a push notification — stated plainly, not softened.

An AI-generated brief, but only if you turn it on

For a renewal-due contract, optionally generate a plain-language summary, a likely business owner, and a vendor risk read — each drawn only from that contract's own real fields. Off by default: an admin has to turn on the AI capabilities behind it, and the generated text hasn't yet been checked against a live model response, so treat it as a draft rather than a verified read.

English-language contracts only. This brief is reliable for English-language contract content only — a contract written in Spanish or French isn't summarized or evaluated accurately yet, regardless of which language your Contrayo interface is displayed in.

Comparison

Put two contracts side by side

Compare any two contract records — type, status, counterparty, signing entity, business unit, value, dates, and every custom field your org has added — plus two figures the comparison works out for you: the actual term length in whole months and days, and the real notice period between the cancellation deadline and the term's end. Each row is marked as matching, effectively equivalent (same meaning, different formatting), genuinely different, or present on only one side.

Compares data, not documents

This compares the structured data your contracts already carry — it does not open or read the documents themselves, and it never claims otherwise. The comparison view says plainly, for each side, how many attached documents haven't been opened, rather than going quiet about what it can't see.

No AI of its own

Every value being compared is already exact and typed — a status, a date, a dollar figure — so there's nothing here for a model to interpret. If you've run a clause deviation check (below) on either contract, that side's own result — matches, deviates, or needs review — shows alongside the comparison, read from the existing check rather than run fresh.

Clause library

Your organization's own standard language, kept in one place

An admin can maintain a library of standard clauses per contract type — a title, a category your org defines (Confidentiality, Indemnification, whatever taxonomy you already use), and the clause's own body text. Setting a new standard clause for a given type and category automatically retires the one it replaces, so there's always exactly one current standard to point to.

Checked against your contracts, not just kept on a shelf. Run a clause deviation check on a contract, and each of your active standard clauses is located inside its attached documents — an exact text match settles most of them for free, and anything that doesn't match verbatim goes to an optional AI pass that looks for the corresponding language and reports whether it matches, differs, or couldn't be determined, quoting exactly where it looked. A person still confirms the result; only a confirmed answer can ever feed the delegation-of-authority engine's routing. One real limit, named rather than hidden: this checks your own library against the document, so a clause a counterparty added that isn't already in your library isn't something it can notice.

Connected to

What the record feeds

The DoA engine

Type, value, jurisdiction, entity, and business unit are exactly what routing matches against.

See the approval engine →

E-signature routing

The contract's value is what decides whether signing stays native or requires a third party.

See e-signature routing →

One record, one published price

Contract records ship on every tier. Check the seat price for your organization's size.