Seller Agreements

Seller agreements are the contracts your consignors sign before you sell their lots: a seller (consignment) agreement, an attestation of authenticity and title where a lot needs one, and a lot schedule addendum when a seller who has already signed sends you more lots. Babylon fills each contract from a template you control, sends it to the seller for electronic signature, optionally asks your team to countersign, and keeps the executed document and a full audit trail.

You can also decide how strictly agreements are enforced: from "never hold a lot" to "no lot goes live without a signed agreement".

This guide covers the Seller Agreements settings under Settings → Business Settings, and the Agreement Templates, Seller Agreements and Legal Documents screens in the Supply section of the sidebar.

Before you start

• Seller agreements are off until you turn them on. The Supply screens in this guide only appear once they are enabled.
• Turning them on and changing the settings needs the permission to manage tenant settings (standard roles: Admin and Finance Manager).
• Writing templates and legal documents needs the permission to manage agreement templates. Issuing, sending reminders and revoking links needs the permission to issue agreements. Countersigning, voiding and overriding the publication gate each have their own permission. The standard Admin role holds all of these. Listing Admin can view agreements, so they can see why a lot is being held, but cannot change them.
• Agreements are issued to consignors from your consignment pipeline, so you will normally also use Supply pipeline.

A sensible order is: turn the feature on, publish your legal documents and templates, set the default templates and terms, then choose how strictly to enforce signatures.

Turn on seller agreements

1. Go to Settings → Business Settings and open the Commerce tab.
2. Expand the Seller Agreements section.
3. Turn on Enable Seller Agreements. The rest of the section appears.
4. Click Save Settings.

Seller agreement requirement

Seller agreement requirement decides whether a lot can be scheduled or go live without a completed agreement:

• Blocking (the default, described on screen as holding a lot only while a sent agreement is unsigned): a lot with no agreement ever sent is not affected. Once an agreement for the lot has been sent, the lot is held until it is signed. Declined and expired agreements also hold the lot.
• Required (every lot must have a signed agreement before it can go live): a lot cannot be scheduled or go live unless a fully executed agreement covers it, even if none was ever sent. Lots in a marketplace tier that needs an attestation also need a signed attestation.
• Off (do not enforce): agreements are still issued and signed, but never hold a lot.

In Blocking and Required modes, a lot is also held if its details have changed since the seller signed in a way that alters what the signed document printed, for example a different marketplace tier, sale format or commission rate. The message lists each changed field with the agreed and current value, so you can either change the listing back or issue a new agreement.

Choose Blocking if you want agreements to be enforced without stopping staff-sourced stock that never needed one. Choose Required if every lot you sell must be under contract.

The requirement is checked when lots are put on sale with the Schedule for sale or Publish now bulk actions on Sell → Listings. Approving a listing, saving a new listing with Create & schedule lot, or changing a listing's status on its edit form does not currently run this check. If you rely on the requirement, schedule lots with the bulk actions. See Listings and collections.

Default templates

Under Default templates, choose which published template Babylon uses for each document it sends:

• Seller Agreement
• Attestation: issued for lots in a marketplace tier that requires an attestation of authenticity and title. Tiers using the Mark + tiers (premium) or Provenance line trust display require one. See Marketplace tiers and authentication schemes.
• Lot Schedule Addendum: issued when a seller who has already signed their seller agreement sends further lots. Without a published addendum template, adding lots for a seller who has already signed is refused.

Leave a field on Use the only active template of this type if you have exactly one active template of that type.

Default commercial terms

These are wording-only terms that your templates print. They pre-fill the issue form and are used in packs:

• Settlement schedule: required by most seller agreement templates, for example 30 days after sale.
• Grace period, for example 14 days from consignment.
• Withdrawal fee (minor units): enter the amount in the smallest currency unit, so 5000 for 50.00.
• Repayment days (attestation): how many days a seller has to repay proceeds if a sale is unwound after payment.
• Deductions summary and Security: free text describing deductions from proceeds and any security taken from the seller.

Commission and buyer's premium rates are not set here. The buyer's premium comes from your fee settings (or the lot's marketplace tier), and the seller commission from the rate negotiated with the seller or the lot's tier. That way the contract and checkout always use the same number. See Fees, commission and sales models.

How sellers receive documents

For a step-by-step walkthrough, see Seller packs.

When seller agreements are on, the seller gets one email and one link for each step of the journey: a proposal after the valuation is approved, then the drafted listing for publication. The documents themselves, their wording and their signatures are unchanged. There is no separate setting. If you switch seller agreements off, packs are not used.

Signing a pack

A pack page lists every document in it. When the seller first opens the pack, each document in it is marked Viewed, with its own viewed time and history entry, as if they had opened it from its own link. Above the signature the page names each document the signature applies to, and the seller ticks a consent for each one before the button ("Sign all 2 documents" when there is more than one) is enabled. One signature then signs every document in the pack, all at once: if any document cannot be signed, none is, and the seller is told why.

Each signed agreement keeps its own evidence record, as it would on its own link. Alongside the usual fields it records the pack, the consent wording the seller gave for that document, and the list of every document signed in the same act. The completion certificate in each executed PDF prints that list under Shared signature, so each document shows on its own what the signature covered.

From the pack page the seller can also:

• Decline, giving a reason from a short list (the guide range is too low, chose another auction house, changed my mind, other with their own words). Every agreement in the pack is declined and the items move to Lost with the reason recorded. The desk gets one email for the pack, naming the seller, the documents they declined (the Seller Agreement or the Lot Schedule Addendum of a proposal), the lots and the reason, with a link to the Supply screen. Declining a pack of three agreements sends one email, not three.
• Ask a question, which is emailed to the desk address used for enquiries and recorded in the item's activity. Replying to that email answers the seller. The pack stays open.
• Verify once when any document in the pack needs a verification code: one code is emailed and it unlocks every document that needs one.

A signed or declined pack can still be viewed from its link, but nothing more can be changed through it.

When a seller has signed a proposal and Babylon created an account for them that they have not used yet, the completion page offers Email me a link to set a password. Pressing it emails them the usual link to claim their account, once. The page then says "We've emailed you a link. Check your inbox." and does not offer it again. The page never shows the link itself. A seller who already has an account, or whose account does not exist yet, is not offered it. In the second case the invitation sent when their lot is drafted still applies. With seller packs on, a lot drafted before the seller has signed a proposal sends no invitation. The completion page offers the link instead.

A proposal pack needs an approved valuation with a selected reserve recommendation (a guide range and a reserve), a marketplace tier on the item, an email address for the seller and a default Seller Agreement template. If any of these is missing, Babylon names the first one. The pack shows the guide range, the surface, the sale format, the seller commission and buyer's premium, an indicative net figure (the middle of the guide range, less your seller commission and any VAT on that commission), and your "why this range" text, then the document the seller owes: a new Seller Agreement, the agreement they have not yet signed with these lots added, or a Lot Schedule Addendum if they have already signed. If every lot is already covered, the seller gets a notice and nothing to sign. Sending a proposal again for the same items replaces the earlier one, and the earlier link stops working. The seller's own agreement email is not sent as well.

Sending the listing to the seller

Once the listing is drafted, Send to seller on the listing's edit page (and in the Listings table's row menu) sends one email with the drafted listing for the seller to confirm and, where the lot's surface requires one, the Attestation of Authenticity and Title to sign on the same page. The Attestation is issued at that moment, so it states the copy the seller is confirming, and its "your account of this lot's history" question is pre-filled from what the seller wrote in their enquiry, for them to edit. A Paddock lot gets the listing only. The button is disabled, with the reason, while the listing is not a draft, the consignor has no email address, or there is nothing to send.

The seller sees three steps: their listing, with "This isn't right" against every fact; their statement; then one consent per document and one signature. Confirming and signing happen together, so if either fails nothing is recorded.

If the seller flags a fact, the whole pack waits: nothing in it can be signed until you resolve the correction as usual and press Send to seller again. Send to seller is disabled while any correction is still open, and names it, so a correction cannot be dropped by sending the pack again. The seller is not emailed about the resolution on its own. Sending again replaces the earlier pack and its link. An unsigned Attestation whose wording no longer matches the listing is voided and reissued, keeping the seller's own account of the lot's history. A signed Attestation is kept, and if the correction changed what it states you are told to review it: voiding a signed warranty stays your decision.

Sending a pack

Packs are sent by your team, from the Supply Intake and the Supply Board, with the issue agreements permission. Nothing is sent when a valuation is approved, because you may want to call the seller first.

• Send proposal is on an item whose valuation is approved. Approve the valuation with Approve valuation in Update valuation, which records the guide range and reserve the proposal needs. The Send proposal form shows Why this range for a last edit and lists the seller's other ready items, ticked, so one proposal covers them. The seller reads the explanation, so do not quote your internal valuation in it. If you leave it empty a warning appears, and you can still send. When it is sent, Babylon confirms the address it went to. If something is missing, the button is disabled and its tooltip names it.
• Send to seller is on an item whose listing draft is ready, and sends the seller one link to check the listing and sign their statement.

While a pack is with the seller, the item shows when they last looked ("Seller last looked 2 hours ago", or "Not opened yet"). After three reminders it reads "Seller gone quiet: call them". See the Supply pipeline for the board columns that follow packs.

How packs behave

• One email per pack. The seller gets a single email for the pack, with a link to its page. A proposal email shows each lot's guide range. The reasons for the range are on the page, not in the email. Documents in an open pack are not also emailed one by one, and the seller is not chased twice for the same ask. The copy of each signed document still arrives as before.
• Reminders. Every three days the seller is reminded about a pack they have not acted on, for as long as the pack is open. Each reminder sends a new link and the previous one stops working. Packs waiting on a correction are not chased, because the next move is yours. After the third reminder the seller counts as gone quiet, so you can call them. The reminders do not stop at three.
• Expiry. The documents in a pack must be signed within 14 days of being issued, and a reminder does not extend that. Once any agreement in a pack passes that deadline unsigned, the pack is marked Expired, and so is the agreement. The seller is not emailed and is no longer reminded. The item's next step becomes Proposal expired: send it again (or Publication pack expired: send it again), and sending it again issues a fresh agreement. A pack with no agreement in it is marked Expired when its link lapses. Agreements sent on their own, outside a pack, are unchanged.
• Nothing is issued on its own. Cataloguing, scheduling or changing the tier of a listing issues nothing. When a lot is not covered, the publication check names what is missing so you can send a proposal.
• Issuing outside a pack. Issue a document outside a pack is in the More menu on a listing's edit page and in the More lead actions menu on a lead. Each shows a warning that issuing this way bypasses the pack, so the seller receives that document on its own and the pack flow does not know about it.

Seller packs over the API

Everything your team does with packs in the console can also be done through the API, with an API key or token that has the agreements:read ability (to look) or agreements:write (to send). The user behind the key needs the same permissions as in the console. Looking needs Supply access (the view or manage supply operations permission), issue agreements or the permission to update listings. Sending a proposal needs issue agreements and Supply access. Sending the listing needs the same, or the permission to update listings. Seller agreements and API access must be on for the tenant. The supply API used under Prepare the item below accepts the manage supply operations permission as well as manage settings and view payouts. A team member with only the view supply operations permission can read that API (leads, items and their photos, valuations, tasks, consignors and the scorecard) but cannot change anything through it.

• See packs. GET /api/seller-packs lists them, newest first. Filter by kind, status, consignor_id, consignment_item_id, listing_id, open=true for packs still with the seller, and quiet=true for packs where the seller has gone quiet. GET /api/seller-packs/{pack} shows one pack with its dates, reminder count, decline reason, frozen proposal or listing summary, and each document in it. No response contains a pack's link or token.
• Check before sending. GET /api/seller-packs/readiness/items/{item} and GET /api/seller-packs/readiness/listings/{listing} say whether a proposal or a publication pack can be sent. If not, missing holds the readiness sentence. For a proposal, needs says which of the valuation, marketplace tier and recipient email the send can fill in itself, and blocker holds the sentence for anything it cannot, or null.
• Send a proposal. POST /api/seller-packs/proposals with consignment_item_ids (one or several items of the same seller) and, optionally, range_rationale. A rationale you send replaces the one on the valuation case, as in the console. Like the console's Send proposal, the same request can fill in what the first item is missing: valuation (estimated_low, estimated_high and reserve_price together, in minor units) starts the valuation case if needed and approves it with those figures, marketplace_tier_id (with track when the catalogue needs one) sets the item's tier, and recipient_email saves the seller's email on the lead. Only what is missing is filled; meta.backfilled lists what was and meta.ignored lists what was already in place. Filling any of them also needs the manage supply operations permission (403 without it). If something is still missing you get a 422 carrying the readiness sentence, and nothing is saved.
• Revise a proposal. POST /api/seller-packs/{pack}/revise with, optionally, lots (per item: consignment_item_id and any of estimated_low, estimated_high, reserve_price in minor units), reason and range_rationale. It works on an open proposal or one the seller declined over the price, needs figures that differ or a reason, and returns the new pack as 201. Raising the reserve or guide range needs a reason and the raise seller reserve permission (403 without it). Once the seller has signed it answers 422 and points to the reserve lowering flow. Packs carry revision, revision_history, raised_guide and review_request (the seller's reason, note and whether it is pending), and GET /api/seller-packs?review_pending=true lists the proposals waiting on a reply.
• Send the listing to the seller. POST /api/seller-packs/publications with a listing_id. POST /api/listings/{listing}/send-for-review sends the same pack. It answers 422 with "Seller packs are not enabled for this tenant." when seller agreements are off.
• Prepare the item. Set the item's marketplace_tier_id (and track for a premium catalogue) on the items API. Approve the valuation with PATCH /api/supply/valuations/{case} and "status": "approved", after selecting the agreed figures with POST /api/supply/valuations/{case}/recommendations and "select": true. The case's seller_range_rationale is the "Why this range" text.
• Check whether packs are on. GET /api/tenant/configuration/agreements-settings returns seller_agreements_enabled and packs_enabled. It is read-only and needs the manage tenant settings permission. Packs are on exactly when seller agreements are on.
• The seller's own page. The pack page talks to token-authorised endpoints under /api/seller-packs/magic/{pack}: read the pack (GET), save answers (PUT .../agreements/{signer}/responses), add an attachment (POST .../agreements/{signer}/attachments), POST to sign, decline, corrections (flag a listing fact), question, review-request (a reason code from a fixed list and an optional note, once per revision, never a price), second-factor and second-factor/verify. After a proposal is signed, claim in the GET response says whether the seller can ask for a password link (available) and when they did (requested_at), and POST .../claim sends that email once and answers 202 with the same claim object (422 when there is no account waiting, never a link). They take no API key, are rate-limited, and are for the seller's browser, not for integrations.

Legal documents

Supply → Legal Documents holds published, versioned documents that your agreements incorporate by reference, such as your conditions of business. Nobody signs these. Your conditions of business (the document with the slug conditions-of-business) can be read or downloaded publicly at any time, for the current version or an exact past version.

1. Click New Legal Document.
2. Enter a Title and a Slug. The slug is used in the public address (/legal/{slug}). Use conditions-of-business for the document your seller agreements should link to.
3. Write the first version's Document body, and optionally set In force from.
4. Save, then open the Versions tab and click Publish on the version.

Published versions cannot be changed. To update the text, use Add version or Clone as new version, edit, then publish it. Publishing makes it the version new agreements link to and the one shown at the public address; agreements already signed keep pointing at the version they were signed against. Preview shows a version rendered with example values.

Agreement templates

Supply → Agreement Templates holds the contract text your consignors sign. Commission, settlement terms and the lot schedule are filled in when an agreement is issued, not in the template.

Create a template

You can start from a platform starter or from scratch.

To use a starter, click Use starter template, choose a Starter template (a seller agreement, an attestation and warranty of title, a lot schedule addendum, a reserve variation, or the Opening Stint attestation of authenticity and title) and optionally a Key for your copy. Babylon creates an editable copy for your marketplace and opens it. Review the wording with your own legal adviser before publishing.

The Opening Stint attestation copy is ready to publish as it stands. It comes with its Part D question, where the seller gives their own account of the lot's history (key provenance_narrative). Its clause G2 prints your Repayment days (attestation). If you have not set that, cloning sets it to 14 days. Change it under Default commercial terms before you publish if 14 is not right for you.

To start from scratch, click New Agreement Template and fill in:

• Name and Key (a unique identifier within your marketplace).
• Type: Seller agreement, Attestation / warranty of title, Lot schedule addendum or Custom.
• Contract body: the text of the agreement. Insert merge fields by typing them in double braces, for example {{consignor.legal_name}}, {{commercial.settlement_schedule}} or {{lot.title}}. The reference list under the editor shows every available field, grouped by section. Use {{agreement.terms_url}} to link to your published conditions of business.

An optional field with no value, such as a grace period you have not set, prints not stated rather than leaving a gap (none stated for fields like the deductions summary or a seller's VAT number). A link to your conditions of business keeps its words but loses the link while you have none published. A required field with no value stops the agreement being issued, and the issue form tells you which one.

• Supplementary questions (optional): extra questions the signer answers when signing. Each has a Key, Type, Label, whether it is required, Help text, allowed options for select types, an optional Prefill from merge field, and an optional Only show this question when... condition based on another question's answer.

If your commission or buyer's premium differs between marketplace tiers, the editor warns you to print the rate per lot in the schedule ({{lot.seller_commission_display}}, {{lot.buyers_premium_display}}) rather than one headline rate for the whole agreement, because a headline rate can only be issued when every lot shares it.

Publish a version

A template is used only through its published version. Open the template, go to the Versions tab and click Publish on the version you want. You will be asked to confirm, because publishing cannot be undone. The list shows each template's Status as Published or Draft with its version number.

To change the wording later, use Add version or Clone as new version on the Versions tab, then publish the new version. Agreements already issued keep the version they were issued from. Preview renders a version with example values, not real consignor or lot data.

Deactivate or delete a template

Switch a template to inactive on its edit page to stop it being used for new agreements. A template that has already been used to issue an agreement cannot be deleted; deactivate it instead.

Issue an agreement

Seller packs are the normal way to send documents. Issue a document by hand only when a pack does not fit. Agreements are issued from a consignment lead, not written on the Seller Agreements screen.

1. Go to Supply → Supply Desk and open the consignor's lead.
2. Open the More lead actions menu and click Issue a document outside a pack. The form warns that this tenant sends seller packs, so the seller gets a separate email and signing link for each document and the pack flow will not know about them.
3. Pick the Template. Only active templates with a published version are offered.
4. Under Lots to include, tick the items from the lead this agreement covers.
5. Leave Also issue an Attestation for each selected item whose surface requires one on if any selected items are in a tier that needs an attestation. Each attestation is sent as its own signing link.
6. Add the Signers (name and email for each).
7. Check the Commercial terms. Negotiated seller commission can be left blank to use catalogue rates; a rate entered here is recorded against the seller. The other terms are pre-filled from your defaults. For an attestation template, Repayment days appears instead.
8. Turn on Requires countersignature if your team must sign after the seller.
9. Set Signing link expires after (days) (14 by default).
10. Confirm to send.

Each signer receives an email with a private signing link. If the template needs information the lead does not yet hold, the form lists it under Missing contract details so you can fix it first.

A seller signs the Seller Agreement once. Their later lots are added to it with a short Lot Schedule Addendum, which Babylon issues for you when you use Issue a document outside a pack on a lead whose seller has already signed. If a lot is blocked with "The consignor's Seller Agreement is signed, but this lot isn't on its schedule yet", send a proposal for it, or issue from that lead and it goes out as an addendum. Leave the commission blank unless the rate has genuinely changed: a different rate issues a whole new agreement.

Signing and countersigning

The seller opens their link, reads the agreement, answers any supplementary questions and signs electronically. The agreement moves through these statuses:

• Issued, then Viewed and In progress as the seller opens and works through it.
• Awaiting countersignature once the seller has signed, if countersignature is required.
• Executed once every required signature is in place.
• Declined if the seller declines, Expired if the signing deadline passes before the seller signs, Voided if you cancel it, and Superseded if a later agreement replaces it.

The seller cannot sign after the deadline. Babylon marks unsigned agreements past their deadline Expired every morning at 08:25. That includes agreements issued from a lead or over the API, not only those in a seller pack. Nobody is emailed when an agreement expires. To try again, issue a new agreement.

To countersign, open the agreement from Supply → Seller Agreements and click Countersign. The button appears only on agreements awaiting countersignature and only for staff with the permission to countersign.

Manage agreements

Supply → Seller Agreements lists every agreement with its template, type, status, consignor, issue date and expiry. Expiry dates that have passed on unfinished agreements are highlighted. Filter by status, or use Overdue to find agreements past their expiry that are still waiting. Because expired agreements are marked each morning, Overdue only lists ones that ran out since then.

Open an agreement to see its lot schedule, any addenda, its signers, supplementary responses (if you have permission to view them) and an audit trail. The actions available are:

• Download executed document, once the agreement is executed and its PDF has been saved. Babylon saves the PDF shortly after the agreement is executed and tries again if saving fails. If the audit trail shows Executed document not stored, every retry failed. The agreement is still executed and every signature still stands. Contact Babylon support to have the document generated again.
• Revoke signer link: stops a signer using their current link. Send a reminder to issue a new one.
• Void: cancels the agreement and revokes every outstanding link. A reason is required, and this cannot be undone.
• Override publication gate: lets the lots on this agreement go live even though it is not signed. A reason is required and recorded. Use it sparingly, for a case you have resolved another way.

From the list you can select agreements and use Send reminder (sends a fresh signing link to everyone who has not yet signed) or Void.

Agreements and templates over the API

Your own systems can read and issue agreements and manage templates through the API, with an API key or token that has the agreements:read ability (to look) or agreements:write (to change or send). The user behind the key needs the same permission as in the console. The ability alone is not enough, and the permission alone is not enough. Seller agreements and API access must be on for your account.

• Look at agreements. GET /api/agreements, GET /api/agreements/{agreement} and GET /api/agreements/{agreement}/document need the view agreements permission.
• Issue an agreement. POST /api/agreements needs the issue agreements permission.
• Work with templates. Listing and reading templates (GET /api/agreement-templates), creating one, cloning a starter, adding a version (POST /api/agreement-templates/{template}/versions) and publishing it (POST /api/agreement-template-versions/{version}/publish) all need the manage agreement templates permission. A user who can only issue agreements cannot list templates, so give an issuing integration that permission as well, or send it the template version ID.
• Who holds what. The standard Admin role holds all three permissions. Listing Admin holds view agreements only.

A call without the permission is refused with 403. The seller's own signing pages under /api/agreements/magic/ take no key and are not affected.

Chasing sellers

Babylon chases sellers for you, once a day, so you do not have to remember who has not replied.

• Agreements. A signer who has not signed gets a fresh link three days after the last email, and every three days after that, until the agreement's signing deadline. After the deadline the seller is not chased, because the link could no longer be signed.
• Listing confirmation. When seller listing confirmation is on, a seller who has been sent their listing copy and has not confirmed it gets a reminder with the subject "a reminder to check your listing". The scheduled command is listing-confirmations:send-reminders. It runs at 08:40 and reminds three days after the listing was sent or last reminded, up to three reminders. After the third, the lot is left for your team to call.

Each reminder carries a new link with a fresh 14 days, and the previous link stops working. Someone who opens the old link is told that a newer email has been sent. A seller who opened their link in the last 24 hours, and still has more than two days left on it, is skipped that day so the link is not replaced while they are reading it. A listing that has a correction waiting for your team is not chased, because the next move is yours.

Over the API. GET /api/listings/{listing}/confirmations lists every round sent for a lot, newest first. Each round shows its status, sent_at, viewed_at, last_seen_at (when the seller last opened the link), confirmed_at, last_reminded_at, reminder_count (at most 3), token_expires_at and superseded_by_id (the newer round that replaced it, if any). The response to POST /api/listings/{listing}/send-for-review carries the same fields for the round it returns. Both need the update listings permission, and neither ever returns a link token.

What blocks a lot from going live

With seller agreements enabled, a lot is held back from scheduling or going live when:

• An agreement covering it has been sent but is not signed, or has been declined or has expired (Blocking and Required modes).
• No executed agreement covers it at all (Required mode only).
• It is in a tier that needs an attestation and no signed attestation covers it (Required mode only).
• Its details have changed since the seller signed, in a way the signed document printed (Blocking and Required modes).

An agreement with its publication gate overridden counts as satisfied. Off mode never holds a lot. The message on the listing names the exact reason. Remember the note above about which actions currently run this check.

Measuring the seller funnel

Hammerd support can report where your sellers stall between an approved valuation and a confirmed listing, and your own tools can pull the same report over the API (see the end of this section). The report only reads your data. It covers one window of dates (the last 90 days unless you ask for another) and follows everything created or issued in that window to wherever it is now.

Ask for it with php artisan supply:seller-funnel-report --tenant=<slug> --from=2026-10-01 --to=2026-10-31. Add --format=json for a machine-readable copy. Without --tenant it covers every tenant with seller agreements switched on.

It reports four things:

• Valuation to first document. How many items had their valuation approved in the window, how many then had a seller document issued, and the median and 90th percentile hours between the two. A document issued before the approval does not count.
• Seller documents. For the seller agreement, the lot schedule addendum and the attestation separately: how many were issued, viewed, signed, declined and expired, how many reminders went out, how many were signed after the first reminder, and the median and 90th percentile hours from issue to view, view to signature and issue to signature. Only the seller's own signature counts, never your countersignature.
• Listing confirmations. How many were sent, viewed and confirmed, how many had a correction requested or were superseded by a newer round, and the same hours measures. A confirmation never expires on its own, so a round still waiting after its link has lapsed is counted as lapsed.
• Seller asks per lot. For lots with a confirmed listing, how many separate things the seller had to act on: the approved valuation, each document covering the lot (voided ones excluded) and the listing confirmation. The report gives the total and the median per lot.

Percentiles are interpolated between the nearest two cases, so a median over an even number of cases is the average of the middle pair.

Over the API. GET /api/supply/reports/seller-funnel?from=2026-10-01&to=2026-10-31 returns the same report for your own tenant as JSON, with snake_case keys such as valuation_to_document and listing_confirmations. Leave out from and to for the last 90 days. A bare to date covers that whole day. A window longer than 366 days, or one that ends before it starts, is refused with a 422. It needs the manage supply operations, manage settings or view payouts permission, and Supply OS and seller agreements switched on; without them the call is refused.

Common questions

Adding lots for a seller who has already signed fails

Publish a Lot schedule addendum template and, if you have more than one, choose it under Default templates.

A signed lot is being held again

Its catalogue details have changed since signing. The message lists the fields that differ. Change them back, or issue a new agreement or addendum for the new details.

I need to change the wording of a published template

Add a new version, edit it and publish it. Published versions are never edited, so signed agreements always match the text the seller saw.