Between time-tracking and payroll, the integration is the product

Start at the failure, because the failure is the whole reason this product exists. A sync runs on Friday night. It pulls the week's hours from the time-tracking tool, maps them to people, and pushes them into payroll. One thing goes quietly wrong: an employee worked forty-six hours, and the six hours over forty should have been paid at time-and-a-half, but the sync treated all forty-six the same. Payroll runs. The deposit lands. On Monday the worker is short a day's overtime, the company has underpaid someone in a way the law has opinions about, and what looked like a tidy little integration is now a wage claim.

Nobody who buys software like this is buying "we copy hours into payroll." That sentence describes a script, and a script is not a business. What they are buying is the promise underneath it: the hours arrive correct, on time, and survive an audit. The two APIs at the ends of this — a time-tracking service like Clockify or Toggl on one side, a payroll service like Gusto or QuickBooks Payroll on the other — are the easy ends. Each has a clean quickstart and you can read from one and write to the other in an afternoon. The product is the part in the middle that the demo skips, because the demo is one clean week for one salaried person and the failure only shows up in the messy ones.

What actually sits between the two APIs

Lay the chain out end to end and most of it is not the integration. Hours come out of the tracker, often with a spreadsheet alongside for the people and adjustments that never made it into the tracker — a manual correction, a contractor on a different arrangement, a bonus someone typed into a cell. Those raw hours then have to be turned into pay, and that turning is where the work lives. Time gets rounded according to a rule. Hours past a threshold become overtime according to a law. Breaks are deducted or not, depending on jurisdiction. Paid leave is reconciled against accrued balances. Only after all of that does anything get written to payroll — and the write has to happen exactly once, no matter how many times the job runs.

That middle is unglamorous and it is the entire moat. The two integrations are commodities; anyone can read Toggl and write Gusto. What a competitor cannot copy by reading your API list is the accumulated pile of rules you've encoded: how this kind of business rounds, which overtime threshold applies in which state, how a particular client's leave policy interacts with a particular pay period. That pile grows every time a customer hits an edge you hadn't handled, and a year in it is the product. The plumbing was a week. The rules are the years.

The foundation it rides on

Strip the rules engine out for a moment and look at what carries it. Almost all of it is the boring half that has nothing to do with payroll specifically:

• Background jobs — the sync is scheduled, not interactive. It runs on a cadence, it has to retry cleanly when a provider is briefly down, and a half-finished run must never leave payroll in a partial state. This is a batch runner, and it's the spine of the whole thing.
• A log — when a finance owner asks "why was this person's overtime calculated that way," the answer has to be reconstructable months later. Every run records what it read, what rule it applied, and what it wrote. That record is the audit trail the customer is paying for.
• Accounts and auth — payroll is among the most sensitive data a company holds, so who can see and trigger a run is not a feature you add later; it's load-bearing from the first line.
• An admin — somewhere a human can see a run that paused on an exception, inspect the hours, and approve the correction before money moves.

That list is the point of this whole site, and it isn't hypothetical. Those exact services run in production today underneath CompanyGraph — a scheduled batch runner that does real work on a timer, a logger that records what each run did, an admin an operator actually uses, accounts behind all of it. A time-tracking-to-payroll product does not need any of that invented. It needs one new thing — the rules engine and the two integrations that feed it — dropped onto a foundation that already carries the scheduling, the logging, the access control, and the operator screen. To be exact about the boundary: CompanyGraph is evidence the foundation is real and running. It is not this product, and nobody has built this product. The foundation is the part that's checkable; the rules engine is the part you'd build.

What you own, and what stays with the providers

The same habit that helps with any idea like this applies sharply here: decide early what must be yours.

The time data and the payroll mechanics stay external. You are renting time-tracking from Clockify or Toggl and renting payroll-and-tax from Gusto or QuickBooks, and that is the right call — owning tax filing is a different and heavily regulated company you do not want to become. What must be local is the part in between: the computed pay for each person and period, the rule that produced it, and the record that the write happened. If the only place "this is what we decided to pay, and here is why" exists is split across two providers' dashboards, you don't have a product — you have a fragile relay between two systems that don't know about each other. Keep the computed result and its reasoning in your own store, and the providers become inputs and outputs you can reason about, reconcile, and if necessary swap.

There's a sharper way to see why the owned record is mandatory rather than merely tidy. The dangerous operation here is the write into payroll, and the property that keeps it safe is idempotence: running the same pay period twice must pay once, and a run that crashed halfway must be safe to run again without double-paying or under-paying. You cannot get that from the payroll API alone, because the API doesn't know your intent — it only knows what you sent it. Idempotence requires a record on your side that says "this period, for these people, has already been written," checked before every push. That record is the same independent ledger that reconciliation depends on when records cross from one system into another and have to be made to agree: a store of your own that external systems are checked against, so the truth has somewhere to live that isn't just whatever a provider last said.

The hard part, named plainly

Two risks, and neither is the integration.

Labor-law correctness, which varies by jurisdiction. Overtime thresholds, rounding rules, break deductions, minimum-wage interactions, paid-leave accrual — these differ by country, by state, sometimes by city, and they change. Getting them wrong is not a bug that annoys a user; it can underpay a real person and expose your customer to a claim. This is the part that does not yield to cleverness. It yields to carefully encoding rules, one jurisdiction at a time, and being honest about which ones you support. The accumulated set of correct rules is, again, the moat — and also the reason this is a serious undertaking rather than a weekend's wiring.

Secure payroll data. You are holding compensation, and a leak here is among the worst a small product can suffer. The access control and the audit log aren't polish; they're the price of being allowed in the building. This is precisely why riding a foundation where auth and logging already exist and have run in production matters more here than for a lighter idea — the secure handling is assumed, not bolted on at the end.

The verdict

This is a full SaaS and a stable niche — and what you are selling is correctness and trust, not plumbing. That's an unusually durable thing to sell, because correctness compounds: every edge case you handle correctly is one a competitor still has to discover and survive. The moat is the accumulated rules — the rounding logic, the jurisdiction-by-jurisdiction overtime handling, the idempotent sync that has never double-paid and never under-paid — not the two API connections everyone can make. A business where every employee is salaried, in one jurisdiction, with no overtime, doesn't have this pain and shouldn't buy this. The business with hourly workers, overtime, multiple states, and a Friday-night dread of getting payroll wrong has it every single pay period, and will keep paying to make the dread go away.

Which is what makes the bet worth placing only when the foundation is already there. The honest question was never "can I read a time API and write a payroll API" — you can, in a week. It's whether you can get the rules right for a real workforce before the edge cases pile up, and keep the write idempotent and the trail auditable while you do. That's the part that deserves your whole attention, and it's the same shape as the sibling product where reconciliation across disagreeing systems is the moat: the integrations are inputs, the owned logic is the business. If the boring half is already built, the part that's genuinely hard is the only part you have to build — and that's true only because the scheduling, the logging, the access control, and the admin were carried for you. From an empty repository, the rules engine is the same size and the foundation is added underneath it.

---

This rides on the scheduled jobs, logging, accounts, and admin a foundation already carries — so the only thing you build is the rules engine that makes the hours arrive right. If you've got a pointed version of an idea like this, that's exactly what one workflow is meant to prove.