Automotive Repair Software: Estimates, Parts, and Approvals

An auto repair estimate is not a quote. A quote is a number you accept or reject once. An estimate is the opening bid in a negotiation that reopens every time a technician gets the car on a lift and finds something the initial inspection couldn't see. Generic invoicing or CRM software treats the estimate as a static document. Real repair shops treat it as a living record with a full history of what changed, who approved it, and how.

That mismatch is where most off-the-shelf shop management tools fail. They handle the happy path fine: write an estimate, customer signs, work happens, invoice matches estimate. The failure shows up on the supplement, the backordered part, the insurance adjuster who wants photos before approving a line item, and the customer who authorized brakes over the phone but never touched a signature pad. None of that is an edge case in this business. It's most of the volume.

We've built vision-model damage assessment with per-line confidence scoring for construction takeoff on BuildAEC, and the same structural problem shows up in a body shop: someone reads a physical or photographic input, produces a line-item estimate, and downstream systems need to know which lines are certain and which need a human to confirm before money moves. The domain details differ. The shape of the problem doesn't.

The estimate is a contract that reopens itself

A repair order needs to support amendments as first-class events, not edits that overwrite the original. When a tech finds a second bad CV joint mid-job, the system should create a new estimate version linked to the original, carry forward the approved lines, and flag only the delta for approval. If your data model stores the estimate as a single mutable row, you lose the one thing everyone downstream needs: proof of what was approved and when.

The practical rule: every estimate version gets its own row, its own timestamp, and its own approval record. The repair order points at the current version. Nothing is ever overwritten. This is the same discipline we'd apply to any subscription billing or usage metering system — the current state is a projection of an append-only history, not the history itself.

Parts move through three states before they're "in"

Generic inventory software has two states for a line item: in stock or not. A repair shop needs at least five, because a part on order is not a part in hand, and a part in hand is not a part that fits.

• Quoted — priced from a catalog or vendor API, not yet ordered.
• Ordered — a PO exists with a vendor, but no ETA guarantee.
• Backordered — vendor confirmed the delay; the repair timeline now depends on it.
• Received, unverified — the box arrived; nobody has confirmed it's the right part.
• Installed — used against the RO, cost now locked into the job's margin.

The state that generic software skips is "received, unverified." Wrong parts, wrong revisions, and core-charge mismatches all get caught here, and if your schema jumps straight from ordered to installed, the cost of a wrong part shows up as a mystery variance three weeks later instead of a five-minute fix at the counter. This is the same discipline we wrote about for manufacturing in our post on bills of materials: a part list is only as trustworthy as the state machine tracking what actually happened to each line, not what was planned.

The approval loop is the product, not a feature

Ask any shop owner what slows a car down and the answer is rarely labor. It's waiting on someone to say yes: the customer who doesn't pick up, the insurance adjuster reviewing a supplement, the fleet manager who needs three signatures before a $600 repair clears. The software's job is to make every approval fast, unambiguous, and provable after the fact.

A minimal approval record needs to answer four questions without anyone calling the shop to ask:

CREATE TABLE ro_approval (
  id           uuid PRIMARY KEY,
  ro_id        uuid NOT NULL REFERENCES repair_order(id),
  estimate_ver int  NOT NULL,
  amount_delta numeric(10,2) NOT NULL,
  method       text NOT NULL,      -- 'sms_link','signature','phone','portal'
  approved_by  text NOT NULL,      -- name or 'insurance:adjuster_id'
  approved_at  timestamptz NOT NULL,
  evidence_url text                -- signed link screenshot, recorded call, etc.
);

That evidence_url field is the one most systems leave out, and it's the one that ends the chargeback dispute six weeks later. If a customer approved a $400 brake job over a text link, you need the link, the timestamp, and the IP or device that clicked it, not just a boolean "approved" flag on the RO.

A decision rule worth building into the workflow: any estimate delta under a shop-configured threshold (say $150) can auto-notify without blocking work, while anything over it holds the RO in a pending state until an approval record exists. That threshold is a business decision, not a technical one, and it should live in shop settings, not in code.

Labor guides and insurance DRPs are read-only law

Labor time guides (Mitchell, MOTOR, CCC) set the hours a job is allowed to bill against an insurer, and Direct Repair Program agreements set the markup a shop can charge on parts and sublet work. Neither of these is something your software gets to interpret. They're external, versioned, and contractually binding. The software's job is to store the guide version used at estimate time and never silently re-price a job because the guide updated. If a supplement is written six weeks after the original estimate, it should use the guide version in effect on the supplement date, and the RO should record which version applied to which line.

Supplements

A supplement is an amendment to an already-approved estimate, usually because a tear-down revealed hidden damage. It needs its own approval loop, its own line-item history, and — for insurance work — a photo package tied to the specific damage that justifies the new charge. This is a smaller version of the same problem we solved with confidence-scored vision output on BuildAEC: the photo evidence and the dollar amount have to travel together, or the adjuster rejects the supplement and the car sits another week.

Reconciling the invoice against the estimate against the parts cost

By the time a car leaves, three numbers need to match or the shop is either losing margin silently or overbilling a customer: the final approved estimate total, the sum of installed parts at actual cost, and the invoice total charged. A checklist worth running before every RO closes:

• Every installed part has a cost that traces to a specific vendor invoice, not a catalog estimate.
• Every approved estimate delta has a matching approval record with evidence.
• Core charges and returns net out against the original part line, not a separate untracked adjustment.
• Labor hours billed don't exceed the guide-allowed hours for the RO's insurance program, or the excess is flagged as customer-pay.
• The final invoice total is the sum of the current estimate version, not a hand-typed number.

We've run this exact class of reconciliation — matching a per-tenant ledger against real transactions before anything is called closed — on offline-capable retail systems like Retailer OS, where a sale made without a signal has to reconcile cleanly once the connection returns. A repair order is the same problem with a longer approval chain in front of it.

Where generic field service or CRM software breaks

Most CRM and field-service platforms are built around a job that has one price, one approval, and one invoice. Bolting a multi-version estimate, a five-state parts pipeline, and an evidence-backed approval loop onto that model usually means fighting the vendor's data model at every step, or exporting to spreadsheets to track the parts, which defeats the point of buying software at all.

The honest tradeoff: if a shop only does simple, single-visit maintenance work with no insurance billing and no supplements, a generic invoicing tool is genuinely fine, and building or customizing anything more is wasted spend. The complexity described here earns its cost only once supplements, DRP billing, or multi-vendor parts sourcing are a regular part of the week. Below that line, an off-the-shelf tool will serve the shop better than a custom build.

An estimate is the opening bid in a negotiation that reopens every time a technician finds something the initial inspection couldn't see.

Past that line, the fix isn't more features bolted onto a generic CRM. It's a data model that treats estimates as versioned, parts as a state machine, and approvals as evidence, not booleans. We've built that kind of workflow across retail, construction, and several other domains where money can't move until a human or a rule says it's allowed to. If a shop or a platform serving shops is running into this wall, we're glad to talk through what it takes.