Body Shop Repair Order Job Costing from Vendor Invoices

Every repair order in a collision shop is a project. By the time the car leaves the lot, a single RO has accumulated cost from a long list of places — an OEM dealer parts counter, an aftermarket vendor like LKQ or Keystone or NPW, sometimes a salvage yard for a recycled bumper or quarter panel, a glass invoice from Safelite or a regional shop, a paint and materials draw against the monthly jobber statement on the shop's PPG or BASF or Sherwin-Williams or Axalta account, an alignment shop sublet, an ADAS calibration vendor whose invoice shares almost no vocabulary with the next vendor's, sometimes a tow-in, and the shop's own techs' refinish, metal, mechanical, and frame hours.

Body shop repair order job costing is the practice of consolidating every one of those costs against the RO that incurred them, on one workpaper, so the monthly P&L and the gross profit per RO read off the same data. According to BodyShop Business on the body shop P&L structure, the standard auto body shop P&L is broken into a minimum of six buckets: labor, parts, paint and materials, sublet, towing, and other. Per-RO consolidation is what makes both reads possible — the cost-line records that aggregate up to the six P&L buckets are the same records that aggregate down to gross profit on a single RO.

The reality on most shop bookkeeper desks at month-end is not that. Industry coverage has pegged roughly 90% of body shops as not reconciling parts invoices to vendor statements regularly, and the same shops typically lack a clean per-RO cost ledger to hand the carrier when a supplement gets short-paid or when an internal review needs to pin down where a job lost money. The data exists. It is sitting in a stack of vendor PDFs and scanned receipts on the desk, just not organised against the RO as the cost object.

What the Per-RO Cost Ledger Has to Carry

The workpaper is two related tables, not one flat list. The first table is the RO master, with one row per repair order. The second is the cost-line-detail table, with one row per cost record (a parts invoice line, a sublet invoice line, a labor entry for a tech-week-category combination), each pointing back to its RO by RO number. A bookkeeper can implement the pair as two sheets in one Excel workbook, as two structured tables, or as related tables in any other tool. The structure is what matters; the implementation is downstream.

The RO master table holds the RO header columns. At minimum:

RO number — the shop management system's RO identifier, the join key to every cost-line-detail record.
VIN and vehicle (year / make / model) — useful for matching glass and ADAS calibration invoices that key on VIN rather than RO number.
Customer — for customer-pay work, the customer name; for DRP work, the carrier name and the claim number.
DRP indicator and carrier — yes/no plus carrier name (State Farm Select Service, GEICO ARX, Allstate Good Hands Repair Network, Progressive Direct Repair, USAA STARS, Liberty Mutual Direct Repair, Farmers, Nationwide On Your Side). DRP work has a different reimbursement context and the indicator earns its column.
EOR amount — the carrier-approved estimate of record at the point the job was opened.
Supplement amounts — sup-1, sup-2, and a running supplement total. A four-supplement job is not unusual, so leave the column structure flexible (a supplements detail sub-table per RO is cleaner than ten supplement columns on the master).
Status — open, closed, pending parts, pending supplement, awaiting payment.
Open date and close / delivery date — both matter; close date drives the timing cut for the monthly P&L.

The cost-line-detail table is where the work happens. One row per cost record:

RO number — the foreign key back to the master.
Line type — parts, labor, P&M, sublet, towing, or other. This is the shop's internal categorisation of what kind of cost the line is.
P&L bucket — one of the six P&L buckets (labor, parts, paint and materials, sublet, towing, other). This is recorded as its own field rather than inferred from line type because P&M jobber draws and the sublet / towing split do not always follow mechanically from line type, and the sales-mix benchmarks only become readable when the bucket assignment is consistent.
Vendor name — the vendor as it appears on the invoice (the local Toyota dealer's parts department, LKQ, the salvage yard's name, Safelite Solutions Network, the PPG jobber, the alignment shop, the ADAS calibration vendor's company name, the tow company).
Vendor invoice ID — the invoice number as the vendor printed it.
Vendor invoice date — the date on the invoice itself, not the date it landed in the office.
Vendor line description — the vendor's own line text, kept as written so the cost-line-detail record cross-references cleanly to the source document.
Labor category — populated only for labor lines: refinish, metal, mechanical, or frame.
Amount — the line's dollar value.
RO line reference — a pointer back to the estimate or supplement line that triggered the cost. Where the shop management system carries an estimate-line number, use it. Where the linkage is freer, a short free-text reference (for example, "front bumper cover R&I") is enough.

Two design choices warrant attention. Separating line type from P&L bucket means glass can land in either the sublet bucket or its own bucket without rewriting line-type rules; jobber statement allocations land in P&M; tow charges stay separated from the broader sublet bucket. The roll-up at month-end becomes a group-by-and-sum with no translation layer. The second is cardinality: one vendor invoice does not always equal one cost-line-detail record. A single OEM dealer invoice often covers parts ordered for three different ROs that day, and the only clean way to capture it is as three cost-line-detail records, each with its share of the amount and each pointing at the right RO. A single RO, conversely, draws from many vendor invoices — an OEM panel line, an LKQ recycled component line, a counter ticket for fasteners, a paint draw allocated against the jobber statement. The schema holds them all as cost-line-detail records sharing the same RO number, with the right bucket and the right amount on each.

OEM Dealer and Aftermarket Parts Invoices

OEM dealer parts invoices arrive from the local franchised dealer parts department, usually for the make the shop ordered against — a Toyota dealer for a Camry job, a Ford dealer for an F-150, a Honda dealer for a CR-V. Document forms vary. The most common is a counter ticket per delivery, on paper or as a PDF emailed at end of day; a smaller share of dealers will email a per-invoice PDF; some still mail a weekly or monthly statement of all counter activity. The fields are consistent even when the layouts are not: dealer name, customer-account or parts-account number, an RO reference if the parts counter took it from the ordering tech, OEM part number, description, quantity, unit price, extended price, and a core charge where the part is core-eligible.

The matching key the bookkeeper relies on is the part number plus the RO reference, in that order. When the counter ticket carries the RO number cleanly, matching is a one-step lookup against the RO's parts list on the estimate. When it does not — and many counter tickets carry only a free-text customer reference like "for Smith job" or the ordering tech's first name — the bookkeeper falls back to matching by OEM part number, ordering date, and the tech who placed the order. That fallback works because the shop's parts orders for the day are bounded; reconciling four counter tickets against the parts orders three techs placed that morning is a bounded exercise even when the dealer's reference column is messy.

The cross-RO invoice problem shows up daily. The parts counter batches the day's orders into one ticket, prices it once, and sends a single document covering parts for two or three different ROs. Capturing it into the per-RO ledger means breaking it into multiple cost-line-detail records, one per RO, each carrying the part lines and the share of the invoice amount that belong to it. Line-level capture is what makes the split possible. A workflow that treats the dealer invoice as a single record keyed to one RO hides cost on the wrong job every time the counter batches.

Aftermarket invoices are usually cleaner. LKQ in particular runs an order portal where the body shop's parts orders carry a portal order ID through to the printable invoice, and the LKQ invoice itself is structured: header with the LKQ order number and the shop's reference, then line-level rows with the LKQ part number, the OEM part number being substituted, the Hollander interchange code where applicable, description, quantity, unit price, and extended price. Keystone, NPW, and Diamond Standard invoices follow similar patterns; most carry a usable order reference back to the originating shop request. Aftermarket matching is generally cleaner than OEM dealer matching because that order reference survives onto the invoice rather than ending up as free-text.

The cost-line-detail record needs to capture the parts category alongside the amount, because the parts gross margin (which most well-run body shops aim at roughly 40%) is read by category at the end of the month. The categories the bookkeeper records are the standard collision-shop set: OEM new from the dealer, Opt-OEM where the carrier specifies it, aftermarket (LKQ, Keystone, NPW, Diamond Standard), CAPA-certified where the part carries the certification, and recycled (covered separately in the next section because the document mechanics are different). Recording the category at the line level — rather than per RO or per vendor — is what lets parts gross margin be analysed per category without re-tagging months of historical data.

Cores show up as a small but persistent edge case. Refundable cores on parts like A/C compressors, alternators, starters, and certain steering and brake components appear as a positive line on the original invoice — the dealer charges the core deposit at sale — and a credit memo when the core returns to the dealer. The cost-line-detail table handles this with a negative-amount line referencing the original invoice and the same RO when the credit memo lands. The two records together net to the actual cost of the part minus the recovered core deposit. Skipping the core credit, or applying it to the wrong RO, is a common source of small ongoing parts-cost overstatement that the per-RO ledger cleans up.

The same vendor invoice stack also has to reconcile against the monthly statements that LKQ, Keystone, and the OEM dealer parts departments send out at month-end. The per-RO ledger this article is building is the demand-side workpaper — invoices to the RO that drew them. The supply-side workpaper, where the bookkeeper reconciles the same invoice stack against the monthly LKQ, Keystone, and OEM dealer parts statements, is the parallel exercise that catches dropped invoices, double-billed lines, and short shipments. The two workpapers feed each other: the per-RO ledger depends on the same invoice records that the vendor-statement reconciliation depends on, and a discrepancy on one shows up on the other.

Salvage and Recycled Parts Receipts

Recycled parts are the third parts category, and the document side of the workflow looks unlike the OEM dealer and aftermarket sides. A salvage yard does not run an order portal in the LKQ sense; what arrives in the body shop's email or in the parts driver's hand is variable in form. A printed receipt from the yard's counter. A PDF generated by whichever system the yard happens to run. A handwritten delivery note clipped to the part. For smaller transactions, sometimes only the email confirmation that quoted the price and stock number, with no separate receipt at all. The structural fields are similar across these forms; the templates are not.

The fields the bookkeeper has to capture from the salvage receipt are reasonably stable, even when the layouts are not:

Yard name — the salvage yard or recycler the part came from.
Yard receipt or stock number — the yard's internal identifier for the specific part. This is the yard's primary reference and how a follow-up call gets resolved.
Source VIN — the VIN of the donor vehicle the part was harvested from, when the yard provides it. Collision-grade salvage yards usually do; lower-tier yards sometimes do not.
Hollander interchange code — the cross-yard part-identification standard for recycled parts. Hollander interchange is what makes "a left front fender for a 2019 Camry" mean the same thing across yards.
Part description — what the part is, often with side and position (front / rear, left / right) included.
Condition or grade — many yards grade recycled parts (A, B, C grade for visual condition; sometimes a separate functional grade for operating components). Where the yard tracks it, the cost-line-detail record should carry it.
Price — the recycled part's price.
Core charge or core-tag obligation — where the recycled part is core-eligible, the yard either charges a core deposit at sale or applies a tag obligation requiring the damaged original to return for the credit to apply.

The matching logic against the RO works in a layered fallback. The strongest match is on Hollander interchange: the estimate's recycled-parts line will carry the Hollander code, and so will most yard receipts from established recyclers, so the lookup is unambiguous. When the yard receipt does not carry the Hollander code — the case for some smaller regional yards — the next match is on part description plus position (a left front fender on the estimate paired with a left front fender on the receipt). When neither is sufficient, the estimator's order note becomes the linkage: who at the shop ordered the part for which job, with the date corroborating.

The core-tag obligation needs explicit handling in the per-RO ledger. The damaged original component (a damaged radiator support, an A/C compressor, a structural crossmember) has to return to the yard with the tag for the credit to be honored, and many yards charge back a core if the tag does not return within a defined window. The cost-line-detail record carries a flag — core-tag pending, core-tag returned, core-tag credited — and the bookkeeper closes the credit out as a negative-amount line when the credit memo arrives, in the same pattern as the OEM core credits in the previous section. The flag matters because forgotten core tags are a small but real source of cost overstatement; they go un-credited, the cost-line-detail record stays at the gross figure, and the gross profit on that RO comes in lower than it should.

Regional yard reality complicates template-based document handling. Outside the LKQ network and the larger national recyclers, the small and mid-size regional yards each have their own document format, and a body shop dealing with even a handful of regional yards is dealing with several different layouts. Structured extraction by description and position handles this where per-yard templates do not — the receipt fields do not move predictably enough on the page for templates to be worth maintaining, but the conceptual fields (yard name, stock number, interchange where present, description, price, core obligation) are present on every receipt in some form.

Glass Invoices from Safelite and Regional Shops

Glass replacements on a collision RO are typically subbed out — most often to Safelite, sometimes to a regional glass specialist the shop has a relationship with. The Safelite Solutions Network produces a fairly standardised invoice: claim number, an RO reference where the body shop populated it on the work order, vehicle (VIN, year / make / model), the glass part installed (with the manufacturer designation where applicable — laminated windshield with rain sensor cutout, tempered side glass, back glass), labor charge, materials charge for urethane and moldings, any pre-scan and post-scan attachments where Safelite has performed them, and total. The matching key is usually the VIN plus the date plus the RO reference where the shop wrote it on the work order; with all three present the match is unambiguous.

Regional glass shops carry the same conceptual fields with looser layouts. The smaller regional outfits run their own invoicing, and the layout on the page moves around — the VIN is sometimes in the header, sometimes near the line items, the labor and materials split is sometimes itemised and sometimes a flat installation charge. The match logic does not change; the document-shape variability is what shifts. A bookkeeper who handles half a dozen regional glass shops over a year is handling half a dozen layouts, and the cost-line-detail record absorbs them on the same fields.

Pre-scan and post-scan documentation is where glass invoices touch the broader OEM repair procedures conversation. Many DRPs and a growing share of OEM repair procedures require pre- and post-scan documentation to accompany the glass replacement, because windshield replacements on most modern vehicles disturb the forward camera that lives behind the glass and that camera then needs ADAS calibration. The cost-line-detail record for the glass invoice should carry a pointer to wherever the pre/post-scan attachments live — folded into the same source-document linkage the rest of the schema uses — so the carrier or an internal auditor can find them when they look. In some workflows the scans come back as part of the Safelite invoice; in others, the calibration is a separate vendor charge that lands in the sublet bucket and is captured in the next section. Both patterns are common; the cost-line-detail records reflect whichever the shop's actual document flow produced.

In the bucket assignment, glass usually lands in the sublet bucket, treated as a sub-category of sublet at most shops. Higher-volume operations sometimes break out glass as its own bucket where the glass volume earns its own line. The schema handles either by recording the bucket explicitly on the cost-line-detail record. Make the mapping decision once at chart-of-accounts setup and keep it consistent through the year so the monthly roll-up reads the same way each month.

Allocating the Paint and Materials Jobber Statement Across ROs

Paint and materials cost arrives on the bookkeeper's desk in a different shape from anything else in the vendor stack. The shop's PPG, BASF, Sherwin-Williams Automotive Finishes, or Axalta jobber sends a single monthly statement listing the paint, primers, clears, hardeners, reducers, masking products, abrasives, and consumables drawn against the shop's account through the month. Some statements list the daily counter tickets in detail; some only summarise by product category and price band. Pricing reflects the shop's negotiated jobber rate — the shop is buying through a jobber distributor, not the OEM paint manufacturer directly — and a single month's statement at a busy shop can carry several hundred line items.

The structural problem is that the jobber statement does not arrive RO-tagged. The booth used a quart of basecoat on Tuesday afternoon for the Camry, another half-quart on Wednesday morning for the F-150, and the jobber statement at month-end shows the basecoat draws as inventory consumption against the shop's account, with no way to read which RO drew which quart. The per-RO ledger needs P&M cost attached to specific ROs, and the statement does not provide that mapping.

The two realistic ways to bridge that gap are an allocation pass at month-end or a per-RO P&M tracker maintained at the booth.

The allocation pass is what most shops actually do. Refinish labor hours captured per RO that month are the strongest predictor of P&M consumption — paint and materials use scales, with reasonable accuracy, against the time the painter spends on the job. The allocation logic is straightforward: total the month's jobber statement, total the month's refinish hours across all closed ROs, and allocate each RO's share of the jobber statement in proportion to its share of refinish hours. An RO that captured 12 of the month's 400 refinish hours absorbs 3% of the jobber statement amount. The product is one P&M cost-line-detail record per RO that received refinish work that month, with line type "P&M", P&L bucket "paint and materials", vendor field set to the jobber name, and vendor invoice ID set to the statement number.

The per-RO P&M tracker is the more accurate option and the higher-administrative-load one. Painters note products and quantities used against the RO at the booth — usually on a clipboard or a tablet — and the bookkeeper costs those records out against the jobber statement at month-end. The result is a per-RO P&M record that reflects actual consumption rather than a labor-hour proxy. Most shops do not maintain it. The administrative cost is real, the painter's time is the bottleneck, and the labor-hour-based allocation is accurate enough for the gross-profit-per-RO read most shops are after.

The industry benchmark worth holding in mind without re-deriving it is that paint and materials true cost typically runs 5–7% of revenue at well-run shops. Sanity-check the allocated month's P&M cost against this band. A month coming in at 9% or 10% points to paint waste, miscoded jobber statement lines, refinish-hour capture errors on the labor side, or a statement reconciliation problem. A month at 3% points the other way — an undercount, often because some jobber draws have been miscoded into another bucket. The per-RO ledger is what makes either reading visible at all, monthly and per RO, without sampling.

Sublet — Alignment, Towing, ADAS Calibration, and Mechanical

Sublet is the catch-all for work the shop directs against an RO but does not perform in-house. The category has grown meaningfully wider over the last several years as ADAS calibration became a routine line on collision repairs, and the document side has become correspondingly heterogeneous. Five sub-categories cover most of what shows up in the inbound stack: wheel alignment, ADAS calibration, towing and transport, mechanical sublet, and frame straightening sublet for shops without their own bench.

Alignment sublet is the most predictable. The local alignment specialist (sometimes a tire-and-alignment shop, sometimes a dedicated alignment and frame outfit) sends an invoice in the shop's own template, usually carrying a clear reference to the inbound vehicle — VIN, RO number where the body shop wrote it on the work order, sometimes both — plus the alignment service performed (four-wheel alignment, thrust alignment, alignment check), before-and-after readings as an attachment in some cases, the labor charge, and the total. Matching is usually unambiguous because the alignment is RO-specific, the timing is tight (alignments happen toward the end of the repair), and the vehicle reference is on the document.

ADAS calibration sublet is where the document heterogeneity gets serious. ADAS calibration vendor invoices have essentially no vocabulary standardisation. The same conceptual operation — a forward radar calibration, a surround-view camera calibration, a blind-spot module recalibration, a lane-departure camera realignment — gets written differently by every vendor. One industry sample tracking the line-item text strings on calibration invoices has counted over 12,000 distinct strings across the field, for a small number of underlying operations. A given calibration vendor in a given metro area might write "FCM static aim" while the next vendor over writes "front camera target setup" and the next writes "ADAS forward camera recal — static" for what is operationally the same procedure on the same model.

That heterogeneity is the practical reason per-vendor template matching does not hold up in this category. A new calibration vendor lands in the inbound stack every few months as the field expands, and a workflow that depends on a stable per-vendor template breaks every time. Structured extraction by description and operation — pulling vendor name, invoice ID, description text, RO or VIN reference, and amount from the document regardless of layout — is what handles the variability. The cost-line-detail record carries the vendor's own line text in the description field, which is what the carrier or an internal auditor will look at later, and the bucket assignment is sublet.

Towing and transport invoices are usually simple single-page documents tied to a specific RO — the inbound tow that brought the vehicle to the shop, occasionally a transport between facilities or to a sublet vendor. The fields are stable: tow company name, the vehicle, the date, the pickup and delivery points, the charge. The bucket is the towing bucket on the six-bucket P&L, separate from sublet. The separation matters at the roll-up because tow expense is one of the metrics the broader sublet bucket can mask — a month with rising tow expense reflects either inbound tow costs the shop is absorbing or transport between facilities, and the separated bucket keeps that read available.

Mechanical sublet covers engine, drivetrain, suspension component replacement, and electrical work the body shop does not perform itself, usually directed to an external mechanical shop or a specialist for the vehicle make. Frame straightening sublet, where applicable, follows the same pattern — a sublet shop's invoice tied to one RO, with the operation described and the time and charge captured. Both sit in the sublet bucket alongside alignment and ADAS calibration. The matching key stays consistent across the whole sublet category: vendor name, vendor invoice ID, vendor description, and the RO reference (or VIN, where the sublet vendor used VIN as the primary linkage).

A different category of automotive sublet — dealership-side fixed-ops sublet invoice processing for warranty and mechanical work — runs on a different vendor ecosystem under warranty reimbursement and OEM-mandated procedures, not carrier-reimbursed DRP work. The structural problem rhymes; the practical workflows do not.

In-House Labor by Category — Refinish, Metal, Mechanical, Frame

In-house labor is the cost side of what the shop's own techs put into each RO, and the four-way category split is what distinguishes collision-shop labor accounting from generic auto-repair shop accounting. Refinish is the painter's work — preparation, sealing, basecoat, clearcoat, color blending, anything done from the prep deck through the booth. Metal is the body tech's work — sheet-metal repair, panel R&I and replacement, body filler work, anything that is not structural frame work. Mechanical is the in-house mechanical tech's work where the shop carries one — engine, drivetrain, suspension, electrical operations performed in-house rather than subbed out. Frame is the structural tech's work on the frame bench, where the shop has one.

The split matters because the body shop P&L tracks revenue and cost per category. Door rate analysis (what the carrier is paying the shop per labor hour, by category), gross profit per category, and tech productivity per category are all per-category reads. A shop that captures only a flat "labor" total against each RO loses the ability to see whether the refinish department is profitable, whether the metal department is keeping up with its hours, whether the mechanical work is a cost center the shop should reconsider in-housing. The category split on the cost-line-detail record is what keeps those reads available.

The data source most shops work from is a tech paysheet or its electronic equivalent — printed from the shop management system at end of shift, exported from the tech-time module, or filled in by hand on paper paysheets at smaller shops. Whichever form it takes, the underlying record is the same: hours per RO per labor category per tech. The cost-line-detail capture pattern is one record per RO per labor category per pay period. A painter who put six hours of refinish on the Camry in the week becomes one cost-line-detail record: line type "labor", labor category "refinish", RO number set, vendor field carrying the tech's name (or simply "in-house labor — refinish"), amount = 6 × the painter's hourly cost rate.

Techs flexing across categories during a single shift is a normal pattern at smaller shops where the same person handles both metal and refinish on smaller jobs. The handling is straightforward: the tech logs time against each category separately on the paysheet, and the per-RO ledger reflects the split as separate cost-line-detail records. A four-hour shift split two hours metal and two hours refinish on one RO produces two cost-line-detail records, not one merged labor record.

The line worth drawing is around what the bookkeeper should not try to re-implement. CCC ONE Pay Workflow and Mitchell's pay-management module are mature, complex pieces of software that exist to handle tech-time entry, flag-rate vs hourly tracking, multipliers, productivity reporting, and payroll feeds. The per-RO ledger is not a replacement for either of them. Where the shop management system already produces a labor-by-category-by-RO export, the bookkeeper's job is to pull that export into the cost-line-detail table and align the categorisation; nothing more. Where the shop is still on paper paysheets, the bookkeeper enters the per-RO labor-by-category lines directly into the cost-line-detail table week by week. Either flow is workable; trying to rebuild the pay-management workflow inside Excel is not.

The amount on the cost-line-detail record uses the tech's hourly cost rate, not the door rate. The cost rate is wage plus burden — payroll taxes, workers' comp, benefits where applicable — and it is what hits the labor bucket on the cost side of the P&L. The door rate is what the carrier is paying the shop per labor hour, and it lives on the revenue side of the RO header (in the EOR amount and supplements, where the carrier-priced labor lines are aggregated). Conflating the two is the most common labor-accounting mistake at smaller shops; the per-RO ledger keeps them separated by design, with cost on the cost-line-detail record and revenue on the RO header. Cost minus revenue per RO gives gross profit per RO, and the same arithmetic at the bucket level gives gross profit per labor category at the monthly roll-up.

Rolling the Per-RO Ledger Up to the Six-Bucket P&L

By the time the cost-line-detail table is populated for the month, the body shop 6-bucket P&L from repair order data is one group-by away. Every cost-line-detail record carries an explicit P&L bucket — that field was the design choice in the schema section that pays off here — and summing the amounts grouped by bucket for ROs closed in the target month produces the cost side of the six-bucket P&L row.

The labor bucket aggregates every labor cost-line-detail record across all four labor categories. The parts bucket aggregates every parts record across OEM, Opt-OEM, aftermarket, CAPA-certified, and recycled. The paint and materials bucket aggregates the jobber-statement allocations from the P&M section — a number that should land in the 5–7%-of-revenue band most months. The sublet bucket aggregates alignment, ADAS calibration, mechanical sublet, frame sublet, and (for shops that keep glass in sublet rather than its own bucket) glass. The towing bucket aggregates the inbound tow and transport records as a separate line. The other bucket picks up whatever does not fit the first five — small vendor categories the shop deals with occasionally, miscellaneous shop supplies coded against ROs, anything the chart of accounts has flagged as miscellaneous.

The same per-RO ledger that produces the bucket roll-up also produces the gross-profit-per-RO read, because both views derive from the same records. At the RO level, revenue is the EOR amount plus accumulated supplements; cost is the sum of cost-line-detail amounts for that RO; the difference is gross profit on the job. The shop can see gross profit on every RO that closed in the month and identify the jobs that lost money, the jobs that ran above expected margin, and the carriers or vehicle classes where the shop is consistently coming in tight.

The industry sales-mix benchmark is worth holding in mind without re-deriving it. Well-run body shops typically run roughly 47% labor, 39% parts, 10% P&M, and 4% combined sublet, towing, and other on the revenue mix, and the parts gross margin target sits around 40%. Sanity-check the monthly roll-up against these bands month over month. A parts gross margin coming in at 25% instead of 40% points to pricing problems on the parts line of the estimate, missed core credits, or a parts-cost coding issue. A P&M bucket at 12% points to waste, allocation error, or a refinish-hour capture problem. The benchmarks are not gospel — every shop's mix differs by DRP composition, geographic market, and severity profile — but the band gives the bookkeeper a reference for whether the month's numbers warrant a closer look.

Most shops resolve the timing-cut question — which ROs land in which month — on close date, the day the vehicle is delivered. The schema's RO header status and close-date columns make the cut readable. ROs closed in April aggregate into April's roll-up; ROs still open at month-end stay out but can be reported separately as work-in-process for shops that watch WIP. Pick a timing convention once at chart-of-accounts setup and keep it consistent through the year; switching mid-year breaks the comparability of monthly numbers.

The cost-side discipline this section closes is the counterpart to the cash-side reconciliation on the other end of the carrier transaction. The same RO that carries cost on the per-RO ledger eventually receives a DRP carrier EFT remittance (or a customer-pay payment, or a deductible) on the revenue side, and the matching exercise — match DRP carrier EFT remittances back to the same repair orders on the cash side — closes the cash-side loop. The per-RO ledger this article builds is the cost half of that picture.

Tooling Paths — Excel, CCC ONE Workflow, Outsourced Bookkeeping, and Extraction-Augmented Spreadsheets

The schema and the vendor walkthroughs leave one open question: what does a body shop actually run this on. Four paths cover the realistic options.

Excel-only. Free, fully customisable, entirely under the bookkeeper's control. A disciplined bookkeeper at a small shop with low RO volume runs the workpaper in two sheets and keeps it accurate. The path breaks at higher invoice volumes. Re-keying every OEM dealer counter ticket, every LKQ portal export, every salvage receipt, every Safelite invoice, every line of the jobber statement, and every alignment and ADAS calibration sublet invoice eats more hours than a busy shop can afford, and accuracy degrades when the bookkeeper is pressured.

CCC ONE Workflow plus the QuickBooks integration. The platform-native path for shops already on CCC ONE estimating. The integration tier that connects CCC ONE to QuickBooks sits at roughly $600 per month and is gated above the entry CCC ONE tier. Honest version: for multi-location operations standardised on CCC across estimating and accounting, the integration earns its cost — data flows from estimate to RO to accounting without re-keying. For many small and mid-size shops, the monthly cost is hard to justify against the RO volume, particularly because the integration solves the estimate-to-accounting linkage but not the heterogeneous vendor invoice consolidation this article walks. Mitchell RepairCenter and Audatex Qapter occupy the same position on the estimating side; AutoLeap, Tekmetric, and Shop-Ware sit alongside in the broader shop-management market.

Outsourced bookkeeper. A reasonable fit for shops that do not want to run AP in-house. The outsourced bookkeeper does the same per-RO consolidation work, often in their own Excel template. The shop hands the data back in finished form rather than building it forward, which means the books get done but the cost-side detail is not always available in real time when a supplement gets short-paid or when an internal review needs to inspect a particular RO.

Structured-extraction-augmented spreadsheet. The fourth path replaces the re-keying that breaks the Excel-only path without adding the recurring cost of the platform-integration path. Each vendor PDF in the inbound stack — OEM dealer parts invoices, LKQ portal exports, salvage receipts, Safelite invoices, jobber monthly statements, alignment sublet invoices, ADAS calibration vendor invoices, towing receipts — runs through a structured-extraction tool that produces line-level structured data and lands in the cost-line-detail table directly. The bookkeeper still does the RO matching and the bucket assignment, because those are judgment calls. What disappears is the typing.

This is the path our own product is built for. Users extract body shop vendor invoices into a structured per-RO ledger by uploading the inbound vendor PDFs and writing a natural-language prompt that describes the fields to capture — vendor name, vendor invoice ID, vendor invoice date, line description, amount, RO or VIN reference where present, parts category for parts lines — and the result lands as a structured Excel, CSV, or JSON file the bookkeeper can paste straight into the cost-line-detail table. The interface is a single prompt field with a file upload area, the same interaction pattern as ChatGPT or Claude, with no per-vendor templates to configure and no rules engine to set up. Batches up to 6,000 files per session handle the heaviest month-end stack a multi-location shop runs into. Line-item extraction (one row per invoice line rather than one row per invoice) is what makes the cross-RO splitting workable: a dealer counter ticket covering parts for three ROs lands in the output as multiple rows the bookkeeper assigns across the three RO numbers. 50 free pages per month cover ongoing low-volume use as a permanent free allowance rather than a trial — enough for a bookkeeper to test the workflow on a representative week of invoices and keep using it month to month at low volumes without committing. The 12,000-distinct-string ADAS calibration reality from the sublet section is exactly the kind of variability the prompt-driven approach absorbs without per-vendor templates.

The franchised-dealer side of the automotive AP picture runs separately on a different vendor ecosystem under warranty reimbursement, walked in dealership accounts payable automation for the franchised-dealer side of the automotive AP picture.

Whichever path the shop runs, the structural choice is upstream of the tool choice. The schema (RO header plus cost-line-detail), the vendor-category logic, the labor-category split, and the six-bucket roll-up are what make per-RO job costing readable. The tool decides how much of the work is re-keying and how much is matching and judgment.