Skip to content

Vendor Portal

The vendor portal is a token-authenticated public surface that lets a vendor see what they need to see — their payment history, the bills they’ve submitted, their W-9 status — without signing up for an Eclipse account.

You generate a unique link from the vendor’s record in Eclipse. The vendor opens the link, completes the action, and you see the result back in your AP workspace.

When a vendor opens their portal at /portal/vendor/<token>, they can:

  • Submit a W-9 — required for any vendor you’ve paid $600+ in a calendar year (1099-NEC threshold). The vendor can upload their W-9 PDF and enter the requested tax fields; Eclipse derives and stores only the last 4 digits of their TIN, never the full TIN.
  • View AP payment history — last 90 days of payments from your org to them, with payment date, amount, and bill reference.
  • Submit a bill — vendors can upload an invoice PDF that lands in your /approvals queue for review and approval before being booked.

The portal does NOT show:

  • Your other vendors’ data.
  • Your bank account info.
  • Any internal comments or notes on the vendor record.
  • Bills that were paid more than 90 days ago.
  1. Open the vendor’s record at /expenses/vendors/[id].

  2. Click Generate portal link in the actions menu.

  3. Eclipse shows a one-time link. Copy it and send it to the vendor (email, text, whatever channel you use).

  4. The link is valid until you revoke it. Each vendor has one active link at a time — generating a new one revokes the previous one.

The link includes a long random token (hashed in our database — we never store the raw token), so it’s safe to email. Anyone with the link can act as the vendor; treat it like a password.

When the vendor opens the portal and clicks Submit W-9:

  1. They upload their W-9 PDF.
  2. They enter their TIN so Eclipse can validate the form and derive the last 4 digits. The full value is discarded and never persisted.
  3. They click submit. Eclipse:
    • Stores the W-9 PDF in the attachments table linked to the vendor.
    • Records the last-4 TIN, business name, business type, and address.
    • Sets the vendor’s w9_status to received.

You can re-request a W-9 at any time from the vendor record (e.g., for an annual refresh). The vendor’s existing portal link works for the resubmit.

If you’ve paid the vendor $600+ in the calendar year and the vendor type qualifies for 1099-NEC (sole proprietor, partnership, LLC), Eclipse automatically:

  1. Sets needs_w9 = true on the vendor.
  2. Surfaces the vendor in your Tax → 1099 workspace.
  3. Pulls the W-9 details (last-4 TIN, business name, address) into the 1099-NEC form when you generate it at year end.

The threshold check uses canonical bill_payments (posted only — not drafts), so the count stays consistent with what you actually paid.

When the vendor clicks Submit bill:

  1. They upload an invoice PDF.
  2. They enter amount, due date, and a reference number.
  3. Eclipse adds an entry to your /approvals queue with the PDF attached. No bill or ledger entry exists until your team approves the submission.
  4. You review, approve, and post the bill on your end. The vendor never sees the GL — they just see the bill move from “submitted” to “received” to “paid” in their portal.

Open the vendor record, expand the actions menu, click Revoke portal link. The link stops working immediately. Generate a new one if you want to give the vendor access again.

For the technically curious:

  • Each token is a 32-byte URL-safe random string.
  • Eclipse stores only the SHA-256 hash of the token. We can never recover the raw token from our database.
  • The portal endpoints compare submitted tokens with timing-safe-equal to prevent timing attacks.
  • Tokens have an expiration and an is_revoked flag.
  • We track use_count on each token so you can spot if a token is being reused unexpectedly.
  • Public requests are bounded and protected by distributed source and token-fingerprint limits before Eclipse reads organization data, accepts an upload, or performs a mutation.
  • Contact changes and their before/after audit evidence commit together; an audit failure cannot leave an unaudited contact update.
  • Customer Portal — same model, different audience: customers see their statement and outstanding invoices.
  • Payment Runs — what generates the payments the vendor sees in their portal.
  • Approvals queue — where bills submitted via the portal land for your review.