Transitioning from Tax Elements to Smart Compensation & Deduction Mapping in CMiC

• Transitioning from Tax Elements to Smart Compensation & Deduction Mapping in CMiC
  • Overview
  • 1. Why Change? (Business & Technical Rationale)
  • 2. What Replaces The Tax Elements Screen?
  • 3. The New Fields On Each Master
    • • Benefit Master (the four key controls)
      • Expense Categories
      • Deduction Master
  • 4. Compensation IDs (Comp IDs): The Engine Behind “Smart Taxability”
  • 5. Governing Exceptions With Override Pop-Ups
  • 6. Transition Playbook (slide-by-slide into actions)
  • 7. FAQs & Guardrails
  • 8. Customer Checklist
  • Conclusion

Overview

CMiC’s Vertex modernization retires the legacy, manual Tax Elements screen and replaces it with an intelligent, ID-driven model configured directly on the Benefit, Deduction, and Expense masters. Instead of hand-coding taxability for every jurisdiction, you assign Compensation IDs and Deduction IDs once and Vertex determines taxability by jurisdiction and pay type. The result is less setup, fewer errors, and compliance by design.

1. Why Change? (Business & Technical Rationale)

Business pain in the old model:

• Manual and inconsistent setup: users configured federal, state, local, and benefit/deduction taxability repeatedly across entities and locations.

  

  Payroll Tax Elements screen

• High misconfiguration risk and rework during audits.

• Complex reciprocity/“exempt here, taxable there” rules were easy to mishandle.

• Freedom to “roll your own” rules led to non-standard implementations and support burden.

Technical root cause:

• CMiC always defaulted the wage/compensation to Comp ID “00”—treated as always taxable—which distorted results and forced downstream overrides.

• This also required users to manually setup compensation where is taxable and remove where its exempt from the jurisdictions.

The fix:

• Move taxability decisions to Vertex using Compensation & Deduction IDs maintained on master screens; eliminate per-tax element mapping.

2. What Replaces The Tax Elements Screen?

New operating model:

• Configure once in:

  • Benefit Master (compensation behavior)

  • Deduction Master (pre/post-tax behavior)

  • Expense Categories (reimbursements & fringe)

    Vertex then applies jurisdictional rules automatically.

Bottom line: The Tax Elements screen is no longer needed; Vertex classifies with IDs and applies the right taxability—no guesswork.

3. The New Fields On Each Master

Benefit Master (the four key controls)

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

• Is the Benefit: Taxable/Exempt: Taxable flows to adjusted & taxable wages; Exempt is excluded.

• Compensation ID: Appears when Taxable; select from Vertex’s list (bonus, sick, vacation, GTL, etc.) to drive jurisdictional taxability.

  

  Compensation ID LOV pop-up

• [Override Taxability] button: Launches a pop-up to bind a user-defined Comp ID for special cases.

• Pay Type: tells Vertex whether to use Regular tables or Supplemental flat-rate method.

Expense Categories

The same pattern: Taxable/Exempt, Compensation ID, Pay Type to standardize fringe/expense treatment (e.g., parking).

Deduction Master

Pgm: PYDEDUCT – Deductions Master; standard Treeview path: US Payroll > Administration > Deductions > Master

• Is the Deduction: Taxable/Exempt: After-tax vs pre-tax behavior.

• Deduction ID (and Supplemental Deduction ID): Primary ID plus supplemental behavior for bonus/off-cycle.

  

  Deduction ID LOV pop-up

• Deduction ID Override Taxability: Jurisdiction-specific exceptions via pop-up (e.g., exempt in NY only).

4. Compensation IDs (Comp IDs): The Engine Behind “Smart Taxability”

What they are:

Numeric codes that classify compensation (bonus, severance, GTL, etc.) so Vertex knows what’s taxable, subject, or exempt by tax and jurisdiction.

Why they matter:

Choosing the correct Comp ID replaces the “00 = always taxable” workaround and enables accurate, automated mapping.

User-defined range:

Use 1000–1999 for customer-specific types; provide pay type and, if needed, override defaults.

Worked example: Group Term Life (GTL)

Employee has $1,000 base + $20 GTL (Comp ID 01).

• FICA: GTL fully taxable → base $1,020

• Fed Withholding: GTL subject but not taxable → base $1,000

• FUTA: GTL exempt → base $1,000.

Report terms you’ll see:

• Current Earnings, Subject, Adjusted, Taxable—and how Vertex flows from one to the next.

Example of impact on tax calculations

5. Governing Exceptions With Override Pop-Ups

Deduction example (Child Support in NY):

Keep the global Deduction ID Taxable, then add an override State = NY / Tax = ZSTA / Deduction Type = Exempt to comply with NY state withholding while preserving taxable status elsewhere.

Pgm: PYDEDUCT – Deductions Master; standard Treeview path: US Payroll > Administration > Deductions > Master

Override Taxability pop-up

Why it’s better than legacy:

The override gives precision and keeps the master clean; in the old screen, missed mappings defaulted the deduction to taxable.

6. Transition Playbook (slide-by-slide into actions)

1. Conversion Script

   CMiC will be providing a conversion script to update Deduction Master screen to update the deduction ID’s from the tax elements as best as possible. As per the tax element design the assumption is that the customer MUST have use ONE deduction per deduction code in the tax element screen. If there were a mismatch then the system will update the FIRST deduction ID. User must review all ID’s on the Master Deduction screen. (New model replaces Tax Elements with IDs on masters.)

   The Benefit Master setup must be reviewed by the customer and assigned appropriate compensation ID;s or by default payroll will consider them as “00”. Same rules applies to expenses.

2. Replace per-tax settings with master assignments.

   • For each Benefit: Set Is the Benefit, choose Compensation ID, set Pay Type, add Override only for bona-fide exceptions.

   • For each Deduction: Set Is the Deduction, populate Deduction ID (+ Supplemental ID if used), add Override entries where needed.

   • For each Expense: Set Taxable/Exempt, choose Compensation ID, confirm Pay Type.

3. Standardize supplemental logic.

   Confirm where Supplemental (flat-rate) should apply (bonuses, special runs) and set Pay Type accordingly for you benefit code.

4. Model known exceptions.

   Use Deduction ID Override Taxability for state/local carve-outs (e.g., NY child support). Keep overrides minimal and documented.

5. Validate with a GTL test.

   Run the GTL scenario to confirm FICA taxable / Fed WH subject-only / FUTA exempt—and verify the report columns (Current/Subject/Adjusted/Taxable).

6. Decommission Tax Elements.

   Once parity is confirmed, remove dependencies on the legacy screen; IDs on masters now drive taxability automatically.

7. FAQs & Guardrails

What if I can’t find a matching Vertex Comp ID?

Use a user-defined ID (1000–1999) and specify pay type; override if the default taxability doesn’t fit.

Do I still need per-jurisdiction entries?

Generally no—only for exceptions via the override pop-ups.

Why did our old setup over-withhold?

Many mapped wages as “00” (always taxable); the new model prevents that by design.

8. Customer Checklist

• Every Benefit has Taxable/Exempt, Compensation ID, Pay Type reviewed.

• Every Deduction has Taxable/Exempt, Deduction ID, Supplemental ID if used, and necessary Overrides.

• All Expenses are aligned to Compensation IDs and Pay Type.

• Documented list of user-defined IDs with purpose and rules.

• Test run covering regular vs supplemental, GTL example, and at least one override scenario.

Conclusion

Moving from Tax Elements to ID-driven master setup lets Vertex determine taxability by code and jurisdiction, dramatically reducing manual effort and error risk. Configure once on the masters, use overrides sparingly for exceptions, and lean on Compensation/Deduction IDs to keep payroll compliant and maintainable.