Incentive evaluation is deterministic: the engine reads the plan, the member's target values and the period's Performance KPI records, and writes what follows. When a result looks wrong, one of those inputs is wrong — this page maps the symptoms to the input to check.
A compensation line shows no reward
Work down this list — evaluation stops silently at the first missing piece:
- Plan status — only Approved plans are evaluated. A draft or unapproved plan writes nothing, with no error.
- Line references — the compensation line must carry the incentive plan, the incentive period and the member (incentive resource). A line missing any of the three is skipped.
- Target assignment — the member needs an incentive resource target for the line's target. No assignment, no evaluation of that target for that member.
- Target value — an assignment with a value of zero can never qualify: achievement is a percentage of the member's own value.
- KPI data — Performance KPI records must exist for that plan and period, tied to the target, and must match the member: a resource plan matches on the record's resource, a partner plan on its partner account, a branch plan on its branch, a customer plan on its account. Records attributed to the wrong party sum to zero.
- Target filters — an item, item group or account filter on the target excludes KPI records that don't carry the matching reference (item group matching is SKU-aware).
- Slab coverage — the achievement percentage must fall inside some slab's from–to band. Gaps between bands, or a top band that ends too low, qualify nothing.
- Line criteria — with All Conditions Are Met, one failing target fails the line; with custom logic, check the
{N}positions refer to the sequence numbers you think they do.
A line whose filter criteria is Always (No Criteria) qualifies without evaluating targets — but since rewards attach to slabs qualified through targets, such a line writes no slab reward. If a line is meant to pay, give it targets.
The amount is not what was expected
- The percentage is floored. Reached ÷ target × 100 is rounded down before slab matching — 80.9% is 80, and lands in a band ending at 80, not the one starting at 81.
- First matching slab wins. Slabs are checked in sequence order and matching stops at the first hit. Overlapping bands pay the earlier slab, not the richer one.
- Open-ended bands. A to percentage left empty (or zero) extends the band upward without limit — an over-generous top band catches everything above it.
- Per-unit types multiply. Amount Per Unit pays the per-unit amount × the achieved value of the target the slab qualified through; the Incremental variant pays double that. A value-based target makes "per unit" mean per unit of value.
- Percentage On Value keeps the higher figure. It replaces the line's incentive amount only when the computed amount is higher — a smaller recomputation does not lower an amount another slab already wrote.
- Re-evaluation replaces. Every save recomputes from current data. If KPI records or targets changed since the last save, the new result is not a bug — it is the current truth. Use the override incentive amount to preserve a reviewed figure.
The achieved figures on the line look wrong
The engine stamps what it counted onto the line — use those figures to localise the problem:
- A figure is zero but performance exists — member mismatch (the KPI records name a different resource/partner/branch/account than the member's enrolment) or a target filter excluding them.
- A figure is too high — the KPI records for the period include rows you did not expect; the achieved figure is the sum of everything that matched. Check for duplicate or misdated KPI rows in that period.
- Unique counts surprise you — No Of Unique Invoices counts distinct accounts across the matching KPI records, and No Of Unique Items distinct items; they are distinct-counts, not row-counts.
- Custom KPI reads zero — the target's custom KPI field name must exactly name a field carried by Performance KPI records; a misspelt name reads as zero.
Common questions
Nothing at all is being evaluated for a period — why?
Because nothing asked to be: evaluation runs when compensation lines are saved, and a period with no compensation lines has simply never been evaluated. Create the compensation record and its lines for the period — see Running an incentive cycle.
How do I force a recalculation?
Save the compensation line again. Every save re-evaluates from the current plan, targets and KPI data and replaces the previous result. There is no cache to clear and no job to wait for.
Who should fix a plan-level problem — the user or the admin?
Target values and compensation lines are user-fixable. Plan structure — member type, period type, scoping — locks once the plan has members or targets, so structural mistakes need an administrator and usually a new plan; the configuration reference lists the exact validations and locks.
