A single-location operator has a payroll problem that software solved years ago. A multi-entity operator has a different problem that mostly still gets solved by hand, on a Sunday, in a spreadsheet, by the owner or the bookkeeper, with a stack of printouts.
The reason is structural. Eight stores that are eight LLCs are eight employers. Every hour has to land on the right employer's books, every subtotal has to be per entity, and a person who covers a shift across town has just created a row in a second company's payroll. Nothing about that is exotic — it's just tedious in a way that's easy to get wrong, and wrong here means a misfiled wage expense.
What this is — and what it is not
Before anything else, be clear about the deliverable, because this is where expectations go sideways.
What we're describing — and what our payroll workbook feature does — produces a workbook. A real spreadsheet file, per week, with per-entity sections, hours, leave columns, riders and live subtotal formulas, that you download and hand to whoever runs payroll.
It is not a payroll processor. To be completely explicit:
- It does not file taxes — no federal, state or local filings, no W-2s, no 941s.
- It does not move money — no direct deposits, no tax withdrawals, no ACH of any kind.
- It does not replace your payroll provider, your CPA or your bookkeeper.
It replaces the four hours of retyping that happen before payroll gets run. If you were hoping for something that pays people, this isn't it, and you should go buy a payroll processor. If what actually hurts is assembling the numbers that go into one, read on.
Hours belong to the store where they were worked
Here's the mistake that seems reasonable and quietly corrupts everything: filing a person's hours under their home store.
Most systems have a notion of where someone "belongs" — a home location, a primary store, a department. That's useful for org charts and useless for payroll, because the entity that owes the wage is the entity whose counter the person stood behind. If a shift is covered at store B, store B's LLC owes those hours, regardless of the fact that the person's badge says store A.
We learned this the unglamorous way. An early version of our timesheet built its lookup keyed on the employee alone, so somebody who worked two stores had their entire week's schedule attached to their first row — and a store where they had never once clocked in showed sixteen hours of somebody else's work. The fix is to key everything by (employee, location) together and to file each punch under the location of the punch, not the location of the person. Stated that plainly it's obvious. It is also the single most common defect in hand-built multi-entity payroll sheets, because a human doing it by hand naturally organises by person.
"Is she salaried?" is the wrong question
This is the part that catches everyone, including us.
We originally stored a single pay kind per employee: hourly or salary. It's the obvious design and it's wrong, because in a multi-entity group a person can genuinely be salaried at one LLC and hourly at another. A manager might draw a weekly salary from the two stores she runs and pick up hourly shifts at a third when it's short-staffed. Those are different arrangements with different employers, and both are correct at the same time.
So the flag has to live on the pairing. The right question isn't "is this person salaried?" — it's "is this person salaried at this store?" Concretely: a per-(employee, store) profile row either carries a weekly salary figure or it doesn't. If it does, that store pays salary. If it doesn't, that store pays for punched hours.
Two consequences worth stating, because both are rules the sheet has to obey:
- A salary belongs only to the stores that have a salary arrangement. If you treat "salaried" as a global property, that salary duplicates into every entity the person touches and every LLC's subtotal is overstated. A salaried row with no arrangement at that store must be skipped entirely rather than carried along at zero.
- An hourly store's real punches still count. The flip side of the same bug: if you zero out someone's hours because they're "salaried," you erase the genuine hourly work they did at the third store. Zero the hours only on the rows where that store actually pays a salary.
For salary rows, the hours column is a convention question — ask your bookkeeper. Ours wanted a literal 0 on salary rows so nothing looks like it should be multiplied by a rate; a scheduled-hours figure is also defensible. Pick one, write it down, and make the sheet do it every week without anyone remembering.
If your group looks like this — several entities, shared staff, one person assembling it all by hand on a Sunday — book a demo and we'll build the sheet against your actual store list on the call.
Leave, loans, deductions and mileage
Hours are the loud part of payroll. The riders are where the corrections come from.
Leave columns get hand-filled, and that's fine. Vacation, sick, holiday, bereavement, paternity/maternity, and an "other" bucket with a reason. You could try to derive these from a time-off system, and for some operators that works. In practice, at a small multi-store group, leave gets decided in a conversation and recorded after the fact. So the honest design is: give each leave type its own column, per person per store per week, editable by the owner, and let it be blank when it's blank. A blank leave column that someone fills in on Friday beats an automated one that's confidently wrong. What matters is that the value lands in the workbook rather than on a sticky note.
Loans, deductions and mileage ride along per store. An advance repayment, a uniform deduction, a mileage reimbursement — each one attaches to a person at an entity, because that's the entity whose bank account it comes out of. Keep a balance on loans so the sheet can show what's left, and keep the note field next to it: "loan bal. after this week" is exactly the kind of thing that stops a payroll question turning into an email thread.
These all come from the same place the hours do — the time clock supplies punches per location, the per-store profile supplies the riders, and the workbook assembles them. If the punches aren't trustworthy, nothing downstream is; that's worth fixing first.
Highlight the rows that changed
Here's a small feature that saves more review time than anything else in the workbook: shade the whole row yellow when something about that person's pay changed this week.
A raise that took effect Wednesday. A pay change logged since the week started. A new note on their profile. Any leave hours at all. Those are precisely the rows where an error is plausible and where the bookkeeper's attention is worth spending. Everything else is last week's numbers with different hours — safe to scan.
Without the highlight, reviewing forty rows means reading forty rows, so nobody reads carefully and mistakes survive. With it, three rows are yellow and get real scrutiny. It also creates a useful paper trail: the week a rate changed is visibly the week a rate changed, six months later, in the file.
The related discipline is to keep a ledger of pay changes rather than overwriting a rate. If Tuesday's rate is simply replaced by Wednesday's, you can never reconstruct which rate applied to which hours, and you certainly can't answer "when did she go to $19?" Log every move with a date; the workbook can then highlight honestly instead of guessing.
Ship her sheet, not your system
The last principle is the one most software gets wrong, and it's a discipline rather than a feature.
Your bookkeeper has a workbook. It has her column order, her entity section headings, her subtotal rows, her entity numbers in the corner. She has used it for years, she can read it at a glance, and she catches errors in it because she knows what it's supposed to look like. Handing her a new portal with a new layout doesn't save her time — it costs her the fluency she already had, and you'll spend a month arbitrating between "the system says" and "my sheet says."
So generate her sheet. Match the column order. Match the section structure — and be prepared to support more than one, because some operators want it grouped by entity (all of store A's people, then store B's) and others want it grouped by person with their entities listed underneath. Keep the subtotals as live spreadsheet formulas, not baked-in numbers, so she can insert a row for the one thing the system didn't know about and the totals just follow. That last detail matters more than it sounds: the ability to override locally is what makes a generated file trustworthy rather than annoying.
Do that and the change you're proposing is small enough to actually happen: same sheet, same review habits, same payroll provider at the end of it — but assembled from real punches in a few seconds instead of retyped from printouts over an afternoon. That's the whole pitch, and it's deliberately narrow.
The wider context — scheduling, time clock, store scoping, who can see pay data — is on the workforce & store ops page, and there's a write-up of what this looks like across a multi-entity franchise group on our franchise workforce page. Workforce deployments are quoted per site and headcount rather than off the shelf, so there's no number to quote you here; the conversation starts with how many entities and how many people.