Compensation IDs in CMiC (PTX): How They Work & Their Impact on Tax Calculation

• Compensation IDs in CMiC (PTX): How They Work & Their Impact on Tax Calculation
  • 1. What is a Compensation ID?
  • 2. What Changed from PTQ / Legacy Tax Elements?
  • 3. Where do Comp IDs Live in CMiC?
    • Benefit / Expense Master – New Fields
  • 4. Understanding Pay Type & Calculation Method
  • 5. User-Defined Comp IDs (1100–1999)
    • When to Use User-Defined Comp IDs
    • Compensation ID - Taxability Setup (Design Pattern)
    • Earnings Bases in PTX: Current, Subject, Taxable, Adjusted
    • How They Flow in PTX Logic
  • 6. End-to-End Processing Flow (Payroll)
  • 7. Practical Examples
    • Example A: Qualified Parking (Expense)
    • Example B: Group Term Life (GTL)
  • 8. Tax Override Screen — When & How to Use
  • 9. Migration Guide: From Tax Elements to Comp IDs
  • 10. Testing Checklist (Recommended)
  • 11. FAQs

1. What is a Compensation ID?

Codes for alternate compensation

A Compensation ID (Comp ID) is a standardized classifier—defined and maintained by Vertex—that tells PTX what the pay is (e.g., regular wages, qualified parking, GTL, moving expense). Comp IDs replace the legacy CMiC Tax Elements approach. Instead of hard coding taxability per jurisdiction, CMiC sends the Comp ID with each pay line to Vertex PTX, which returns taxability and calculation treatment by federal, state, and local rules.

Key Benefits

• Jurisdiction aware taxability: Vertex interprets Comp ID + employee/work locations + reciprocity to determine taxable bases.

• Less config, fewer mistakes: No more maintaining large per jurisdiction matrices in CMiC.

• Future proofing: As laws change, Vertex rules drive the treatment.

2. What Changed from PTQ / Legacy Tax Elements?

Area	Legacy (PTQ)	New (PTX + Comp IDs)
Taxability source	CMiC Tax Elements screens configured per jurisdiction	Vertex PTX rules based on Comp ID + context
Default mapping	Customers often used a generic default like “00 = always taxable”	Defaulting to “00” is retired. Each benefit/expense must be mapped to a specific Comp ID (or a governed user-defined ID)
Overrides	Scattered rules/flags	Centralized Tax Override screen for explicit edge cases
Transition	Manual re-keying	CMiC provides a script to retire Legacy Tax Elements, assign default “00” to benefits/expenses, and update deductions “as close as possible” on the new masters; customer must review and finalize

Action for Customers

After the script, review every Benefit and Expense and assign the correct Compensation ID. Use the Tax Override screen for any state-specific exceptions or reciprocity edge cases.

3. Where do Comp IDs Live in CMiC?

Comp IDs are selected on the Benefit and Expense master screens. Both screens were enhanced with three new fields and a link to Tax Overrides.

Benefit / Expense Master – New Fields

1. Compensation ID: LOV of Vertex-defined Comp IDs plus governed user-defined range.

2. Pay Type: Regular or Supplemental to signal calculation method; supplemental drives “supplemental wage” rules where applicable.

   

   Pgm: PYBENFIT – Benefits Master; standard Treeview path: US Payroll > Administration > Benefits > Master

3. Applicability/Taxable toggle (Expense only): Whether the item is subject to taxability evaluation (send to PTX) or always exempt (true reimbursements). Use sparingly; Vertex should decide in most cases.

4. Tax Override (screen/button): Maintain jurisdiction exceptions, reciprocity, or special handling (e.g., NY Child Support–style cases).

The Expense setup mirrors the Benefit setup.

Example used in training: Parking expense mapped to a qualifying parking Comp ID for Vertex to apply the correct taxability rules.

4. Understanding Pay Type & Calculation Method

• Regular pay type: PTX evaluates with regular wage rules.

• Supplemental pay type: PTX evaluates using supplemental wage rules (e.g., flat-rate withholding where applicable).

• Calculation Method Override: Separate screen is available for rare scenarios needing a forced method; default to Vertex’s decision whenever possible.

Why this matters: Correct Pay Type ensures the correct withholding calculation path even when the taxable base determined by PTX is the same.

5. User-Defined Comp IDs (1100–1999)

CMiC exposes a governed range 1100–1999 for customer-specific pay types not covered by standard Vertex IDs.

Governance Recommendations

• Maintain a register: ID, name, description, intended usage, owning department.

• Establish a naming convention and require approver sign off (Payroll + Tax/Compliance) before first use in production.

• Create unit tests (see 10. Testing Checklist (Recommended)) for each custom ID to prevent regressions.

Only use a user-defined ID when no standard Vertex ID fits. When Vertex later introduces a standard ID, plan a migration to it.

When to Use User-Defined Comp IDs

Pgm: PYUSERTAXVAL – Vertex User-Defined IDs; standard Treeview path: US Payroll > Administration > Taxes > Vertex User-Defined Ids

Use a governed 1100–1999 Comp ID when one or more of the following applies:

• A custom benefit or perk doesn’t align with Vertex’s built-in types (e.g., travel per diem bonus, project completion reward).

• You need complete control over how the item is treated for subject vs taxable bases (temporary pilots, contractual edge cases).

• You’re testing/piloting new compensation plans without impacting production mappings.

Reminder: Keep these under change control, with written rationale, examples, and tests. Plan to migrate to a standard Vertex ID if/when one becomes available.

Compensation ID - Taxability Setup (Design Pattern)

Taxability List pop-up

A user-defined Comp ID can be modeled with an explicit subject/taxable posture to mirror Vertex semantics:

• CashSubjectTaxable: Regular wages, bonuses.

• CashSubjectNotTaxable: Reportable but tax-exempt allowances.

• NonCashSubjectTaxable: Imputed income (e.g., GTL over $50K).

• NonCashNotSubjectNotTaxable: Non-reportable fringe benefits.

These are governance patterns for your internal catalog. The actual authority-by-authority result still comes from PTX once you send the Comp ID.

Earnings Bases in PTX: Current, Subject, Taxable, Adjusted

Understanding these terms helps explain why different authorities show different wage bases even for the same Comp ID.

Sample Vertex Employee Report

1. Current Earnings

   • Definition: Total gross pay earned this period.

   • Includes: Base wages, overtime, bonuses, taxable fringe (when applicable).

   • Used for: Pay slip and gross reporting.

   • Example: $1,000 base + $20 GTL imputed = $1,020 Current.

2. Subject Earnings

   • Definition: Portion of Current that a given tax considers in its base, even if not ultimately taxed.

   • Think of it as: “Included in the jurisdiction’s wage base.”

   • Used for: Wage limits, eligibility checks (e.g., Social Security max).

   • Example: GTL may be subject to Federal Withholding (must be reported) but not taxable.

3. Taxable Earnings

   • Definition: Portion of Subject actually multiplied by the tax rate.

   • Used for: The employee’s tax liability calculation.

   • Relation: Always ≤ Subject.

   • Example: FUTA — GTL not taxable, so only $1,000 base is taxed. FICA — GTL taxable, so $1,020 is taxed.

4. Adjusted Earnings

   • Definition: Internally adjusted base PTX uses after applying deductions/exclusions/offsets.

   • Used for: Feeding the most accurate base into each authority’s calculation.

   • Example: An exempt deduction reduces taxable income; Adjusted reflects that reduction.

How They Flow in PTX Logic

• Current: What the employee earned.

• Subject: What the jurisdiction cares about.

• Adjusted: After exclusions/deductions.

• Taxable: What actually gets taxed.

6. End-to-End Processing Flow (Payroll)

1. Time/Benefits/Expenses create pay lines.

2. Each pay line carries Comp ID + Pay Type (and, for expenses, the applicability flag if used).

3. CMiC calls Vertex PTX APIs with the pay line context: home/work locations, residency, reciprocity flags, filing status, YTD, etc.

4. PTX returns: taxable inclusion/exclusion for FIT, FICA/Medicare, FUTA/SUTA, state/local; and the calculation method outcome for withholding.

5. CMiC calculates withholding amounts and taxable wages per authority based on PTX response.

6. Overrides (if any) are applied as per the Tax Override screen configuration.

7. Results post to Payroll, GL/JC, and feed reports (e.g., Employee tax detail).

7. Practical Examples

Example A: Qualified Parking (Expense)

• Business Case: Company reimburses job site parking.

• Setup: Expense master:

  • Comp ID = Qualified Parking (training example referenced ID 09)

  • Pay Type = Regular (typical)

  • Applicability = Send to PTX

• Effect: PTX will decide federal/state/local taxability and inclusion in FICA/FUTA based on current rules and thresholds.

• Why not “always exempt”?: Because treatment varies by jurisdiction and caps. Let PTX decide.

Example B: Group Term Life (GTL)

• Business Case: Imputed income for employer-provided life insurance beyond allowed thresholds.

• Setup: Benefit master:

  • The GTL Comp ID

  • Pay Type usually Regular (imputed income)

• Effect: PTX returns which authorities include GTL in taxable wages and how withholding should be computed.

• Tip: GTL often differs in inclusion across FIT vs FICA/FUTA. Always confirm with PTX responses rather than hard coding.

Additional scenarios covered in training include state reciprocity (e.g., MD↔DC, WI↔MN non-reciprocal), where taxability and withholding location are determined by PTX using residency/work facts in combination with the Comp ID.

8. Tax Override Screen — When & How to Use

Use overrides sparingly to document intentional exceptions:

• Reciprocity/Residency edge cases not handled by employee data (e.g., missing non-resident certificate flag at time of payroll).

• Mandated authority exceptions (e.g., a specific state program that overrides default treatment for a Comp ID).

• One-off grandfathering during transition/pay correction cycles.

Good practices:

• Capture reason & reference (policy/ticket) on every override.

• Apply overrides at the lowest effective scope (employee, authority, period) to avoid unintended spillover.

• Review overrides quarterly; aim to retire them once the underlying data/process is fixed.

9. Migration Guide: From Tax Elements to Comp IDs

1. Run the CMiC transition script:

   • Retires Legacy Tax Elements.

   • Sets default “00” on Benefits/Expenses.

   • Updates Deductions on the new Deduction Master as close as possible.

2. Map every Benefit/Expense to a Comp ID:

   • Replace “00” with the correct standard Vertex Comp ID.

   • Only use 1100–1999 for genuine gaps.

3. Validate state-specific cases:

   • Review reciprocity and withholding in the new Tax Override screen, only adding overrides where necessary.

4. Regression test (see 10. Testing Checklist (Recommended)) with real employee mixes and prior pay periods.

5. Cut-over controls:

   • Freeze legacy changes.

   • Communicate new setup and support playbook to Payroll Ops & Support teams.

10. Testing Checklist (Recommended)

Data Readiness

• Employee residency & work locations (primary/secondary) are accurate.

• Non-resident certificates and reciprocity flags reflect reality.

• Benefits & Expenses all have non “00” Comp IDs assigned.

Unit Tests

• For each Comp ID in use (including user defined):

  • Single employee test (baseline)

  • Cross border test (residency/work in different states)

  • Supplemental scenario if applicable

Payroll Cycle Tests

• Small pilot run (5–10 employees across jurisdictions)

• Mid-size run (50–100 employees, include fringe/expense variety)

• Compare: taxable wages by authority, FIT/FICA/SUTA/FUTA bases, net pay deltas, and W 2 map implications.

11. FAQs

Do we still need a “Taxable/Exempt” switch on Expenses?

Prefer letting PTX decide. Use the switch only for items that are strictly non-wage reimbursements that should never be evaluated by PTX.

What if a Comp ID seems to give the “wrong” result?

First verify employee data (residency, locations, reciprocity flags) and Pay Type. If still off, review the Tax Override screen and open a ticket with evidence (PTX request/response).

When do we use Supplemental Pay Type?

Bonuses, commissions, and other supplemental wage scenarios where jurisdiction rules differ from regular wages.

Can we reuse our old “00” fallback?

No. “00” is a temporary placeholder only during transition. Replace it with a specific Comp ID or a governed user-defined ID.