You are on page 1of 4

Ask the Experts Q&A Series: Payroll Integrations

June 11, 2020

Payroll Integrations: A Cross-Functional


Perspective
1. We have employees in multiple countries and the number of employees varies greatly
from a couple dozen to several thousand. Do we take the same approach with all of
our countries for payroll, or should we look at different options?
If a Workday delivered connector exists (Ex: ADP streamline, GDP, Safeguard),
connectors should be used. In addition, Workday also offers the option to send Local
Payroll data to external vendors who support that feature which is another good option.
If using a custom solution, use the following guideline:
i. 1– 100 Employees: Use a report
ii. 151 – 150K employees – PECI
iii. > 150K – PICOF
iv. If worker population includes contingent workers, consider using WECI to
transmit worker data.

2. I understand that there is more than one option on the type of integration that can be
used for a PI. What are the considerations for each type of integration?
If WD delivered connector exists for the vendor, our recommended approach is to use
the delivered connector.
If vendor can handle only top of stack transactions or requires a simple CSV or XML
format, then consider using PICOF instead of PECI.
If Worker population is > 150, then PICOF else PECI. PECI has limitation of 150K workers
per paygroup.
Corrections and rescinds are handled appropriately by PECI where PICOF, produces a
report and these would have to be handled manually.
PICOF is an “end-of-Life” product meaning Workday may no longer add
enhancements/changes to this template. The PECI does bring many advantages and
extensible for future enhancements. If the requirement is matching to PICOF with
vendor is not able to receive the full stack file, then PICOF can be a better option. PECI
can return corrections and rescinds, whereas PICOF has limited option to handle
corrections and rescinds.
If worker population includes contingent workers, consider using WECI (Worker
Effective Change Interface) to transmit contingent worker data.

Collaborative Solutions, LLC. 1


Ask the Experts Q&A Series: Payroll Integrations
June 11, 2020

3. Per our IT governance model, we need to identify what is the system of record for
each of our data points across our systems. When using a PI which system is the
system of record for payroll data – Workday or the payroll system?
Workday recommends using your payroll system as the system of record for payroll
data. Examples are tax elections (Federal and State for US), earnings, and deductions
that do not flow through Workday.

4. Where should personal information related to receiving pay be entered (direct deposit
information for example)? In Workday or in our payroll system? What about our
earnings and deduction codes? Time off requests?
Workday fully supports payment elections since they are stored under personal data
and not payroll. Earnings and Deductions should only be stored in Workday if they are
being passed through Workday. One-Time Payments and Allowance plans will more
than likely always be stored in Workday and can be passed to the payroll provider. If you
are not using Workday Benefits then you would have no need to set up the deduction
codes. Time off request would only be needed if you are using Workday Absence.

5. We’ve been live in Workday for a while, but are expanding our global footprint and
need to set up PI for several countries. I am worried we don’t have all the data we
need in Workday to support payroll in those countries. What HCM data do we need?
We recommend working with your local payroll vendors on the fields they will be
requesting to receive from Workday. Some will request Date of Birth, number of
dependents, marriage date, etc., and you would want to make sure you have this data
to put in Workday. An experienced Workday consultant can help you identify the most
appropriate place to hold this information in the application. Knowing these items
before the implementation begins will help it go faster and smoother.

6. Our time off and LOA plans are complex (or at least feel that way.) How do we make
sure they work correctly with our PI? In our previous systems we had a lot of trouble
making sure our time not worked fed into payroll correctly.
For both time off and leave of absence, it is imperative that the detailed E2E test
scenarios are completed for every absence type to ensure all values are able to be
passed through the PI and mapped to a corresponding PI value. Below are some
additional considerations for Time Offs and Leave Events.
Time Off
For Time Off the payroll interface (PICOF /PECI) can easily move time off taken
downstream to a payroll vendor for processing. The complexity of the plan/accrual itself
isn’t a primary factor for what is picked up by the interface since these calculations
occur in workday prior to the time off being entered. A couple of items that are key:

Collaborative Solutions, LLC. 2


Ask the Experts Q&A Series: Payroll Integrations
June 11, 2020

1) Test the plans, accruals and time offs thoroughly to make sure they are
functioning in alignment with policy. Since these provide the raw materials for
the PI it’s critical they’re accurate.
2) Understand exactly what the payroll provider requires to calculate pay, generate
data elements required on the paycheck and understand where the calculations
need to occur. For example, does the provider have all of the meta-data required
to generate pay; or is there some amount of preprocessing of time off that
can/should occur in the PI. Understand if time not worked (for a time off) is all
that is required by payroll, or is it required to provide forecasted hours, hours
not worked and hours worked.
Leaves of Absence
Workday is limited to reporting if a worker is on leave. We can implement leaves in a
way that the type of leave can be instructive as to how to pay. For example a leave type
of Short Term Disability 66% could be fed to by the PI to the payroll provider, but we are
not able to send an exact dollar amount to be paid. It would be up to the payroll vendor
to calculate actual pay since it would not be something we would expect – or want –
calculated in an interface file.
When setting up the Leave Types in workday, start with a list of leave values that are
being captured in the PI so that a 1 to 1 mapping can be completed between Workday
and the payroll vendor. Concurrent leave events should be avoided when using PI as this
can cause issues when there are competing pay impacts for separate leave types.
7. We understand testing is an important part of any new system. What are some
important steps for us to take to properly prepare ourselves? How early should we
engage our 3rd party payroll provider?
Collaborative recommends a minimum 6 weeks for End to End testing. Make sure the
vendor has an UAT instance where all test scenarios can be tested thoroughly. First
cycle of testing should include New hires. In cycle two, add job data changes, Leaves and
Terminations. In cycle three, include RFL for those on leave in Cycle 2, terms,
corrections, and rescinds.
8. Once the needed HCM/Payroll data is identified what should we do to prepare
ourselves for the data conversion files that will be requested of us? What type of data
cleanup do you recommend?
We recommend doing a “clean-up” check with your compliance team to make sure
you’re able to purge records that haven’t been used. Example: if an employee has 7
bank accounts but are only using 1 or 2. We also recommend asking employees to make
sure their most current personal data (home address, email, phone number, emergency
contact) is up to date.

Collaborative Solutions, LLC. 3


Ask the Experts Q&A Series: Payroll Integrations
June 11, 2020

9. If we use Workday as the system of record for our data points across our systems,
what are our options for bringing in pay results from our 3rd party payroll provider?

Data from external payroll vendor can be imported as External Payroll results and used
for reporting purposes. The Import Payslip connector can also be used to store Worker
Payslip data.

10. When do you recommend using PECI instead of PI? And use primary and ad-hoc
model?
See #2 for PECI vs PI.
Primary integrations: These are scheduled integrations where change detection is
automatically performed based on the pay period status - it includes all effective
changes for pay periods whose status is Not Yet Started, and only changes since the last
successful run when the pay period status is In Progress. The integration requires only 2
launch parameters, Pay Group and Pay Period Selection Option.
AdHoc Integrations: These are used for AdHoc/Error resolutions and run manually.
Workday recommends that you do not enable the PI Change Detection Launch
Parameters and PI Members Launch Parameters integration services on a Primary
Integration. Use these parameters on ad hoc/error resolution runs.
When a separate integration is used for Time Tracking, these integrations are run once
per pay period and do not have Primary Integration attribute enabled.

11. Do you recommend partitioning the data returned in the payroll interfaces? Payroll,
OTPs, Time Off and Time Tracking... meaning creating a single PI for every one of
those. I know Workday recommends having separated Time Tracking but wanted to
see if you have others?
Time Tracking Integrations are standalone non-primary integrations, since these are
only run once pay period and it is recommended best practice to have a separate
Integration for Time Tracking.
If the requirements dictate producing separate files, a merged payroll extract can be
used for all pay groups and post processor such as Document Transform or Studio to
produce separate files as required.

Collaborative Solutions, LLC. 4

You might also like