Money Movement Platform

Context:
After standing up Paylocity’s Modern Tax System, which gave us a structured approach to managing our clients’ varying tax obligations, it became clear that how we’d historically been handling the underlying movement and reconciliation of funds left a lot to be desired.

As a Payroll and HCM company operating under a TPA / POA model with our clients, moving funds between Paylocity-held accounts, client accounts, employee accounts, tax authorities, and other entities is the linchpin of our business.

Unfortunately, our system for doing so became unruly after it had grown ad-hoc over the years. The resulting system and workflows were fragmented, difficult to manage, and relied far too heavily on manual intervention and tribal knowledge. That’s not a sustainable way to operate or scale an enterprise system.

Our different teams like Payroll, Tax, Banking Operations, Engineering, and Support all interacted with transactions in different ways, often relying on a mix of internal tools, database reports, and manual processes to request, execute, track, and verify the movement of money.

This resulted in a murky view and minimal shared understanding of how transactions actually moved through the system from end to end.

The Problem:
This lack of a unified model and standardized processes resulted in real operational challenges across the company.

At its core, our org’s workflow for moving money was still highly manual. ACH files had to be generated multiple times per day by Banking Ops users in order to be transmitted on time to meet bank processing deadlines. Missing a deadline could push payments out another business day, creating real downstream risk for time-sensitive obligations like payroll deposits or tax payments.

Aside from executing payments, there was no consistent way to manage or clearly understand transactions triggered from the many, various parts of our HCM platform. Different services implemented their own methods for requesting, funding, and tracking payments, which led to fragmentation across the system. Similar types of transactions were being handled in different ways depending on the product or team.

Our Banking Ops Teams had to rely heavily on spreadsheets, raw ACH and BAI2 files, and internal reports to piece together what was happening. This made even basic questions – internally or for clients – difficult to answer without manual investigation, which in turn was also a challenging process.

There was no shared platform responsible for performing money movement in a consistent, reliable way. Our services like Tax, Payroll, Rewards and others each owned parts of the process themselves, instead of being able to rely on a centralized system that could handle requests, execution, and status updates.

Combined, this all made the verification and reconciliation of funds (one of the most important jobs in the entire organization) far more complex than it needed to be. Banking Ops users were responsible for ensuring funds were successfully moved and accounted for, both at the payment level and at the client level, but they didn’t have a unified system to support those key, daily workflows in a structured way.

While spinning up our in-house full-service tax product put a spotlight on many of these issues, the underlying problem extended beyond any single domain. We had a platform-wide gap in how money movement was structured, carried out, and supported.

System Mapping:
The first step I had to take was making the entire system understandable.

In order to do so, I built a service blueprint that mapped the full lifecycle of a payment, starting with Client Onboarding, followed by a Payroll run through to Tax and Money Movement, into and out of the Banks and back into Paylocity for Reconciliation.

It clearly depicted the journey of how funds were requested, processed, and ultimately verified and told the story across multiple swimlanes to show how transactions should actually move through the system from end to end.

It also made inputs, outputs, and dependencies between systems explicit, helping us identify gaps, overlaps, and failure points as we evolved the document into its final form below:

Rather than focusing on a single product or workflow, my goal was to capture the system as a whole and define a clear model for how it should operate. This made it possible to see how different services initiated requests, how funds were moved between accounts, what could be automated, where human intervention was still required, and how reconciliation was handled after the fact.

This became a shared artifact used across the triad to align both teams and stakeholders on how money movement worked and how it should evolve moving forward. It was built through close collaboration with product and business partners to uncover how these processes functioned in practice, where they were breaking down, and how they could be improved through a more unified system.

Most importantly, it established a common language and mental model that let Product, Design, Engineering, and Ops all discuss the system in the same way. It fast became something we frequently referenced in stakeholder discussions, was regularly pulled up in working sessions, and also wound up being really useful when onboarding new team members.

Designing for Multiple Roles:
One of the most important parts of this work was accounting for the different teams, roles and systems involved across the lifecycle of a transaction.

This wasn’t a platform built for a single type of user. It had to support a range of areas, each with its own goals and responsibilities. From clients running payroll, to Tax teams managing obligations, to Banking Ops reconciling funds, everyone interacts with money movement in a different way. They all have different priorities.

To accurately capture this, I partnered closely with my product and business partners to understand how each role actually operated, what they needed from the system, and where things overlapped.

Key Money Movement Participants

This resulted in a set of clearly defined participants that were baked directly into the blueprint, ensuring the system reflected the full range of users and workflows involved in moving money end to end.

The Platform:
Visually mapping the system cemented the notion that we needed to treat money movement as a shared platform underlying our different HCM services rather than something that each one implemented bits and pieces of on its own.

Instead of embedding portions of payment logic within Tax, Payroll, and other products, we built a model where they’d just hook into a centralized platform and make a request. Any service could now simply ask that a specific amount be collected from one account and delivered to another by a defined date. This gave us a consistent, systematic way for services to move money and laid the groundwork for greater automation, speed, and accuracy across the organization.

From there, the Money Movement Platform would take over and automatically carry out the transaction, from funding, executing, tracking, and updating the status of each payment as it moves through the system. This ensured requests were handled quickly, accurately, all while reducing the need for human intervention.

This created a clear separation of labor with services defining what needed to happen and the Money Movement Platform handling how it happened, positioning it as a service enablement layer across the organization. This allowed products like Tax, Payroll, Rewards and more to rely on a shared, consistent foundation rather than implementing their own fragmented solutions.

Transaction Visibility:
Outside of fast, accurate and automated money movement, the most immediate gap the platform addressed was visibility into transactions. By centralizing all transaction activity into a single source of truth, users could track the complete lifecycle of any payment from start to finish.

Before, answering even basic questions about a payment often required digging through multiple systems, reports, and raw data files. There was no one place to see how a transaction was initiated, where it was in the process, or whether it had successfully completed.

Payment visibility needed to be treated as a first-class part of the platform, not some sort of afterthought. That meant building a centralized, searchable record of all transaction activity to help users understand what happened, why it happened, and how to respond.

Default view shows recent transactions across companies

Users can search by company ID, Set ID, or FEIN

Users can switch between different milestone date types

Plenty of filter options to narrow down transaction results

Detailed transaction view supports both client and internal inquiries

Rather than relying on spreadsheets, ACH files, or engineering support to run database queries, Bank Ops users could now search a unified record of transactions, including key details like amount, source and destination accounts, and status.

Their jobs became significantly easier. They could trace transactions, quickly ID issues, and reduce the amount of manual investigation needed to understand what was happening or answer urgent questions from clients.

At the time, this visibility was only available internally. Clients themselves had no direct way to see or understand their payment activity, which meant these questions always had to be routed through support.

While Transaction Activity immediately improved how our internal teams handled these requests, it also served as a proving ground for something larger. By centralizing transaction data and validating it through internal workflows first, we were laying the foundation for eventually delivering that same level of visibility directly to clients as a self-service experience.

The Impact:
Creating a unified Money Movement Platform gave Paylocity a consistent and reliable foundation for how funds were handled across its ecosystem.

By centralizing payment functionality, we reduced duplication across services and enabled far more scalable workflows, all while improving accuracy, speed, visibility, and automation at the core of our business.

This also helped position Paylocity to scale its payment infrastructure and support new financial products without requiring each service to build its own money movement logic.