Invoicing & Payments

Most invoices are never typed from scratch — they're generated for you, and land in Draft waiting for a look before they go out. There are three sources:

1. A completed visit, on a job with no contract. Marking a job visit complete drafts an invoice automatically — one line item per service on that visit (falling back to a single line from the job's flat rate if it has no services broken out). Recurring, package, and project jobs can rack up many visits, so each one gets its own invoice. One-time and waiting-list jobs are guarded so a job whose services were split across several visits doesn't get double-billed once the whole job closes. The invoice description follows a fallback chain: the visit's own override, then the job-level override, then the service's own invoice description, then the plain service name.
   Materials ride along too. Any Product added to the job that's still Pending, or that a crew already marked Used in the field (inventory decremented, but not yet billed), gets swept onto this same invoice as its own line and flipped to Invoiced so a later visit on the same job can't bill it again. A product marked Used, not billed is deliberately skipped — that status exists for materials the crew used but shouldn't be charged for.
2. A contract's billing cycle. Any job linked to a contract is billed on that contract's schedule instead — visit completion never invoices it directly. A daily cron job checks every active contract with auto-generate on, and creates that month's invoice on its configured billing_day_of_month (clamped to the last day of a shorter month). A contract can also bill a month in advance, which shifts the invoice's dated month forward by one. The amount comes from that contract's per-month override if one is set, otherwise its flat monthly amount. This is idempotent — it checks for an existing invoice on that contract for the billing month before creating another.
3. Manual creation. You can always build one by hand from Accounting → Invoices, independent of any job or contract.

When a completed visit drafts an invoice, each line item carries a taxable flag and the invoice picks a tax rate, so the tax the client agreed to on the estimate is the tax that shows up on the bill:

• Which lines are taxable. A job's services are taxable or not according to the service catalog — unless the job was converted from an estimate, in which case they follow the estimate: services converted from an estimate that carried sales tax are taxable, and services from an untaxed estimate are not.
• Which rate applies. A job converted from an estimate uses that estimate's tax rate. Any other job uses the client's default tax rate. Tax is computed on the taxable lines only.
• Appending visits to an open draft. If a client is billed monthly and a second completed visit lands on an already-open draft, the draft's tax is recomputed from all of its taxable lines at the invoice's rate — the appended visit is taxed too, not just the first one.

• No blank line items. An invoice can't be saved with only empty lines — Save is refused with "Add at least one line item with a description or amount before saving this invoice." Every line that's kept needs a description or an amount; rows you added and left blank are dropped.
• Abandoned new invoices don't linger. Opening New Invoice creates a draft immediately so you can start adding lines; if you close the sheet without saving anything, that empty draft is removed rather than left on the client's Uninvoiced list.
• Undeliverable email addresses. If the mail provider rejects the client's address when you email an invoice (a malformed or unroutable address, a rate limit, a provider outage), the error you see is the provider's own reason — not a generic "failed to send" — so you can tell a typo in the client record apart from a problem on the sending side.
• The manual Invoice buttons won't double-bill. The dispatch board's per-visit popup and the job detail page's Invoice button both check for an existing invoice first — a visit or job that's already been invoiced shows View Invoice #N instead and takes you straight there rather than creating a second, duplicate draft.
• Products need a Service first. Adding a Product to a job requires picking which of the job's Services it belongs to — the same rule Estimates already follow. Add Product is disabled (with a hint) until the job has at least one Service on it.
• Invoice and estimate email templates live in Documents, not a dedicated Email Templates settings page — Settings still has an Email Templates panel, but it's now just a pointer card to Documents, where invoice, estimate, client, and chemical-notice templates are all built with the same block editor.
• Printing several invoices at once produces one PDF. Selecting multiple rows on the Invoices list and choosing Print Selected combines them into a single multi-page PDF in one tab — it no longer opens a separate print popup per invoice (the same change applies to Estimates' own Print Selected).

Five statuses form a straight line; two more are side states that sit outside it — they describe an invoice's condition rather than a step it passes through.

Draft → Sent → Viewed → Partial → Paid is the path a normal invoice walks. Overdue and Void can layer on top of (or, for Void, replace) wherever an invoice sits in that line — Draft, Paid, and Void invoices are never shown as Overdue no matter how old their due date gets.

A payment is its own record — not a field on the invoice — so one payment can be split across multiple invoices for the same client in a single entry (useful when a client pays one check against several open invoices at once). Each payment stores a method:

What counts as "collected." Payment reports and every "Collected" or "Payments" figure (Payment Audit Summary, Invoices and Payments, P&L Cash Basis, the Cash Collected KPI, dashboard gauges) count only cash payments: an AR Write-off zeroes a balance without money changing hands, so it is excluded, and so are account credits applied from a previous overpayment. Amounts are also net of refunds — a $500 card payment refunded $100 counts as $400 collected. In the Custom Analysis builder the Payments dataset exposes this as the Cash Received, Account Credit, and Net Amount (after refunds) columns.

A payment can only be applied to an issued invoice. Draft invoices are still uninvoiced work and Void invoices are dead, so neither appears in the allocation list — send or print the draft first, then apply the payment.

Overpayments never push an invoice negative. A payment applies to an invoice only up to that invoice's remaining balance; anything beyond it stays on the payment as unused credit. If you type more than the balance into an allocation box it's capped on the spot ("Capped at this invoice's balance — the rest stays as unused credit"). An $80 check against a $55 invoice marks the invoice Paid at $55 and leaves $25 unused; that $25 shows up on the client as Credits and can be applied to a later invoice — it isn't lost and it isn't reported as "Paid −$80." The same limits are enforced on the server: an invoice can never be allocated more than its total, and a payment can never allocate more than its own amount.

Writing off a balance. The invoice's Enter Payment dialog offers AR Write-off (non-cash) alongside the real payment methods. A write-off is capped at the invoice's balance ("A write-off can't exceed the invoice balance") and, because no money changed hands, is excluded from every cash collected figure — see "What counts as collected" above.

Typing amounts. Currency fields — payment allocations, contract amounts, employee rates — keep exactly what you type while you're in the field and format it (e.g. 55 → $55.00) when you leave it. Nothing is reformatted mid-keystroke, so "55" can't turn into $5.01 on the way in.

Applying (or un-applying, if a payment gets edited) an allocation goes through a single database function that locks the invoice row, recomputes its balance, and derives the new status in one atomic step — so two payments landing on the same invoice at nearly the same moment can't silently overwrite each other's balance update.

An invoice for a fall cleanup goes out at a $500.00 total.

1. Invoice sent: total $500.00, amount paid $0.00, balance $500.00 — status Sent (or Overdue, once its due date passes unpaid).
2. Client pays $200.00 by check. You record a $200.00 payment allocated to this invoice. Amount paid becomes $200.00, balance becomes $300.00 — since the balance is still above $0.00, status flips to Partial.
3. Client pays the remaining $300.00. Amount paid reaches $500.00, balance hits $0.00 — status flips to Paid.

If the client had instead underpaid — say $220.00 against that $300.00 remaining balance — the invoice would stay Partial at an $80.00 balance; a later short payment doesn't skip straight to Paid just because a lot has accumulated. Only a balance that reaches exactly $0.00 (or is written off, or the invoice is voided) closes it out.

And if the client overpaid — a $350.00 check against that $300.00 balance — the invoice takes $300.00 and flips to Paid; the extra $50.00 stays on the payment as unused credit, listed under the client's Credits until you apply it to the next invoice.

You don't have to remember it's there. Any issued invoice with a balance shows a prompt when that client has unapplied money on them — an overpayment, a prepayment, or a deposit taken when they accepted a proposal — with an Apply to this invoice button. It uses the oldest money first and never applies more than the invoice still owes, leaving any remainder for next time.

Example. A commercial property manager emails: “please put PO# 4521 on the invoice, our AP system needs it to pay you.” That's their own internal purchasing reference, not anything from your side. You:

1. Open the invoice, edit the PO Number field, and type 4521.
2. It prints on the invoice PDF (labeled “PO Number” / “PO #” depending on the PDF template) so their AP department can match it against their own system.
3. Nothing else happens — no requisition, purchase order, or vendor record is created or touched. A job or contract can also carry its own po_number, which flows onto invoices generated from it the same way.

If you actually want to know what a job or project cost you in vendor materials — reconciling against real Equipt/PO purchase orders, not a client's AP reference — that's a different mechanism entirely: assign the PO line item's Project field to the matching CRM Project, rather than trying to tie a line item to a specific job or invoice. Cost tracking rolls up at the project level, so that's where to look to see what a project actually cost in purchased materials — not on the invoice.

Collecting payment straight from the invoice — a saved card or bank account, Autopay, bulk “Charge All” runs, processing fees — is its own workflow, covered in full in the in-app Online Payments (Stripe) documentation. Short version: connect a Stripe Standard account under Settings → Card Payments, save a card or ACH bank account per client, and charge it via “Charge Saved” or a fresh entry. Autopay is a separate toggle from simply having a saved payment method on file. A processing fee is added automatically to card charges (not ACH) and can be waived or overridden per charge; fees post to the P&L as “Credit card processing fees” income.

See the Support / Docs section in-app for the full walkthrough.

Snow jobs don't go through any of the flow on this page — no auto-invoice on visit completion, no contract billing cycle. Snow is billed through its own dedicated flow at CRM → Accounting → Snow Invoicing, built around per-inch and per-hour storm rates instead of flat job/service pricing.

See the Snow Invoicing guide for the full walkthrough — this page won't re-cover it.