Auto repair invoice software: what the invoice has to contain

What auto repair invoice software has to produce

A generic invoicing app can print a document with a total on it. A shop invoice is a different artifact: it is itemized, it is regulated, and it is the document a customer reads when they are deciding whether to trust the shop with the next repair.

The regulation to design against is California’s, because it is unusually specific. CCR title 16 § 3356 requires an invoice to show the dealer’s registration number and the business name and address as they appear in the Bureau’s records, and to separately list and describe:

• all services and repairs performed, including diagnosis and warranty repairs, with the price for each;
• each part supplied, in a way the customer can understand, with a price for each part;
• the subtotal for all work performed;
• the subtotal for all parts supplied, not including sales tax;
• the applicable sales tax; and
• the total for work, parts and tax.

The same section requires the shop to give the customer a legible copy and to keep one. That is the shape the software has to produce, and it is worth noticing what it is not: a single “repair” line with a grand total is not an itemized invoice, and a parts column that says “transmission kit” without identifying the parts is not a description.

The lines that are not allowed

This is the part of the category almost nobody writes about, and it costs shops money. Subsection (g) of the same regulation prohibits separate billing for items “generically noted as shop supplies, miscellaneous parts, fees for electronic communication with the smog check database, and the like.” In California, a shop supplies line is not a small line item with a small margin — it is a prohibited charge.

Subsection (f) is the mirror image: if a part is to be charged for, it must be listed specifically as an item on the invoice, and if it is not listed, it is not regarded as a part and no separate charge may be made for it. Both rules point at the same design decision: an invoice line has to be a thing with a name, a quantity and a price.

The section also governs how a change in the job gets documented. Additional authorization obtained after the estimate — the classic “while you were in there you found X” — has to be recorded on the invoice if it was given orally or electronically, with the date and time, the name of the person who authorized it, how to reach them, and a description and price of the added parts and labor. If your shop is in the middle of a transmission job, that is the rule that decides whether the extra work is billable, and it is the same document trail the estimate depends on (auto repair estimate software covers the estimate side of it).

Labor, parts, tax and the two subtotals

Two subtotals are not a formatting preference; they are how a customer, an accountant and a tax auditor each read the bill. Labor and parts behave differently in almost every direction:

Software that collapses those into one number makes all four rows invisible. A customer who is told “the parts are $1,840 and the labor is $1,050” can ask a sensible question about either one. A customer looking at a single figure of $2,890 can only argue with the total.

Tax is the reason the subtotals have to be computed rather than typed. Whether a jurisdiction taxes labor or only parts changes the total on the same job, and the invoice is the record that has to match what was collected. Any tool whose tax field is a free-text box will eventually produce a bill that does not reconcile, and the shop eats the difference.

Warranty terms belong on the record, not in a folder

A repair warranty is a promise with a time limit and a mileage limit, and a transmission warranty is usually two promises at once: the shop’s workmanship warranty on the build and R&R, and the parts supplier’s warranty on a remanufactured unit or a converter. When a job comes back at eleven months, the first question is which promise applies and whether the customer is inside it.

That question is unanswerable if the warranty terms live only on a printed sheet in a paper file. The invoice record should carry:

• the warranty period in time and mileage, and the date the vehicle was released;
• whether the promise covers parts, labor or both;
• the unit or part identifiers the claim will be made against — serials and part numbers, not descriptions;
• the evidence behind the original conclusion, so a comeback can be evaluated against what was actually found the first time.

In BayStacker the invoice opens only after verification passes — the road test and code recheck — and a comeback reopens the work order it came from rather than starting a new job. That is the cheapest possible version of a warranty: the record that answers the claim already exists. The reasoning behind the gate is laid out on the transmission shop software page; the cost side of the same decision is in transmission rebuild vs. replace.

Getting paid without charging the customer twice

Payment handling is where a shop’s software most often embarrasses it in public. Three failure modes are worth testing for during a demo:

The double charge. A counter person taps “take payment,” the connection stalls, and they tap it again. If the payment endpoint is not idempotent, the customer is charged twice and the shop spends a week reversing it. BayStacker’s payments require an idempotency key, and a second request with the same key returns the first payment rather than creating a second one — the same design it applies to invoices, where a second press on the same work order returns the existing invoice.

The unknown rendered as success. Card processing fails in ways that leave the outcome genuinely unknown — a timeout, a dropped connection mid-authorization. Software that shows a green check for an unknown outcome is lying to the person at the counter, and the customer pays for that lie. An unknown payment should read as unknown, with a reconciliation step, not as a paid invoice.

The deposit that nobody can find. Transmission work commonly starts with a deposit and a parts order. The deposit has to land against the job, reduce the balance due, and survive the conversion from deposit to final invoice. If the deposit lives in a separate ledger that a human reconciles monthly, a job will eventually be invoiced as if the deposit never happened.

Around those three, the useful conveniences are ordinary: a payment link or text-to-pay so a customer can settle from the waiting room, a card reader or terminal for on-site payment, partial payments with a visible balance, and an import for the processor’s settlement file so the day’s takings can be matched against the day’s invoices rather than assumed.

Accounting sync: what the bookkeeper actually needs

“Integrates with QuickBooks” means different things. ALLDATA’s Manage Online, for example, publishes an integration set that includes QuickBooks alongside CARFAX, Worldpay, MechanicNet, Kukui and Demandforce. What matters is not the name on the integration page but the shape of the data that moves.

At a minimum, a month’s file should give your bookkeeper:

• Revenue split by category — labor, parts, sublet, fees — because parts revenue and labor revenue have different cost structures and different tax handling.
• Sales tax collected, by jurisdiction, if the shop sells across more than one.
• Payment processor fees, as their own expense line, not netted silently against revenue.
• Parts cost, so gross profit is computed rather than guessed. An incomplete cost must be reported as unavailable, never as zero: a job whose vendor invoice has not arrived is not a job with zero parts cost, and a report that says it is will make the shop look more profitable than it is.
• Core credits and warranty claims, tracked as receivables until the money arrives. A core on a bench is not a credit, and a warranty claim submitted is not a warranty claim paid.

If you do the books yourself, the same list applies in a smaller size: you want the export to match the invoices you issued, without you re-keying a single total.

Options compared

Prices were read from each vendor’s own site on 2026-09-23. Where a vendor publishes nothing, the honest answer is that you have to ask.

One note on reading that table: several products put invoicing behind a higher tier than estimating. If your shop issues fewer than a handful of invoices a week, paying for the top tier to get a payment link may be worse value than issuing the invoice in the shop system and taking payment on a terminal. If you issue several a day, the arithmetic flips, because the cost of re-keying invoices into a bookkeeping file is a person’s time.

What to do next

Take your last three invoices — one straight repair, one job with an additional authorization, and one warranty comeback — and ask each vendor to produce all three in the demo, with the tax computed rather than typed and the payment recorded once. That exercise will tell you more about a product than any feature list, because it is the only version of the test that matters: the documents your shop actually issues, with the awkward cases already on the page.