Your financial hub for quotes, invoices, and budgets.

Accounting is the landing page for Lavori's billing pipeline. Rather than a single ledger, it is a hub that gathers the financial parts of the app into one place: quotes you send to clients, invoices you bill against, budgets that plan project costs, the service library of reusable billable items, and a dedicated payroll workspace for admins.

Open it from the Accounting link in the sidebar. The page is team-scoped, so the activity and snapshots you see reflect the team currently selected in the top bar. Switch teams to see another team's financials.

At the top of the Accounting hub is an Accounting Activity chart that plots your billing work month by month. It reads the team's quotes, invoices, and budgets and groups them into the month each was created or issued, giving you a quick read on volume and momentum across the pipeline.

Each series is color-coded so the three families stay distinct: budgets, quotes, and invoices. Quotes and invoices are broken down further by stage so you can see how work moves from drafted to sent to closed.

• Budgets Made — budgets created in the month.
• Quotes Made, Quotes Sent, Quotes Accepted, and Quotes Denied — the volume of quotes and how they resolved.
• Invoices Sent and Invoices Paid — invoices that left draft, and those that have been paid.

Below the chart, the hub presents the main billing modules as cards. Clicking a card takes you straight into that area. These are the same tools documented under Billing; Accounting is simply the front door to them.

• Quotes — create and manage estimates for your clients, then move accepted ones forward.
• Invoices — bill clients and track payments against what you have sent.
• Budgets — plan project costs and track margins. This card appears only on plans that include budgeting.
• Service Library — manage the reusable billable items and services that feed quotes, invoices, and budgets.
• Payroll — close out a pay run: review contractor time, clear the exceptions blocking it, mark the whole run paid, and keep 1099 records. Organization admins only.

Organization admins get a Payroll tab: a close-out workspace built around one pay run at a time. Rather than a ledger you browse, it asks a single question — can this run be paid yet? — and shows exactly what is standing in the way. It has four views: Current run, Timesheets, People & rates, and 1099 & history.

Payroll is admin-only. Members do not see the tab, and contractors cannot reach it; they log and submit their own hours from the Crew Portal instead. Non-admins who try to open it are sent back to the Accounting hub. On mobile, Payroll is read-only: you can follow the current run and the run history, but paying and reopening happen on the web.

• Current run — the run itself, grouped by person rather than by entry. The header carries the run code, its status, the period with arrows to step to the neighbouring runs, the run total, and a bar splitting it into approved, awaiting, and unpayable. Expand a person to see their entries, then Approve their hours or Send them back with a reason. A rail alongside holds the close-out checklist and the exceptions blocking it.
• Timesheets — the review queue for individual entries. Filter by status (including Drafts) and by project and period; a strip at the top counts entries still sitting in draft and offers a Nudge to whoever owes them. Each row carries the reason it needs a look: the exception underneath the project name, and chips for "Differs from schedule" when the logged hours disagree with the shift, "Above role rate" when the rate beats the contractor's role rate, and "Sent back" for a rejected entry. Select rows and use the footer bar to Approve or Send back in bulk; an admin can also Fix a missing rate inline, or un-approve an entry that has not been paid yet. No one can approve their own time, and paid entries are locked.
• People & rates — every person and role that can be paid, with their hourly and day rates, what they are currently owed, and their paid-to-date for the calendar year. Edit a rate in place; anyone who worked a role with no rate on file is flagged with a Set rate button. Rate edits apply from here on: they never reprice hours that have already been logged, because each entry snapshots the rate it was worked at.
• 1099 & history — every run for the year with its period, status, crew, hours, total, and paid date, a CSV export of the year's payments, and a receipt for any individual run showing each person's amount, method, and the run's payment reference. Below that sits 1099 readiness: calendar-year paid-to-date per contractor, a Mark W-9 on file action with a received date you can edit or clear afterwards, and a flag once someone's payments reach the configured 1099 threshold.

A run covers one pay period and moves through three states. It is open while the period is still running, becomes in review once the period has ended, and becomes paid when you mark it paid. Periods are computed from the cadence and anchor date in Settings, so every run is the same shape; the arrows in the run header step between them, and Payroll opens on the most recent run that has not been paid.

Before a run can be paid it has to clear four gates, all checked on the server: the period has ended, everyone has submitted, exceptions are cleared, and everything is approved. The checklist in the rail shows which ones are met, and Mark run paid stays disabled with the outstanding blockers listed beneath it until they all are.

Marking a run paid is a single action for the whole run, not one payout per person. You give the paid date, the method, an optional payment reference such as a check number or ACH batch, and any notes; Lavori records one payment per person, stamps their approved hours as paid, and copies the reference onto each one so the run and your bank record match.

A run can be reopened if you paid it in error. Reopening requires a reason, voids the run's payments (the rows are kept for the trail), releases the hours back to approved, and returns the run to in review. It is refused if any of the run's paid time has already been imported into a budget, since that time is being billed on to a client.

Exceptions are the things that make a run unsafe to pay, computed on the server and grouped by person. There are six kinds.

• Needs a rate — the entry has no resolvable rate, so there is nothing to pay against until one is set on the shift or on the person's role.
• Two shifts in a day — the same person logged entries against two different shifts on the same date. Worth confirming both happened.
• Still in draft — someone has hours they have not submitted, so they are invisible to the review queue.
• No project — the entry is not costed to anything, so it cannot flow through to a budget.
• Crew without an account — an ended shift is assigned to someone with no portal account. Only users can be paid here, so the fix is on the schedule; this one is advisory and never blocks the run.
• Hours outside the late-entry window — hours were logged into pay periods that were paid more than 90 days ago, so they cannot join a run. Advisory too: fix them from the Timesheets queue.

Payroll's settings live behind the gear button in the run header rather than in a view of their own. They cover the pay period cadence (weekly, every two weeks, twice a month, or monthly), the anchor date periods step from, the 1099 threshold, and an optional Auto-approve schedule-matched time after N days.

Payroll is calculated from time entries, not entered by hand. When a confirmed, published shift ends, Lavori seeds a draft time entry for the contractor with the shift's rate snapshotted onto it. Hourly shifts contribute their span in hours times the rate; day-rate shifts contribute one entry per day at the day rate, so they add to the amount owed without adding hours. The rate is the one locked in when the shift was confirmed, falling back to the contractor's saved rate when none was snapshotted.

Only approved and paid entries count toward what a run will pay. Draft and submitted entries show as awaiting until an admin approves them. An entry with no resolvable rate raises the Needs a rate exception; set a rate on the shift or on the person's role in People & rates, and it fills in on the next read of the run.

Each entry also records where its rate came from — the shift, the person's role, or an admin's manual fix — so an expanded person in the run shows whether their pay was priced from the schedule or fell back to their profile.

Amount paid comes from the payments a run records when it is marked paid: one per person, each storing the amount, the paid date, the method, and the run's payment reference. Voided payments from a reopened run never count.

Settings can turn on Auto-approve schedule-matched time after N days: a submitted entry that came from the schedule, still matches its shift's hours, and has a resolved rate is approved automatically once it has sat for that many days, so an admin only needs to step in for entries that changed or were logged by hand.

Accounting does not store its own financial records. It is a view layer over the billing pipeline: quotes capture estimates, accepted quotes flow toward invoices, invoices and their payments record what is collected, and budgets plan and compare project costs. The service library supplies the line items they all draw from.

Payroll sits alongside that pipeline rather than inside it. It reads scheduling to learn what contractors are owed and keeps its own record of what each run paid, and approved time can be imported into a budget when you need to pass those costs through to a client. Keeping shifts confirmed and published is what keeps Payroll's runs accurate — and once a run's time has been imported into a budget, that run can no longer be reopened.