xMatix
Sign in Request demo
xMatix
PRODUCTS
SalesField SalesCRMRewardsClaimsInventoryProcurementWarehouse ManagementField ServiceServiceSupportTelephony & MessagingFinance & AccountingPayrollExpense ManagementCommercePortalsAnalytics & ReportingData StudioMobile AppSee all products →
PLATFORM
Platform overviewApp BuilderAutomationIntegrationsSecurity & GovernanceChange ManagementDevelopers
SENSE AI
Sense AI overviewSense AssistSense ControlSense VisionAI StudioTrust & governanceIn Claude & ChatGPTUse cases
SOLUTIONS
FMCG & DistributionManufacturing & Dealer NetworksAutomotive & DealershipsPharma & HealthcareConsumer DurablesAgri-InputsBuilding MaterialsService NetworksWarehousing & 3PLFinancial AccountingERP SoftwareIndia GST ComplianceUAE VAT & e-InvoicingSaudi ZATCA & VATAll solutions →
RESOURCES
Knowledge CenterDeveloper & CLIBlogGuidesWhat is xMatix?Company facts
COMPANY
AboutCareersPartnersEventsContactAuthorsLegal
Sign in Request demo
Home/Docs/Rewards/Troubleshooting rewards
TROUBLESHOOTING · Last reviewed

Troubleshooting rewards

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:

  1. Plan status — only Approved plans are evaluated. A draft or unapproved plan writes nothing, with no error.
  2. 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.
  3. Target assignment — the member needs an incentive resource target for the line's target. No assignment, no evaluation of that target for that member.
  4. Target value — an assignment with a value of zero can never qualify: achievement is a percentage of the member's own value.
  5. 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.
  6. 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).
  7. 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.
  8. 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 youNo 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.