Your Payroll Processing Data Template
Your Payroll Processing Data Template
- Standardized data attributes for payroll analysis
- Essential process milestones to track in UKG Pro
- Technical extraction guidance for system integration
Payroll Processing Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity
ActivityName
|
The specific event or step performed in the payroll process. | ||
|
Description
This attribute captures the name of the step occurring within the payroll workflow, such as Time Sheet Submitted, Gross Pay Calculated, or Payment Executed. It defines the flow of the process map. These values are typically extracted from audit logs, system status change tables, or timestamped transactional updates within the UKG Pro environment. Consistent naming conventions are applied during data transformation to ensure readability in the process graph.
Why it matters
This is the mandatory Activity attribute that defines the nodes in the process map.
Where to get
System Audit Logs, Workflow History, or Transaction Timestamp columns
Examples
Time Sheet SubmittedGross Pay CalculatedPayment Executed
|
|||
|
Last Update Date
LastUpdateDate
|
The timestamp of the most recent modification to the data row. | ||
|
Description
This attribute indicates when the record was last changed in the database. While similar to the event timestamp, it is specifically used for incremental data loading and data integrity checks. It ensures that the process mining model reflects the most current state of the payroll record, capturing any late adjustments or retroactive corrections made by payroll specialists.
Why it matters
Mandatory attribute for incremental data refreshing.
Where to get
System metadata columns like LastModifiedDate
Examples
2023-10-05T17:00:00Z2023-10-06T09:00:00Z
|
|||
|
Payroll Record
PayrollRecordId
|
Unique identifier representing a specific employee within a specific pay period. | ||
|
Description
The Payroll Record acts as the central case identifier for the process mining analysis. It is conceptually constructed by combining the Employee ID and the Pay Period End Date (or Pay Group instance). This ensures that every payroll cycle for an individual employee is treated as a distinct case, allowing for the analysis of recurring processes over time. In UKG Pro, this is typically a composite key derived from the Payroll Header table or similar transactional records. Grouping by this ID allows analysts to reconstruct the end-to-end journey from time sheet submission to final payment and tax filing.
Why it matters
This is the mandatory Case ID that groups all payroll activities together to form a process instance.
Where to get
Derived from UKG Pro Payroll Header or Employee Pay History tables
Examples
EMP001-20231015EMP492-20231031EMP883-20231115
|
|||
|
Source System
SourceSystem
|
The system of record for the data. | ||
|
Description
This attribute identifies the origin of the data record. In this specific context, the value is statically set to UKG Pro (or the specific instance name if multiple exist). This is crucial for multi-system process mining where payroll data might be blended with general ledger data from an ERP. It allows analysts to filter views to show only steps originating strictly within the payroll platform versus those that might be integrated from external time-keeping systems.
Why it matters
Mandatory attribute for data lineage and multi-system analysis.
Where to get
Static value or System Configuration table
Examples
UKG ProUltiPro LegacyTime Management System
|
|||
|
Timestamp
EventTimestamp
|
The date and time when the activity occurred. | ||
|
Description
This attribute records the exact moment an activity took place. It is essential for sequencing events correctly and calculating durations between steps. High precision timestamps are preferred to distinguish between automated steps that happen in rapid succession. In the context of Payroll, this drives the dashboard analysis for Cycle Time Distribution and SLA Compliance. Without accurate timestamps, it is impossible to measure the velocity of Gross to Net calculations or the delay in Time Sheet Approvals.
Why it matters
This is the mandatory StartTime attribute required to sequence events.
Where to get
Date/Time columns associated with transaction status changes
Examples
2023-10-01T09:15:00Z2023-10-01T14:30:45Z2023-10-03T08:00:00Z
|
|||
|
Cost Center
CostCenter
|
The cost center code for financial allocation. | ||
|
Description
The Cost Center attribute defines where the payroll expense is allocated in the general ledger. While similar to Department, it often provides a more granular financial view. This attribute is used in the Time Tracking Approval Performance dashboard to identify if specific cost centers have slower approval hierarchies. It also helps in validating that payroll expenses are flowing to the correct financial buckets during the Gross to Net calculation phase.
Why it matters
Supports financial analysis and identifies bottlenecks by budget unit.
Where to get
Employee Job or Allocation tables
Examples
CC-5001CC-9002Overhead-Corp
|
|||
|
Cycle Time (Days)
CycleTimeDays
|
Total duration from initialization to payment execution. | ||
|
Description
This duration attribute measures the end-to-end time of the process for each record. It underpins the Payroll Cycle Time Distribution dashboard. Analyzing the variance in Cycle Time Days across different Pay Groups or Departments reveals inefficiencies and helps quantify the impact of manual corrections on the overall process speed.
Why it matters
Core metric for process efficiency.
Where to get
Calculated: Payment Timestamp - Initialization Timestamp
Examples
3.55.01.2
|
|||
|
Department
DepartmentCode
|
The department code associated with the employee. | ||
|
Description
This attribute links the payroll record to a specific organizational unit. It is essential for the Audit Exception and Correction Trends dashboard, allowing the organization to see which departments consistently generate errors or require manual intervention. By segmenting data by Department, analysts can identify if specific managers need training on time sheet approval processes or if certain business units have complex pay rules causing calculation delays.
Why it matters
Critical for organizational segmentation and root cause analysis.
Where to get
Employee Master or Job History tables
Examples
DEPT-100FINANCE-01OPS-WEST
|
|||
|
Gross Pay Amount
GrossPayAmount
|
The total pay calculated before deductions and taxes. | ||
|
Description
This attribute represents the monetary value of the gross pay calculated for the record. It is mapped to ActivityAmount to enable cost-based process analysis. Analyzing the Gross Pay Amount helps in the Gross To Net Calculation Velocity dashboard. While the dashboard primarily measures time, correlating time against the complexity (and value) of the payment can reveal if high-value or complex commission calculations are the source of performance issues.
Why it matters
Enables value-stream analysis and outlier detection.
Where to get
Payroll Result or Pay Register tables
Examples
2500.0010500.50480.00
|
|||
|
Has Audit Exception
HasAuditException
|
Flag indicating if an audit exception was triggered. | ||
|
Description
This boolean attribute flags whether the Audit Exception Flagged activity ever occurred for this case. It supports the First Pass Payroll Accuracy Rate KPI. It allows analysts to quickly separate 'clean' cases from those that required intervention, simplifying the analysis of rework causes in the Audit Exception and Correction Trends dashboard.
Why it matters
Identifies cases requiring intervention.
Where to get
Derived from existence of 'Audit Exception Flagged' activity
Examples
truefalse
|
|||
|
Is Off Cycle
IsOffCycle
|
Flag indicating if the payroll run is outside the standard schedule. | ||
|
Description
This boolean attribute identifies whether the payroll record belongs to an off-cycle run. It is used to calculate the Off Cycle Payroll Volume KPI. Off-cycle runs are typically costlier and more manual. Filtering the Process Variant Path Analysis dashboard by this flag highlights the non-standard paths taken to correct errors or issue ad-hoc payments.
Why it matters
Key filter for analyzing process deviations and rework.
Where to get
Payroll Header 'Check Date' vs 'Period End Date' logic
Examples
truefalse
|
|||
|
Is SLA Breached
IsSlaBreached
|
Flag indicating if the payment was executed after the deadline. | ||
|
Description
This boolean attribute is a calculated metric that compares the 'Payment Executed' timestamp with the 'SLA Deadline'. It is the direct driver for the Payroll SLA Adherence Rate KPI. Having this pre-calculated allows for instant filtering of the dashboard to show only problem cases, facilitating root cause analysis on why deadlines were missed.
Why it matters
KPI driver for compliance monitoring.
Where to get
Calculated: PaymentTime > SlaDeadline
Examples
truefalse
|
|||
|
Pay Group
PayGroup
|
The logical grouping of employees for payroll processing. | ||
|
Description
Pay Group is a fundamental configuration in UKG Pro that dictates the frequency (weekly, bi-weekly) and processing rules for a set of employees. It acts as the primary batch identifier. This attribute is critical for the Payroll Cycle Time Distribution dashboard. It allows for the comparison of processing performance between different groups, such as Executive Payroll versus Hourly Plant Workers, identifying if specific configurations are causing systemic lags.
Why it matters
Primary dimension for grouping and comparing payroll performance.
Where to get
Payroll Header or Pay Group Configuration table
Examples
US-BiWeeklyCA-WeeklyExec-Monthly
|
|||
|
Pay Period End Date
PayPeriodEndDate
|
The last day of the pay period being processed. | ||
|
Description
This attribute marks the closing date of the pay cycle. It serves as a critical reference point for determining if submissions are late. It is used alongside the StartTime of the 'Time Sheet Submitted' activity to determine lag times and is a key grouper for the Payroll Cycle Time Distribution dashboard.
Why it matters
Temporal anchor for the payroll cycle.
Where to get
Payroll Header or Time Period Configuration
Examples
2023-09-302023-10-15
|
|||
|
Payroll Specialist
PayrollSpecialist
|
The user ID or name of the person processing the record. | ||
|
Description
This attribute identifies the specific payroll administrator or specialist responsible for approving the record, performing data corrections, or executing the payment run. It is mapped to the Generic User attribute. This data is vital for the Specialist Workload and Throughput dashboard. It allows management to visualize how work is distributed across the team and identify if specific individuals are overburdened or acting as bottlenecks during the approval phase.
Why it matters
Enables resource analysis and workload balancing insights.
Where to get
Audit logs or 'ModifiedBy' columns in transaction tables
Examples
jsmithmdoesystem_admin
|
|||
|
SLA Deadline
SlaProcessingDeadline
|
The target date/time for payment execution completion. | ||
|
Description
This attribute defines the internal or external deadline for when the payroll process must be completed to ensure timely bank transfers. It is the core attribute for the SLA Compliance and Deadline Monitor dashboard. Comparing the actual Payment Executed timestamp against this deadline allows for the calculation of on-time performance rates and helps prioritize at-risk records.
Why it matters
Reference point for calculating SLA adherence.
Where to get
Pay Calendar or derived from Pay Date minus bank processing days
Examples
2023-10-13T16:00:00Z2023-10-28T16:00:00Z
|
|||
|
Tax Jurisdiction
TaxJurisdiction
|
The primary state or locality for tax filing. | ||
|
Description
This attribute identifies the main tax jurisdiction associated with the payroll record. It is essential for the Multi State Tax Filing Timelines dashboard. By analyzing process flows based on Tax Jurisdiction, compliance teams can spot if specific states have consistently slower filing completion times or if multi-state employees trigger more audit exceptions than single-state employees.
Why it matters
Critical for compliance monitoring and geographic analysis.
Where to get
Tax Location or Employee Tax tables
Examples
CANYTX
|
|||
|
Correction Category
CorrectionCategory
|
The type of data correction performed (e.g., Time, Rate, Deduction). | ||
|
Description
When a Data Correction Performed activity occurs, this attribute captures the nature of the fix. It is vital for the Manual Data Correction Rate KPI. Understanding if corrections are mostly related to 'Time Entry' versus 'Benefit Deduction' allows the business to target specific upstream systems or teams for process improvement.
Why it matters
Provides granularity on rework reasons.
Where to get
Audit Log 'Field Changed' column
Examples
Time Entry AdjustmentRetroactive PayTax Code Update
|
|||
|
Employee Type
EmployeeType
|
Categorization of employee (e.g., Full-time, Part-time, Contractor). | ||
|
Description
This attribute categorizes the individual associated with the payroll record. It is used in the Time Tracking Approval Performance dashboard. Different employee types often have different time sheet submission behaviors and approval workflows. Segmenting by this attribute helps distinguish between systemic process issues and behavioral patterns specific to certain workforce segments.
Why it matters
Segments analysis by workforce category.
Where to get
Employee Master table
Examples
Full TimePart TimeContractor
|
|||
|
Incentive Source
IncentiveSource
|
Origin of incentive data (e.g., SalesForce, Excel Import). | ||
|
Description
This attribute identifies the source of any incentive or commission data imported into the payroll record. It supports the Incentive Data Import Accuracy dashboard. By correlating this attribute with the Incentive Data Rework Frequency KPI, the team can determine if specific upstream files (e.g., the Northeast Region Sales Report) are consistently prone to formatting errors or data quality issues.
Why it matters
Traces quality issues back to external data providers.
Where to get
Import Log filename or Batch ID description
Examples
Sales Commission FeedManual Bonus UploadExecutive Comp System
|
|||
Payroll Processing Activities
| Activity | Description | ||
|---|---|---|---|
|
Payment Executed
|
The effective date or actual transfer of funds to the employee. This marks the fulfillment of the compensation obligation. | ||
|
Why it matters
Used to validate 'SLA Compliance' and ensure employees are paid on the committed date.
Where to get
Use the 'Check Date' or 'Advice Date' field on the finalized Pay Header record.
Capture
Logged when transaction payment_post executed
Event type
explicit
|
|||
|
Payroll Record Approved
|
The final sign-off on the individual record or the entire pay group. This action locks the record from further changes and queues it for payment generation. | ||
|
Why it matters
A critical milestone separating the working phase from the finalized phase. Used to calculate 'Bank Transfer File Lead Time'.
Where to get
Capture the status change of the Pay Group or individual Check record to 'Approved' or 'Locked' in the Pay Period Control table.
Capture
Logged when transaction approve_pay_group executed
Event type
explicit
|
|||
|
Payroll Record Initialized
|
The creation of the specific pay line item for an employee within a new pay group instance. This signals that the employee is active and attached to the current processing cycle. | ||
|
Why it matters
Marks the official start of the payroll processing phase within the core system. Essential for distinguishing between time capture duration and actual payroll processing duration.
Where to get
Identify the timestamp when the record is inserted into the Employee Pay or Check Header table for the specific Pay Date.
Capture
Logged when transaction pay_period_create executed
Event type
explicit
|
|||
|
Tax Filing Completed
|
The successful submission of tax data to the relevant jurisdictions (federal, state, local). This often happens post-payment. | ||
|
Why it matters
Essential for the 'Multi State Tax Filing Timelines' dashboard to ensure regulatory compliance and avoid penalties.
Where to get
Capture the status update in the Tax Filing Interface or Payment Services log indicating 'Filed' or 'Accepted'.
Capture
Logged when transaction tax_file_transmit executed
Event type
explicit
|
|||
|
Audit Exception Flagged
|
The system or a user identifies a discrepancy, such as negative pay, missing tax codes, or SLA warnings. This puts the record into a state requiring attention. | ||
|
Why it matters
Directly feeds the 'Audit Exception and Correction Trends' dashboard. High volumes here indicate upstream data quality problems.
Where to get
Identify records in the System Warning Log or Pay Period messages table associated with specific employee IDs.
Capture
Logged when transaction validation_warning created
Event type
explicit
|
|||
|
Bank Transfer File Generated
|
The technical generation of the NACHA or direct deposit file for transmission to the bank. This prepares the funds for movement. | ||
|
Why it matters
Delays here directly risk missing banking cutoffs. Supports the 'Bank Transfer Generation Speed' dashboard.
Where to get
Capture the timestamp when the ACH/Direct Deposit file creation job completes in the System Job Log.
Capture
Logged when transaction create_ach_file executed
Event type
explicit
|
|||
|
Benefits Deductions Applied
|
The system applies pre-tax and post-tax benefit deductions (health, 401k) to the gross pay. This logic typically runs immediately following gross pay determination. | ||
|
Why it matters
Errors here often require manual corrections. Isolating this step helps determine if delays are caused by the benefits engine or configuration issues.
Where to get
Inferred from the timestamp of the calculation batch or by observing creation timestamps in the Employee Deduction History table.
Capture
Derive from comparing field calculation_stage
Event type
inferred
|
|||
|
Data Correction Performed
|
A manual modification made to the payroll record (e.g., adjusting hours, overriding tax) after the initial calculation but before final approval. | ||
|
Why it matters
This is the primary measure of rework. Tracking this enables the 'Manual Data Correction Rate' KPI.
Where to get
Capture updates to the Employee Pay Detail or Deduction tables in the Audit Log where the User ID is not 'System'.
Capture
Logged when transaction update_pay_detail executed
Event type
explicit
|
|||
|
Gross Pay Calculated
|
The initial calculation run where the system determines total earnings based on hours, rates, and incentive data. This occurs before deductions and taxes are applied. | ||
|
Why it matters
Measuring the time from here to 'Taxes Calculated' provides the 'Gross to Net Calculation Velocity' metric required for system performance analysis.
Where to get
Inferred from the 'Start Time' of the calculation batch process in the System Job Log.
Capture
Compare status field before/after calculation job start
Event type
inferred
|
|||
|
Incentive Data Imported
|
The ingestion of external compensation data such as commissions, bonuses, or one-time payments. This is distinct from regular hours and often involves batch file uploads. | ||
|
Why it matters
High failure rates or rework following this activity indicate issues with data mapping or external file quality, a common source of payroll delays.
Where to get
Capture from the System Log or Batch Import History where the file type relates to 'Incentives' or 'Additional Pay'.
Capture
Logged when transaction import_batch_data executed
Event type
explicit
|
|||
|
Pay Slip Published
|
The pay statement becomes visible to the employee in the self-service portal. This completes the communication loop. | ||
|
Why it matters
While not a blocking technical step, late publication drives helpdesk calls and impacts employee satisfaction.
Where to get
Inferred from the 'Check Date' or a specific 'Self Service Release Date' setting in the Pay Group configuration.
Capture
Derive from comparing field check_date to release_policy
Event type
inferred
|
|||
|
Payroll Result Previewed
|
A user opens the payroll register or preview report to validate the calculated results. This represents the transition from automated processing to human review. | ||
|
Why it matters
Indicates the start of the validation phase. A long gap between Calculation and Preview suggests resource availability issues.
Where to get
Capture from the Audit Log where a user accesses the 'Payroll Register' or 'Pre-Check' report.
Capture
Logged when transaction report_view_preview executed
Event type
explicit
|
|||
|
Taxes Calculated
|
The final stage of the calculation engine where multi-state tax logic is applied to determine net pay. This completes the automated computation phase. | ||
|
Why it matters
Completes the 'Gross to Net' sequence. Long durations here suggest performance issues with the tax engine or complex multi-jurisdiction configurations.
Where to get
Inferred from the 'End Time' of the calculation batch process in the System Job Log or the timestamp on the Employee Tax table.
Capture
Compare status field before/after calculation job end
Event type
inferred
|
|||
|
Time Sheet Approved
|
The managerial approval of the submitted hours, validating them for payment processing. This step unlocks the data for import into the payroll calculation engine. | ||
|
Why it matters
Bottleneck analysis of this step reveals delays caused by management review, which directly impacts the available window for payroll specialists to process data.
Where to get
Capture from Time Management history where Status changes to 'Approved' or 'Signed Off'.
Capture
Logged when transaction time_card_approve executed
Event type
explicit
|
|||
|
Time Sheet Submitted
|
The event where an employee or manager submits the time card for the pay period. This marks the entry of raw hours data into the broader payroll workflow, though it may originate in the Time Management module before flowing to core Payroll. | ||
|
Why it matters
Establishes the earliest start timestamp for the end-to-end payroll cycle. Critical for measuring the latency between work performance and payroll data ingestion.
Where to get
Capture from the Time Management Audit Log or Time Card History table where the Status field changes to 'Submitted'.
Capture
Logged when transaction time_card_submit executed
Event type
explicit
|
|||