Skip to main content

Eligibility Gates and Statuses

This guide explains why deals become Waiting / Pending / Paid, what inputs each gate requires, and where to look to unblock a deal.

When to use this

  • You need to understand why a deal is Waiting, Pending, Earned, or Paid.
  • You’re deciding whether to gate commission on invoice and/or payment.
  • You want to know what inputs are required to move a deal forward.

In the UI, “anchor mode” is shown as Deal relevance mode.

Eligibility gates

Plans can define an eligibility gate:

  • NONE: no invoice/payment dependency; commission can be earned based on the anchor/timing rules.
  • INVOICE: commission is earned when an invoice exists (or the invoice date is known).
  • PAYMENT: commission is earned when payment is received (cash collected).

Important: a plan can anchor on one date (for example closed-won) but still gate on invoice or payment.

Waiting vs pending (how totals behave)

In Core8, “earned” commission can be split into:

  • Pending: expected to be paid (no blocking gate), but not yet marked as paid.
  • Waiting: blocked by missing gate data (for example no invoice date / payment received date yet).

This is how teams typically operationalize “earned but not payable yet” without losing visibility.

How statuses are derived (what you’ll see)

  • WAITING_INVOICE / WAITING_PAYMENT: the deal is calculated, but invoice/payment evidence is missing for the gate.
  • WAITING_GATES: a gate is blocking payout, but Core8 can’t classify it as invoice vs payment waiting.
  • WAITING_DATA: there is a broader data gap required for calculations (not just an invoice/payment gate).

Eligibility gates affect payout timing and status, but they do not block the calculation pipeline itself.

What to check when a deal is “waiting”

  1. Confirm the plan’s eligibility gate (none/invoice/payment).
  2. Confirm the required date exists on the deal:
    • invoice gate → invoice date
    • payment gate → payment received date
  3. If the data should exist, check integration sync and Data Hub.
  4. If the deal is WAITING_DATA, check for missing required fields (amounts, dates, currency, participants) and confirm the deal was successfully parsed/imported.

Common gotchas

  • If a number looks “wrong,” first confirm you’re looking at the right period and right plan (selection/timing vs payout timing).
  • If two places disagree, check whether one view is showing source values and another is showing effective values (after overrides).
  • When debugging, follow the chain: Deal → Plan selection → Eligibility gates → Calculation breakdown.