Billing Recurring Service

Recurring service looks like a subscription, and most of the tooling for it comes from software subscriptions, but what's being sold is different. A software subscription sells access, which starts the moment the customer signs up and is the same every day. A service agreement sells visits: a first service that's bigger than the rest, then a visit every month or two, more often in the busy season and less in the quiet one, plus free return visits if the problem comes back. Billing has to follow the work, not the calendar alone, and it has to survive everything the work does: a first visit that never happens, a visit moved by a storm, a technician who couldn't get into the yard.

The Payments volume covers the rails: cards, ACH, stored credentials, disputes. This chapter is about the layer above them: what to bill, when, for how much, and what to do when it goes wrong.

What the Customer Agreed To#

The agreement (Service Agreements & Plans) fixes the commercial terms, and billing should read them, never re-derive them:

• An initial price, for the first service, which usually takes longer and covers more (an interior treatment, an inspection, installing equipment).
• A recurring price and its frequency: per service, monthly, every four weeks, quarterly or annually.
• A term: a fixed length in months, or a single service.
• Add-ons, each with its own initial and recurring price, and discounts, each with what they apply to.

Snapshot all of it onto the subscription when the agreement is signed. A price list that changes next season must not change what this customer pays; only a new agreement or a documented price change does.

The frequency is the real design choice, because it decides whether billing follows the visits or the calendar:

	Per service	Calendar (monthly, quarterly, annual)
Invoice when	Each visit is completed	On the billing day, every period
Amount	The visit's price	Fixed, whatever happened that period
Seasonal service	Bills more in summer, less in winter	Smooth: the same amount all year
Missed visit	Nothing billed until it happens	Billed anyway; the visit is owed
Customer sees	"I pay when you come"	"I pay a monthly fee"

Per-service billing is easy to explain and never bills for work not done. Calendar billing smooths cash flow for both sides and makes the price easier to compare, but it means the business owes visits the customer has already paid for, and a cancellation mid-season has to settle that difference. Many businesses offer both, plus an annual prepayment at a discount. Whichever you offer, the subscription records which model it uses and the billing engine treats them as different things, not as one with flags.

A useful derived number is contract value: the initial price plus the recurring price times the number of periods in the term. It's what sales teams are measured on (Sales Teams & Commissions), and it's only an estimate for per-service plans, where the number of visits isn't fixed.

Billing Starts When the Work Does#

Don't bill at signature. An agreement signed at the door is still inside its cancellation window (Consumer Protection), the first visit may not happen for days, and a meaningful share of sales cancel before it does. Billing for a service that never started produces refunds, disputes and angry calls.

Billing starts when the first service is completed. The completion event from the field (Proof of Service) is what creates the first invoice and starts the recurring cycle:

• At signature, save the payment method with the customer's consent to future charges (Stored Cards & Recurring Billing), create the billing customer and the subscription in a pending state, and charge nothing.
• At the initial service, create the initial invoice (initial price plus add-ons, less discounts, plus tax) and charge it, then anchor the recurring cycle.
• If the first visit never happens, the agreement is cancelled with nothing to refund.
• One-time services bill once at completion and close.
• Visits that bill nothing (a free return visit, a visit marked no-charge, a visit cancelled as not serviced) produce no invoice, and the billing system should know why, not just see silence.
• Duplicates get caught here. Two salespeople sell the same house, or a customer signs again without cancelling; when the first service completes, check for another active subscription at the same address for the same service, and resolve it before billing twice.

The Billing Day#

Monthly customers expect to be charged on the same day each month, and they'd like to choose it (the day after payday, the first of the month). Let them pick a day from 1 to 28. Every month has those days; a customer who picks the 31st is billed on a different day in half the months, which is how billing systems behave (Stripe bills a January 31 anchor on the last day of shorter months) and not what the customer thinks they chose.

The billing day is a local date, so anchor it in the service address's time zone, at an hour early in that local day. Billing engines store anchors as instants (Stripe's billing cycle anchor is a Unix timestamp, in UTC), and an anchor computed as midnight UTC lands on the previous evening for every customer in the Americas, so a customer who chose the 1st is billed on the 30th. Compute the instant from the local date and the zone, per Time.

Changing the billing day later re-anchors the cycle. Decide whether the gap is prorated or free, and say so to the customer before they confirm.

Per-Service Billing#

A per-service plan has no fixed cycle, so model it as usage: each completed, billable visit adds a line to an invoice, and the invoice is finalized and charged when the visit completes.

• One visit, one charge. The visit's identifier is the idempotency key for its invoice line, so a replayed completion event can't bill twice (Idempotency).
• Price from the subscription, not the visit: the technician's app doesn't decide what the visit costs.
• Corrections follow the visit. A completion that's reversed (marked complete by mistake, then cancelled) reverses its charge with a credit, as below.

Tax on Services#

Sales tax on services is decided state by state, service by service, and the answer is often yes. Texas, for example, requires providers of structural pest control to collect sales tax, on the total charge, even when no pests are found, and requires invoices that mix taxable and nontaxable services to state each separately. Ohio taxes a list of named services, including exterminating and landscaping and lawn care (with an exclusion for lawn care providers whose sales are under $5,000 a year). Other states tax few services or none, and whether a service is taxable can depend on details like whether a chemical was applied or what kind of property it was.

Don't encode this yourself:

• Use a tax engine (Avalara, Stripe Tax, Vertex) that computes tax from the service address and a tax code per product, and keep each service and add-on as its own line with its own code, so taxable and nontaxable charges are separated the way states require.
• Source by service address, not billing address. The tax belongs to where the work was done.
• Store exemptions (government, nonprofit, resale) with the certificate and its expiry on the customer.
• Store the computed tax on the invoice, with the engine's transaction reference, and never recompute a finalized invoice.

The engine needs the invoice before it can tax it, which creates a small ordering problem for the first charge: the amount isn't final until tax is added. One approach is to authorize the expected total when the invoice is created, wait a few minutes for tax to be applied, then capture the final amount; if the tax made it higher than the authorization, charge the difference as a second payment to the same method. Authorizations lapse, so the delay has to sit well inside the card brands' capture windows (Card Payments).

One Business, Several Merchant Accounts#

Field service companies often operate through separate legal entities by state or region, for licensing, insurance or tax reasons, and each entity needs its own merchant account (and sometimes its own processor account entirely). The same customer data model then lives in several payment accounts:

• Route by service address. The entity that does the work collects for it. Resolve the account from an explicit choice, then the service address, then a default, and record which one was used on every payment.
• Customers and payment methods exist per account. A card saved under one entity's account isn't usable by another's without copying it through the processor. A customer who moves across a state line, or buys service at a second property in another state, gets a second billing customer.
• Events arrive per account. Each processor account sends its own webhooks; label them with the account they came from before anything else reads them.
• Report across them. The business wants one balance per customer and one revenue number per region, rolled up from accounts that settle separately (Software Platforms covers the same pattern from the provider's side).

Applying Payments#

Customers don't pay invoices one by one. They pay a balance: an autopay charge, a check for "whatever I owe", a partial payment over the phone. So payments go to the account, and an allocation step applies them:

• Credit the payment to the customer's balance first, as a ledger entry (Payment States & Ledgers).
• Then pay open invoices oldest-due first, each in full. Paying invoices only in full keeps each invoice's status meaningful (paid or not), rather than a dozen invoices each partly paid.
• Leave the remainder as credit, applied automatically to the next invoice.
• Manual payments need limits. Staff recording a check, cash or an adjustment can move a customer's balance with a keystroke; cap the amount without approval, require a reason, and reconcile manual payments against the bank deposit (Accepting Checks).

Corrections: Credits, Reversals and Refunds#

A finalized invoice is a record of what was billed, and it doesn't change. Corrections are new records:

• A credit note reduces what an invoice asks for, for an overcharge, a missed add-on, a goodwill credit after a complaint or a damage claim. Against a paid invoice, the credit goes back to the payment method as a refund or onto the customer's balance.
• Void and reissue when an invoice was wrong from the start. Voiding keeps it on record as zero-value and terminal; the corrected invoice replaces it.
• A payment that comes back after the invoice was paid (an ACH return, a bounced check, a payment taken on a fallback processor that reversed) has to put the debt back. Some billing systems can't reopen a paid invoice, so the pattern is a credit note against the original, a replacement open invoice with the same lines, and the original marked as returned rather than deleted, so the history still shows what happened (ACH & Bank Transfers).
• Refunds carry a reason (duplicate, customer request, fraudulent, service not performed) that feeds reporting, and refunds above a threshold need approval.

Coupons and promotions are part of the same system. A coupon is reserved at the sale and redeemed when it's applied to an invoice, its scope says whether it applies to the initial invoice, the recurring ones or both, and who can apply which coupons is a permission, because a discount is a cost someone has to own.

Upgrades, Add-Ons and Price Changes#

The subscription changes after the sale more often than the sale itself suggests. A technician sells an add-on at the door, a customer upgrades to a bigger plan after a bad month, the business raises prices for the new season.

• An upgrade is a new agreement, signed, with its own terms. Link the new subscription to the one it replaces, carry over the billing day so the customer isn't billed twice in one month, and end the old one at the moment the new one starts, with any overlap credited.
• An add-on can be a new line on the existing subscription if the agreement allows it, with its own initial charge billed at the visit where it's first performed.
• A price change follows the agreement. The agreement says whether and how prices can change during the term; the billing system applies the change from a stated date, tells the customer before it takes effect, and records which notice was sent. Never change a recurring price by editing it in place: schedule the new price with an effective date, so invoices before and after both explain themselves.
• Credit the right people. Upgrades and add-ons sold in the field often pay the technician or salesperson, usually once the upgraded service is actually performed, so the billing events that confirm it are inputs to commissions (Sales Teams & Commissions).

Revenue Numbers#

Finance will ask for monthly recurring revenue (MRR) and its annual equivalent (ARR). Compute them from active subscriptions with every frequency normalized to a monthly amount (a quarterly price divided by three, an annual by twelve), and say what's excluded: frozen subscriptions, subscriptions scheduled to cancel, and per-service plans, which have no fixed cadence and are better estimated from their visit schedules than pretended into a monthly figure. Say too whether the numbers are gross or net of discounts. Accounting is a separate question: a prepaid annual plan is cash today and earned as the visits happen, and how that's recognized is a decision for your accountants. Give them the ledger and the visit history they need to make it.

The receivables report ties billing to Collections & Retention: open balances by age, failed payments, refunds and write-offs, by service center and region.

What This Means for the System You Build#

• Commercial terms snapshotted at signature, with the billing model (per service or calendar) as a first-class choice.
• No charge before the first service; its completion creates the initial invoice and anchors the cycle.
• Billing days from 1 to 28, anchored in the service address's local time.
• Per-visit invoice lines keyed by the visit, so completions can't double-bill.
• Tax from an engine, per product tax code, sourced by service address, stored on the invoice.
• Merchant accounts per legal entity, chosen by service address and recorded on every payment.
• Payments to the balance, applied oldest-first in full, with limits on manual payments.
• Corrections as credit notes, voids and replacement invoices, never edits.

References#

Specifications

• Texas Comptroller: Pest Control Services (Publication 94-114), structural pest control taxable even when no pests are found, and taxable and nontaxable charges stated separately
• Ohio Revised Code 5739.01, exterminating and landscaping and lawn care among taxable services, and the $5,000 exclusion for lawn care providers

In practice

• Stripe: Set the subscription billing renewal date, billing cycle anchors as UTC timestamps and month-end anchors billing on the last day of shorter months
• Stripe: How invoicing works, invoice statuses, voiding as terminal, and credit notes against open, paid or uncollectible invoices