Documents & e-sign

For: Sellers · buyers · Cypress Managers

A closing produces real paper: a bill of sale, a gate pass, a title packet. Cypress treats documents as data first — generated from templates, filled from the deal's facts, signed in order, checked by AI — so the PDF is the output, never the source of truth.

Your paper or ours

Every document kind ships with a Cypress base template — a clean, compliant Bill of Sale, Gate Pass, and Delivery Receipt that work for any org on day one. Nothing to configure; deals close on the bases alone.

Bringing your own paper is a first-class path, not a hack. Many fleets have their own bill of sale — legal-approved wording, letterhead, logo, background. An org clones the base in the template designer (Settings → Document Templates) and makes it theirs: upload the branded background, place the fields over it, adjust wording, done. Two rules keep the fork safe:

• A clone is a full copy. Cypress updating its base never silently rewrites your version — provenance is recorded, content never follows.
• Published versions are immutable. Generation always uses the published version; edits create the next one, and any document already generated keeps pointing at the exact version that rendered it.

When an organization has more than one published Bill of Sale, one is the organization's default: tick Default Bill of Sale for this organization in the template designer. New closings use the default unless Deal Setup picks another. There is still only one Bill of Sale slot on the checklist, however many templates exist.

CMs manage the platform bases under Admin → Document Templates; the same designer, one level up.

Fields: filled, asked, or yours

A template is text plus fields, and every field has a provenance:

Custom fields are how your back-office identifiers ride along. Define them once on the org — key, label, type, and which side of the deal they belong to — and reference them in templates as custom.<key>. Each field resolves one of two ways:

• Auto-completed — give it a default on the org and it lands on every deal without anyone touching it (a fixed cost center, a branch code).
• Requested during the transaction — name the moment it's asked: during Deal Setup, or at a specific closing step. A per-deal SAP order number gets asked exactly when your process produces it, and the paperwork downstream carries it.

Partner paperwork often needs identifiers of its own, such as an order ID, a sales representative or a manager. Define them as custom fields and the partner's forms carry them.

Field keys are immutable once created — templates and sheets reference them forever, so a rename can't orphan a contract.

Several values on one line. A row or field that shows data from the deal can carry more values on the same line, each joined by a comma, a space, a dot, a slash or a dash: pickup city, then a comma and the state, then a space and the ZIP prints "Denver, CO 80216". In the designer, choose the first value, then + Add a value on this line. A value the deal doesn't have drops out together with its join, so a missing state prints "Denver 80216", never "Denver, 80216". Every value on the line counts as a field of the template: a missing one is asked for when the document is generated, like any other.

Answers given while generating stay yours to change. A gap filled in on the generate form (a pickup street, a contact phone) is saved to the deal and stays editable there: change it, or press the clear button beside it to leave it blank again. A value copied from the record chosen in Deal Setup (a saved pickup location, bank account or lienholder) is shown read-only on the form and is changed by choosing in Deal Setup. The form's fields are deal facts, not your own details, so browsers and password managers do not autofill them.

The gate pass, properly

The gate pass is the release document — the paper that lets a transporter through the seller's gate with the right vehicle. It is written automatically the moment the seller confirms the funds arrived, from its template (base or yours), carrying the VIN, the pickup location from Deal Setup, the buyer's carrier, and the release window — so it is already waiting at step 4 rather than sitting behind a Generate button.

The Cypress gate pass prints the pickup location as an address a driver can use: the place's name, the street, then the city, state and ZIP on one line, followed by the contact, phone and hours. When the seller picks Vehicle's current location in Deal Setup and the car stands at one of the seller's saved locations (matched on the vehicle's location name), that saved location's street, contact, phone, hours and PO come with it.

Nobody at Cypress verifies it, deliberately. Every fact on it came from the vehicle record and from Deal Setup, so a review would be Cypress reading back its own inputs. The seller's signature issues the pass and completes the step. On self-serve channels the seller's own team owns this step — your yard, your pass — and the transporter receives it without needing a Cypress login.

Signing: digital first, paper welcome

Digital runs on DocuSeal, embedded in the closing: one submission per document, each party in the order its template sets (Cypress's Bill of Sale: the seller, then the buyer), and when the deal needs it, an external signer (the transporter on a gate pass, a lender contact on a payoff) who signs from an emailed link with no Cypress account.

Each side sees its own signing links. The seller and Cypress see every signer's link and hand the buyer its own, with the copy and email buttons on the step card; a buyer sees only its own signers' links and addresses, never the seller's. A link is re-sent only to the party whose turn it is to sign. The signing plan comes from the template version that rendered the bytes, so a republished template can never change who signs an in-flight paper.

Paper is a path, not a workaround: templates can carry wet-ink areas, and the closing then requests a scan-and-upload — the signed copy is uploaded against the generated original and linked to it, so the record shows both the paper that went out and the ink that came back. The execution panel offers the upload inline, and a CM can waive a requirement (audited, reversible) when reality demands it.

The Seller Policy

A seller that publishes seller terms can also require them as a signed document. Seller Policy is a document kind with a Cypress base template. A Cypress Manager adds its slot to the org's Pickup step, only when the org has active terms, and only a Cypress Manager can upload into that slot. When Pickup opens it generates from the exact terms version the buyer accepted (a later edit to the terms does not change it) and goes to the buyer for e-signature. A policy that would print blank, cut off or altered is refused. It is always required: Pickup cannot complete until it is signed, unless a CM waives it for that deal.

Sapele — the compliance reviewer

Every bill-of-sale-class document — generated, signed, or uploaded — gets an automatic pass from Sapele, the closing specialist. It reads the actual paper and answers Looks Good, Warning, or Critical Issue, with the specific flags: a mileage that disagrees with the vehicle record, a missing signature date, a buyer name that doesn't match the deal. The verdict advises the CM's review — a human resolves every flag, and both the AI's read and the human's decision are on the record. This is the agentic layer doing paperwork duty: tireless first-pass eyes, human final say.

Per-company document flows

Which papers a deal needs is configuration, not memory — and it can differ per company. The document checklist defines slots per step and channel; beyond the standard set, an org's process can require more: an odometer disclosure your state demands, a company release form, an insurance certificate before pickup. Each added slot behaves like the built-ins — fill by generation or upload, optional executed-before-step-N rules, snapshotted per closing so config changes never destabilize a running deal. Your compliance process becomes the platform's checklist.

Worked example

Acme runs its own bill of sale — legal's wording on Acme letterhead — cloned from the base months ago, plus one custom field: custom.aso ("Acme Sales Order"), asked during Deal Setup. The Transit's BOS generates with the sheet's facts and ASO-2214 in the corner. Sapele flags a Warning — template mileage 18,412 vs 18,466 on the odometer photo. Alex amends the sheet, regenerates, approves. Maria signs digitally for Acme; Dan countersigns for the buyer; the gate pass goes to Birchwood's transporter by email, who signs from a phone in the yard. One paper in this deal went wet-ink — the lender's payoff letter — printed, signed, scanned, uploaded, linked. Every byte of all of it is still downloadable a year later.

Business rules

• Documents belong to the closing — both sides see the same Documents tab, always current; superseded papers stay, marked superseded.
• Generated and signed documents reach integrators as data: the full field set that rendered them rides with the PDF link (webhooks).
• Money in documents is exact-string arithmetic end to end — no floating point ever touches a contract.

Under the hood

Templates version immutably per org with clone provenance; the data sheet holds namespaced facts plus custom.<key> fields (org defaults auto-fill; requiredAt names the step that asks); checklists snapshot per closing; signature parties carry stable identities so a webhook can never complete the wrong signer.