Catch payroll errors before the next cycle.
The deduction stopped applying in August. Nobody looked until March.
Payroll runs on a schedule with almost no review between runs, so the errors that survive are the structural ones that repeat every cycle. Payroll flags the cycle and the employee class that changed, so a human reviews it while it is still two cycles of correction instead of twelve.
Thirteen real series, one employee class that breaks, detection computed live in your browser.
The problem
Nothing between runs is watching, and the errors compound on a timer.
A benefits deduction that stops applying to one employee class, an overtime rule that loses its threshold after a policy change, a work-location to tax-jurisdiction mapping that breaks after a system update. None of these throw an error. The register balances, the file transmits, and the same wrong number goes out on the next cycle and the one after that. Employees notice underpayment quickly and overpayment almost never, so the errors that survive are exactly the ones that get expensive: retroactive correction, amended filings, and a conversation with counsel.
The insight
A payroll error is a regime change, and regime changes have a date.
Payroll data looks noisy day to day and is extremely stable in its ratios. Benefits deduction rate, effective tax rate, overtime hours per employee, and gross-to-net for a given employee class sit in a tight band, and a configuration break moves the whole band at once, on one day, for one class. That is a changepoint, not an outlier, and it is detectable weeks before it shows up on any total, because a single class is a minority of the register and ordinary headcount growth moves the total more than the error does. To be explicit about what this is not: Payroll flags cycles and employee classes for human review. It does not make tax determinations, does not decide what any employee is owed, and does not discharge a payroll provider or an employer of any compliance obligation. Every finding is an instruction to go look at a carrier file, a rule, or a mapping, not a correction.
CUSUM on day-over-day percentage changes for sustained shifts, Bayesian Online Changepoint Detection (Adams & MacKay 2007) for abrupt breaks, and Benjamini-Hochberg FDR control across every metric × employee class pair, because a register with 12 classes and 8 ratios is 96 simultaneous tests and an uncorrected threshold would send a review request every run.
How it works
Four steps, no data science team
A per-cycle or daily accrual export from ADP, Paychex, Workday, Gusto, Rippling, or a warehouse table. Read-only. No write path into payroll, by design.
Benefits deduction rate, effective tax rate, overtime hours per employee, gross-to-net, employer contribution rate, and garnishment rate, sliced by employee class, work location, and pay group.
Each series runs CUSUM and BOCD. Whatever crosses is filtered by Benjamini-Hochberg across the whole register, so a review request means something rather than arriving every cycle.
The date, the class, the metric, the size of the shift, and the specific artifact to check. A human decides what happened and what is owed.
Who it is for
The payroll manager who signs off on the run
Payroll operations at mid-market companies, roughly 300 to 5,000 employees, where one or two people own the register and there is no time between runs to audit it. Also the PEOs and payroll bureaus that run this for dozens of clients and carry the error risk themselves.
Pricing
- –Full detection engine
- –12 months of history
- –Email review packet
- –One payroll source
- –Unlimited entities and pay groups
- –Per-class and per-jurisdiction slicing
- –Slack and ticket integrations
- –Cycle-over-cycle review log
- –SOC 2 report and DPA
- –Per-client workspaces
- –Cross-client detection tuning
- –Self-hosted option
- –SSO and full audit log
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| ADP / Workday native validations | Pre-run edits and balance checks inside the payroll platform. | Rule-based and mostly intra-cycle. A rule that is configured wrong passes its own validation every time, which is exactly how these errors survive. |
| PayrollOrg-style manual audit checklists | A periodic reconciliation a payroll team runs by hand, usually quarterly. | Correct and far too slow. Quarterly means six semi-monthly cycles of compounding before anyone looks, and it is done on totals where a single class disappears. |
| FloQast / Numeric | Close automation with reconciliation and variance checks on the GL. | Works at account grain in the ledger. Payroll errors live in per-class ratios that net out long before they reach a GL account. |
| Internal BI dashboards | A payroll cost dashboard someone built in Looker or Power BI. | Shows totals and trends. This entire product is the observation that the total is where the error hides. |
The honest failure mode: this sits next to a regulated process without being the system of record, so it has all of the diligence burden and none of the switching cost. A payroll platform can ship anomaly detection on data it already holds and be trusted with it faster than a third party can get through a security review. There is also a real liability boundary to hold. Payroll flags cycles and classes for human review; it does not make tax determinations, decide what anyone is owed, or replace a provider's compliance obligations, and any product in this space that lets that line blur once will not get a second chance with a payroll buyer.
Market
Priced against one correction, not against the payroll bill
A mid-market company with 2,000 employees pays a provider roughly $15 to $25 per employee per month. Nine hundred a month is under 3% of that line, and a single retroactive benefits correction across one employee class costs more in analyst hours than a year of it. Four thousand mid-market registers at the Operations tier is $43M ARR, and the bureau tier reaches hundreds of registers per contract.