Path to payroll

Use this guide as your blueprint for building a minimum viable payroll product. Below, we've outlined core product requirements you need to consider across: the payroll data model, employer experience, employee and contractor experience, and Embedded Setup data synchronization.

What data do you need to power payroll?

Check provides a simple API to access otherwise immensely complex payroll features. Here’s what Check will handle for you:

Each of these functional components requires specific data from employers and employees. There are two ways to capture this data: (1) Check Onboard, which is a white-label product that provides a click-through experience for employers, employees, and contractors to capture all the data required to run payroll, or (2) custom workflows you build into your product on top of our APIs. We recommend starting by using Check Onboard, and then building more custom flows as you learn more about your customers.

Company Information

* Collected by the Check Onboard Component

Employee information

Contractor information

Payroll information

Billing information

As you will be adding a new payroll SKU to your product offering, you will also be adding a new payroll billing line item to your business. Billing functionality and the relevant data that is collected varies from company to company. Assess your billing data framework and ensure you consider payroll billing as a part of this model (i.e. plan type, billing period, etc.).

Automating this functionality is not required for launch, billing data ingestion can/should be handled manually for pilot. However, when you get to the point of a repeatable enrollment motion for payroll, you will want to ensure you have a way to track usage. Please reference our How to bill for core payroll and How to bill for passthrough fees articles, as well as our documentation on Check’s Usage API for more information.

A minimum viable payroll product includes the following functionality:

Using a combination of Check’s APIs along with Check Components, spinning up a payroll product could take two engineers approximately four weeks of development. To see a live demo of a payroll product built on Check, create an account at express-demo.checkhq.com.

The employer onboarding flow will have different requirements based on the type of business they are

If an employer is a new business ("inception business") and just running payroll for the first time, company setup is relatively simple, as they can just load their own information themselves through a fully product led flow. Please reference our Self Service Embedded Setup guide to learn more.

If the employer has run payroll before, this means they will have some kind of previous provider, whether it is a payroll provider software, an accountant, or they were running by hand + paper. Regardless of how they were running payroll before, if it is in the middle of the year, we will need to migrate year-to-date (YTD) payroll data to accurately calculate taxes and generate W2s at the end of the year.

Year to date history isn’t the only thing that’s needed to fully onboard an employer. Before any employer can run their first payroll, there are a number of prerequisites that need to be met - this includes signing Check's Terms of Service, providing bank account details, FEIN, relevant YTD pay history, and Know Your Business (KYB) info as well as e-signatures on authorization forms like the Federal Form 8655. These can be collected through your company Onboarding flow using Check Components and/or by Check's team of professionals when using our Embedded Setup offering

You as the partner have a variety of options to support the onboarding of switcher companies:

A company's ability to run payroll is tracked through the onboard.status field on the Check Company Object. As you complete onboarding, this status should move to state of completed or needs_attention - this is required before a company can run it's first payroll. It’s also important to note that Check will not be able to process payrolls for employers whose onboard status is in a blocking state.

Even after a company has successfully run their first payroll, a company’s onboard status can change from completed to needs_attention or blocking. This occurs most often when a new workplace in a new state is set up, prompting new state-specific forms to be signed by the employer. Your payroll product should have a mechanism in place to surface the Onboard Component whenever there is a change in status. To learn more about how to use onboard statuses, refer to the following guide in our API docs.

Employers will need the ability to edit their basic information. We advise only exposing edits to the following fields: legal name, company address, and phone number.

The ability to list and configure new pay schedules is crucial for companies paying employees on different cadences (i.e. contractors paid monthly and regular employees paid bi-weekly). It’s important to note that when using the Run Payroll Component, at least one pay schedule must be set up beforehand.

Workplaces are used to define physical locations for work performed. These locations are used to accurately determine which taxes to calculate for payroll.

The employer needs the ability to update the bank account used to debit payroll. Bank details are collected in the Onboard Component, but it’s important to allow the employer to change it within your app after the fact.

You will need to provide your employers with an easy way to add new employees or contractors that they intend to pay. We recommend organizing a list view of all workers, highlighting their onboard status for a quick view of which workers need attention.

Every employee and contractor should have a dedicated profile-like view of all relevant information that is easily accessible and editable by the employer. This includes general information like name, email, and home address, as well as bank details and assigned workplaces.

Optionally, this view can also include additional functionality for employers to set up things like benefits, post-tax deductions, or the ability to generate Employee or Contractor Onboard links to share out. Although not necessary, it's also helpful for an employer to have quick access to all relevant onboarding documents and pay stubs. The bulk of the aforementioned functionality already exists within Check Console today. However, it may make more sense for this to live on within your own payroll product for a better overall user experience. Below is an example of how the employee profile could look:

Using the Earnings Rates API, you can store hourly rates and/or salary for a worker. Earning rates are also used by the Run Payroll Component to denote rates for hours worked in a pay period.

A run payroll flow should include three key views: edit, preview, and a post-approval screen. Payrolls can be run following a pay schedule configured using the Pay Schedules API or independently as an off-cycle payroll. It’s important to note that every payroll flow needs the ability to run off-cycle payrolls to be able to support paying out the final wages of employees or contractors that were terminated.

Reduced to 3-5 days when using the Run Payroll Component. This Component supports simple payroll use-cases:

For a more differentiated flow, partners should build custom using the Payroll API. Even before the core payroll flow, you will need to build a basic view that allows employers to see previously run payrolls along with the ability to create new payrolls either from a pay schedule (optional) or off-cycle (required).

The edit view is a critical part of the run payroll flow. As seen in the Run Payroll Component, key information like payroll status, pay period, gross pay, and workplace are highlighted for the employer to easily see at a glance.

Before an employer can approve a payroll, they must be able to view a preview of it to ensure that their employees are paid correctly. Optionally, you can provide a view to surface any benefits or post tax deductions applied.

Finally, when an employer submits a payroll, they should be greeted with a success message followed by a summary of the payroll. This view, often exactly the same as the preview view, should include a button that allows the employer to reopen the payroll for edit.

You will need to provide access to the documents an employer signs when onboarding. This includes federal and state-specific authorization forms that are collected in the Onboard Component. The list documents endpoint surfaces all of the documents collected by Check that you can list in a table in the UI for download.

Although optional for an MVP, it’s beneficial for employers to have easy access to employee documents as well. We recommend setting up a dedicated Documents tab under each employee profile (outlined in the List, add, and edit employees and/or contractors above). Similar to employer documents, you can leverage the employee tax documents endpoint to surface relevant employee tax documents collected by Check in the Onboard Component.

You can surface employee documents alongside company documents by linking to the employee’s respective documents tab in their profile view. Clicking “View Documents” here links to the view in the screenshot above.

Employers will need the ability to generate payroll summaries and payroll journals. This is helpful for accounting and auditing purposes. Check provides two endpoints to generate these reports which return a PDF binary for download.

A minimum viable employee payroll portal includes the following functionality:

Using a combination of Check’s APIs along with Check Components, spinning up an employee payroll portal can take just under two weeks of development. To see a live demo of the employee portal, first create an employer account at express-demo.checkhq.com and then create an employee with another email address to get access.

In order to accurately pay employees or contractors, Check needs to collect information like payment method (direct-deposit or check), along with bank details, SSN (if applicable), and tax withholding preferences (if applicable). Similar to employer onboarding, Check provides an Employee Onboard Component and a Contractor Onboard Component to collect the necessary information from the respective worker type.

We recommend surfacing these steps when the employee or contractor first navigates to your employee payroll portal. Similar to employer onboarding, an employee’s onboard status can change from completed to need_attention or blocking. Your payroll product should have a mechanism in place to surface the Onboard Component whenever there is a change in status. To learn more about onboard status, refer to the following guide in our API docs.

Employees and contractors will need the ability to edit their basic information. We advise only exposing edit functionality to their email, home address, and payment method. The Employee Payment Setup Component can be surfaced for the employee to make changes to their payment method. Today, the Payment Setup Component does not support contractors. Instead, we recommend surfacing Contractor Onboard where the payment method can be updated instead.

Under the Fair Labor Standards Act (FLSA), the majority of states require employers to provide employees with paystubs (or pay statements). The Employee Paystubs Component surfaces paystubs generated by Check after a payroll. The API also provides a paystubs endpoint for you to independently create a list view of paystubs similar to the screenshot below.

The Employee Tax Documents Endpoint can be used to list and download employee documents, like the W-4, collected by Check in the Employee Onboard Component. This view should be identical to the one employers have access to in the employee profile (reference).