Introduction to SAP SuccessFactors Incentive Management

Five Core Layers of SAP SuccessFactors IM

Every implementation, regardless of complexity, is built around five architectural layers. Understanding these is your foundation for the entire platform.

Layer 1: Plan Administration

Where incentive plan logic lives. Plan Administration is where you define how people get paid:

• Plan Types — Commission plans (per-unit commission on sales), Bonus plans (fixed bonus at target, scaled by attainment), Management by Objectives (MBO) plans (based on achievement of goals), and Special Payment Funds (SPF) plans (discretionary bonuses).
• Plan Components — The building blocks: quotas (annual targets), rates (commission per unit or tier), multipliers (accelerators for over-quota), caps (max payouts), and clawbacks (deductions).
• Calculation Rules — The engine's instructions: if attainment is 50–75%, pay at 75% of base; if 75–100%, pay 100%; if 100%+, pay with a 1.5x multiplier.
• Plan Periods — The time windows over which plans operate: monthly, quarterly, annual. Each period has explicit start/end dates and can have different quota or rate configurations.
• Plan Hierarchy — How plans relate to each other. A salesperson might be assigned to a base commission plan + a quarterly SPF plan + a year-end bonus plan. Inheritance rules determine which values a plan component inherits from parent plans.

In SAP SuccessFactors IM, most plan administration is done through the web UI, not SQL. You access a visual plan designer, drag-and-drop components, set effective dates, and test the plan's calculation logic before assigning it to participants. The underlying tables (CSC_COMP_PLAN, CSC_PLAN_COMPONENT, CSC_PLAN_RULE) store the result, but you rarely manipulate them directly.

Layer 2: Participant Management

The people layer. Your organization's hierarchy of salespeople, managers, and support roles — and the assignment of them to plans and quotas.

• Participant Records — Represented by the CSC_PARTICIPANT table, synced from HR systems. Each person has a participant ID, name, employment status (active/inactive), position type, and organizational hierarchy (who their manager is).
• Organizational Hierarchy — Built through the MANAGER_ID field. A rep's MANAGER_ID points to their manager's participant ID, forming a tree. This hierarchy is used for reporting, approval routing, and sometimes commission sharing.
• Plan Assignment — The CSC_PLAN_PARTICIPANT table links participants to plans with effective dates. A participant can be assigned to multiple plans simultaneously, each with different start/end dates.
• Quota Assignment — The CSC_QUOTA table stores per-participant, per-period quotas. A rep might have a $2M annual quota split across four quarterly quotas ($500K each).

Participant Management is the most operationally sensitive layer in practice. Mistakes here cause go-live disasters: missing plan assignments, orphaned participants without quotas, and misaligned hierarchies that break approval workflows. Most operational headaches trace back to participant data quality.

Layer 3: Pipeline Processing

The pipeline is the workflow engine that transforms raw credit transactions into calculated results. Think of it as an assembly line with configurable stations.

The typical pipeline has these stages:

• Import — Raw credit transactions arrive (orders from SAP Sales Cloud, revenue from S/4HANA, activities from Salesforce). They land in CSC_CREDIT as unprocessed input.
• Classify — Credits are categorized: which participant do they belong to? which plan? which period? This is where CRM transactions are matched to IM participants (often via territory or account mapping).
• Allocate — If a deal has multiple salespeople, credits are split. If a participant owns multiple territories, the system allocates credits to the right territory and the right plan component.
• Calculate — The calculation engine evaluates the plan rules. It looks up the participant's quota, applies rates, checks tiers, enforces caps, and produces an incentive amount.
• Approve — Results move to a workflow. SAP Advanced Workflow routes them to the participant's manager, then to finance. Only after approval can results be locked for payroll.
• Pay — Approved results are exported to payroll systems (SAP SuccessFactors Payroll, ADP, etc.) for actual compensation payment.

Pipeline runs are initiated on a schedule (daily, weekly, monthly) or manually by operations staff. Each run is tracked in the CSC_PIPELINE_RUN table with status, start time, end time, row counts, and error logs. Monitoring pipeline runs is a key operational task.

Layer 4: Calculation Engine

The mathematical heart of the platform. After credits are classified and allocated, the calculation engine applies the plan rules and produces the final incentive amounts.

The engine performs these operations:

• Quota Attainment — Compares actual results to the quota. A salesperson with $2M in quota and $1.5M in results has 75% attainment.
• Rate Application — Applies commission rates or bonus tiers based on attainment. If the plan says "pay 1% commission up to quota, 1.5% above quota," the engine splits the calculation at the quota line.
• Multiplier and Accelerator Application — Applies multipliers (1.5x for accelerated bonus above 100% attainment) and modifiers (regional multipliers, product-line modifiers, etc.).
• Cap Enforcement — Ensures payouts don't exceed the defined maximum (e.g., "no single rep can earn more than $500K per quarter").
• Clawback and Adjustment — Applies deductions or negative adjustments for chargebacks, returns, or policy violations.
• Results Aggregation — Combines results across multiple plan components into a single payable amount per participant per period.

Results land in the CSC_RESULTS table and related detail tables. The results table is the single source of truth for what each participant earned and why.

Layer 5: Compensation Statements

The end output: a personalized document for each participant showing what they earned, how it was calculated, and a breakdown by plan and component. Statements are generated as part of the pipeline (a pipeline stage itself) and can be viewed in the IM UI or exported as PDF.

Statement generation is one of the most common customization requests in implementations. Companies want their branding, specific KPI callouts, comparison to prior periods, and hyperlinks to transaction details. SAP SuccessFactors IM provides a templating system, but complex statements often require SAP Crystal Reports integration.

SAP HANA Database: The Foundation

SAP SuccessFactors IM runs on SAP HANA Database, a columnar in-memory data warehouse. This is not a relational SQL Server or Oracle Database database in the traditional sense — it's optimized for analytical workloads and can perform large aggregations and calculations at extreme speed.

For you as a practitioner, this matters for a few reasons:

• Table Naming — All IM tables use the prefix CSC_ instead of Callidus's CS_. This makes it easy to identify which tables belong to IM vs other applications on the same HANA instance.
• Query Performance — Columnar storage means aggregations are incredibly fast. Calculating summary statistics across millions of rows completes in seconds, not minutes. This enables real-time analytics.
• SQL Dialect — SAP HANA uses its own SQL dialect (similar to standard SQL but with extensions). Common functions differ: SECONDS_BETWEEN() instead of EXTRACT(EPOCH FROM ...), ADD_DAYS() instead of DATE_ADD().
• No Updating Calculated Tables — The key tabular structures (CSC_RESULTS, aggregation tables) are calculated and maintained by the pipeline, not manually updated. You can query them, but updating them directly is a breach of system integrity.

Key Tables in the CSC_ Schema

These seven tables are the core of the data model. Everything else is either supporting detail (result line items, component-level breakdown) or configuration (plan rules, rate tables, territory definitions).

SAP SuccessFactors IM vs. Callidus Commissions

If you're migrating from Callidus Commissions (or have Callidus experience), here's what changed and what stayed the same: