Vendor Compliance Rules

Vendor compliance rules are the checklist a vendor has to clear before they’re allowed to book a date at your market. Signed agreements, a current certificate of insurance, a health permit, a deposit paid — you define the requirements, and VendorStreet blocks booking until they’re met.

The point is that you stop chasing paperwork by email. Vendors see exactly what’s outstanding and can resolve it themselves.

Configure these under Market → Edit → Vendor Compliance.

What does VendorStreet always require?

Three requirements are built in and always enforced, before any rule you add:

• The vendor’s profile is complete.
• The vendor has added at least one product.
• The vendor has accepted the VendorStreet terms.

You don’t configure these and you can’t switch them off. Everything below is on top of that baseline.

What kinds of rules can I add?

Each rule you create is one of three types:

Document acknowledgement — the vendor has to read and accept a document you’ve published. Market rules, code of conduct, safety policy. Optionally require an e-signature.

Document upload — the vendor has to upload a document to you. Certificate of insurance, health permit, business license, resale certificate. Optionally require expiration tracking so it can’t go stale.

Payment — the vendor has to pay something before they can book. Membership fee, security deposit, annual registration. You set an Amount (USD) and an Invoice description that appears on their invoice.

How do I create a rule?

Add a rule and fill in:

• Rule title — what the vendor sees on their checklist. Be specific: “Upload current certificate of insurance ($1M liability)” beats “Insurance.”
• Applies to vendor type — leave unset to apply to everyone, or target a single vendor type. This is how you require a health permit from prepared-food vendors and nothing extra from crafters.
• Rule type — acknowledgement, upload, or payment.
• Document — for acknowledgement and upload rules, the document from your document library this rule points at.
• Requires e-signature — for acknowledgement rules, demand a signature rather than a click-through.
• Requires expiration tracking — for upload rules, capture and track an expiry date so the document is re-requested when it lapses.
• Amount (USD) and Invoice description — for payment rules.
• Status — active or inactive.

E-signature and expiration tracking don’t apply to payment rules and are hidden when you pick that type.

What order are rules evaluated in?

Rules run in the order you list them, and the vendor’s checklist follows that order. Put the cheap, fast items first — an acknowledgement takes ten seconds, chasing an insurance certificate from a broker takes a week. A vendor who clears three easy items is more likely to finish the hard one than a vendor who hits the wall immediately.

What does the vendor see?

A checklist showing each requirement, its current status, and the action needed. Booking is blocked until everything is complete, and the checklist tells them precisely what’s missing — so “why can’t I book?” support emails largely stop arriving.

Uploads can be set to require approval by your team, so a submitted document isn’t automatically a satisfied requirement. Review pending uploads under the Documents tab.

How do I handle documents that expire?

Turn on Requires expiration tracking on the upload rule, and set the expiration behavior on the document itself in the document library — either a fixed number of days from upload, or an explicit date.

Once a vendor’s document expires, the rule stops being satisfied and booking is blocked again until they upload a current one. That’s the whole reason to use expiration tracking rather than trusting a file uploaded eighteen months ago: an expired certificate of insurance is the same as no certificate of insurance, and this is the mechanism that keeps you honest about it.

Common gotchas

• Create the document first. Acknowledgement and upload rules need a document to point at. Build your library before your rules.
• A rule targeted at a vendor type only applies to that type. If you meant “everyone,” leave the vendor type unset — this is the most common misconfiguration.
• Setting a rule inactive un-blocks it immediately for everyone, including vendors who never satisfied it. Useful in an emergency, easy to forget to turn back on.
• Payment rules generate a charge, which flows into the vendor’s invoices. See Billing.
• Too many rules kills your applications. Every requirement is a place a vendor gives up. Require what you genuinely need on day one and collect the rest after they’re approved.

Next steps

• Document Library — build the documents your rules reference
• Vendor Types — target rules at specific categories
• Markets — the rest of the market configuration