Four times a repair-order number changes, and what to key on instead
In short
A repair-order number identifies a document at one store, not a job across time. It comes from a per-store sequence that eventually rolls over, it splits when work is divided by pay type, it gains a separate invoice number at close, and it is superseded when an order is voided and reinvoiced. Key on store code, order number, version and open date instead.
Key takeaways
- The number is issued from a per-store sequence, so 2 stores in one group will both hold order 48210.
- Splitting by pay type turns one visit into several numbered documents that each total differently.
- The invoice number is a separate identifier with a separate lifetime — store both, never one.
- A void-and-reinvoice supersedes the number, and the old one stays in history looking valid.
- Store code, order number, version and open date together survive all four events.
A repair-order number identifies a document at one store, not a job across time. Four ordinary events renumber, duplicate or supersede it during a normal order's life, and a fifth property — the sequence is issued per store and eventually rolls over — makes the same number appear twice in any dataset covering more than one rooftop. Key on store code plus order number plus version plus open date.
The format varies: a 6-digit sequence, an 8-digit sequence with a branch prefix, a sequence with a department letter. None of that is the problem. The problem is that the number is a document reference in an accounting system, and a document reference is allowed to be reissued.
What the number identifies at each stage of the order's life
| Stage | What exists | What the number is | What can still change |
|---|---|---|---|
| Estimate | A priced proposal, no work authorised | Often a separate estimate number; sometimes an order number reserved early | Everything — the estimate may never become an order |
| Open | An authorised order with customer, vehicle and at least one line | The working order number, printed on the write-up | Lines, pay types, advisor, technician, promise time |
| Split | Several documents, or one document with lines on different pay types | A suffix, or sibling numbers from the same sequence | Which lines sit where, so what each number totals |
| Closed | A posted document in the ledger | The order number plus an invoice or document number | Nothing, until somebody reopens it |
| Reopened | The same physical job, more work added | Same number, new version — or a new number referencing the first | Totals, hours, and which period the revenue lands in |
| Reinvoiced | A superseded document and its replacement | A new number; the old persists in history marked void | Which of the two your report counted |
The four events that break a stored number
- Split by pay type. One visit divided across customer pay, warranty and internal becomes 3 documents, or one document whose lines belong to different payers. Any report counting documents now counts one visit three times.
- Invoicing issues a second identifier. At close, the accounting side stamps an invoice or document number. That is the number on the customer's paperwork, so it is the number quoted back to you in a payment reference or a satisfaction survey — while your feed is keyed on the other one.
- Reopen and supplement. More work on the same visit produces version 2 of the same number. Overwrite on the number alone and the earlier state disappears; insert and you double the revenue. Only a version field distinguishes them.
- Void and reinvoice. A posting error is corrected by voiding the document and issuing a replacement. The void row usually stays in the data, and it looks exactly like a live order to anything that does not read status.
The fifth problem is not an event. Numbers come from a sequence held by each store — say it runs 100001 to 999999 — so two rooftops in one group will both hold order 48210, and a rolled-over sequence reissues it years later. Order 48210 opened in 2019 and order 48210 opened in 2026 are different orders. That collision is invisible at one store and fatal in a consolidated dataset; how store codes get applied across a group belongs to dealer group data and reporting.
The composite key that survives all four
What breaks downstream when only the number is stored
- Revenue is double counted or lost. A split visit inflates document counts; a reinvoice counts twice unless the void is read. The sales-side version of the argument is the CRM says sixty-two and the DMS says fifty-eight.
- Yesterday's totals move. A reopen restates a closed period, one of the legitimate reasons a feed disagrees with your copy of it — yesterday's export does not match today's copy separates that from your loader's own failures.
- Technician and advisor numbers halve. Hours booked against a superseded document do not follow the replacement unless something links them, so two half-jobs replace one whole one.
- The customer join goes wrong quietly. An order carries a customer reference that may not be the person the CRM holds, a larger problem set out in the DMS and the CRM each believe they own the customer.
- Automation acts on the wrong document. A status message or payment link keyed on the bare number can resolve to a void order — the identity discipline that decides whether automation can act at all, argued in AI in logistics operations.
An EV visit shows all of it at once: a diagnostic line, high-voltage work on a different pay type and an ADAS calibration that may be sublet will produce several numbers for one car on one day, which modelling an EV service visit end to end walks through. How many statuses an order should carry is a different question, living in repair orders and the shop floor.
An order number is a receipt reference. Treating it as an entity identifier is how one visit becomes three jobs and one job becomes none.
Getting the key right before anything is built on it is cheap; retrofitting it after a year of history is not. It is the first design decision in the automation work we scope under AI agents and automation. The rest of this silo sits under DMS, CRM and shop-system integration, inside our automotive work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Does a repair order number change?
Yes, in four ordinary ways: it splits when work is divided by pay type, it gains a separate invoice number at close, it takes a new version when the order is reopened, and it is superseded when a document is voided and reinvoiced. None are faults, and all break a system that stored the bare number.
What is the difference between an RO number and an invoice number?
The order number identifies the working document in the service system; the invoice number identifies the posted document in accounting. They are issued at different moments, and the invoice number is the one printed on the customer's paperwork. Store both.
Can the same repair order number appear twice?
Yes. The sequence is held per store, so two rooftops in one group will eventually issue the same number, and a sequence that rolls over reissues it at the same store years later. Including a store code and the open date in the key is what makes the collision harmless.
What should I key service records on when joining data across systems?
Use store code, order number, version and open date as the composite key, and hold the invoice number, VIN and customer reference as attributes. That combination survives splits, reopens, reinvoices and sequence rollover, which no single field in the feed does on its own.
- repair orders
- data modelling
- dms integration
- identifiers
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The DMS and the CRM each believe they own the customerSample twenty customers who both bought and serviced, and count how many link on an identifier both systems actually store. The failure rate tells you whether this is drift or a missing design.diagnostic
- The CRM says sixty-two, the DMS says fifty-eight, and the manager trusts neitherA 4-unit gap between two systems almost never means 4 lost records. Reconcile one month at record level into four buckets and the shape of the result names the cause before anyone has to argue about it.diagnostic
- The scheduled export: a snapshot of survivors, not a record of eventsA scheduled dealership export is a photograph of the rows that survived to the moment the job ran. That one property decides everything you can build on it, and everything you cannot.definition
- Yesterday's export does not match today's copy of yesterdayA figure that was right on Tuesday is different on Wednesday. Four things cause that, three of them at the vendor and one in your loader, and the only thing that separates them is the raw files themselves.diagnostic
- Data brokers in the dealership stack: who is actually sending you the fileBetween the dealership's system of record and your build sits a party with its own schema, its own cadence and an authorisation only the dealer can sign or revoke.definition
- The deal was voided in the DMS and it is still open in your appA voided deal or a deleted repair order never announces itself. It simply stops appearing in tonight's file, which looks identical to a truncated transfer — so the inference needs a health check before anyone trusts it.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation