Which prices are historical, committed, or future?
List the actual pricebook versions and what each one represents. A historical code, accepted quote, and new price for future work can have different uses. Staff should not have to infer those uses from one current amount.
Use the selling hub to connect the map to the transition. The buyer needs usable pricing while understanding the work and promises already accepted. A sale clause saying software included does not explain how the relevant versions will be preserved.
A pricebook commitment map links each relevant job or code to its old scope, terms, approved changes, new mapping, invoice test, and open questions. It helps the team preserve meaning while implementing the accepted buyer pricing plan.
Which customer records establish the commitment?
Request the actual quote, acceptance, contract, approved changes, and relevant correspondence. Identify the version and date supporting the agreed work. An open-job report may show a current amount without explaining how it was accepted.
Separate proposed quotes from accepted commitments and completed jobs. Those categories can need different review. Do not invent customer acceptance from an active status or assume every quote has the same legal effect.
The sale preparation guide helps collect that evidence early. Counsel should assess the actual terms and proposed buyer path. The technical team should implement the accepted decision rather than decide it by selecting a new price field.
What does the California contract example establish?
California CSLB's home-improvement contract guidance describes written terms and approved written changes within its scope. Its guidance includes customer and contractor signatures for a price or scope change before that change.
Apply that example to the relevant California work and facts. It does not create one nationwide rule for every quote or commercial job. Other jurisdictions and actual agreements need their own review.
Use the example to ask which evidence supports the terms and later changes. A migrated amount is technical data. The team still needs to understand what the customer and contractor actually agreed and what the buyer is authorized to do.
How should product and workmanship promises be preserved?
Identify relevant product warranties, labor promises, service terms, and who made them. A code can refer to equipment and installation while a separate document describes the promise. Those records should not be reduced to one generic warranty field.
The FTC's federal warranty guide distinguishes consumer-product warranties from services-only warranties, with stated mixed goods and workmanship conditions. Apply that scope to the actual record and product. It does not decide every acquired service obligation.
Record who handles remaining claims and how staff find the accepted terms. A new pricebook entry should not silently replace the evidence of an older promise. Counsel and the deal team need to assess the actual obligations and sale treatment.
Which code differences should be tested?
Compare the old and new descriptions, units, included materials, labor scope, pricing basis, and relevant exclusions. A similar name may refer to a different task. The buyer needs the real mapping rather than a label-only match.
Ask which system fields preserve the historical code and which display the new one. Confirm the actual provider-supported process. This guide does not claim that a particular software product includes a migration feature or preserves every field automatically.
Choose samples that cover real differences. If different scope, unit, or price cases exist, test them for the relevant task. Do not invent a target exception or call every renamed code a defect.
How can report controls support the review?
ServiceTitan's report instructions describe filters, column choices, date behavior, and exports. Record those settings when a report supports the job and code review. A report's apparent total can change with its period or date basis.
Check whether the chosen report contains the relevant detail. An aggregate export may help reconcile amounts while omitting the evidence needed to trace a job. The team should understand what the actual output establishes and what it leaves out.
Use the seller-document guide to preserve reports with their scope. A filename saying final pricebook does not establish that it covers every accepted commitment or that all exceptions were resolved.
Which sequence makes migration acceptance meaningful?
Set the acceptance list before staff rely on the new prices. The buyer and seller should see how the technical map connects to existing terms. Keep future pricing decisions separate from the evidence for old work.
- Identify historical versions, accepted quotes, and approved changes.
- Review actual contract and promise questions with the deal team.
- Map old codes to new fields with differences and exclusions visible.
- Test authorized job and invoice samples against accepted terms.
- Record unresolved cases, owners, and accepted completion evidence.
Use a permitted test process without changing real customer commitments or sending invoices. A test can show how an approved plan behaves. It cannot supply the missing permission for an unapproved change.
How can a price difference be misread?
The following illustration assumes an accepted quote of $2,400 and a new pricebook entry of $2,700 for a similarly named job. Those invented figures show a review question. They are not target pricing, a benchmark, or evidence that the customer agreed to pay more.
| Illustrative record | Assumed amount | Meaning still to be checked |
|---|---|---|
| Accepted quote | $2,400 | Actual scope and approved changes |
| New pricebook entry | $2,700 | Future use, scope, and mapping |
| Displayed difference | $300 | Does not establish an approved customer change |
| Ready invoice amount | Not decided by subtraction | Requires the actual accepted terms and permitted workflow |
The arithmetic difference is $2,700 minus $2,400, or $300. It is not automatically added profit or earned revenue. A correct calculation does not establish customer acceptance, equivalent scope, or authority to change the invoice.
How should open exceptions affect dispatch?
Identify the jobs and tasks affected by each gap. A missing code map, unclear quote version, and disputed change can require different responses. A generic note saying price issue will not help a dispatcher choose the approved path.
Give staff the accepted price source and escalation contact. They should know which record controls the permitted task under the actual terms. Do not ask them to resolve legal scope by selecting the newest amount.
Keep any temporary process explicit. It should state who can act, what evidence supports the action, and when the exception will be reviewed. A workaround should not disappear into a permanent undocumented practice.
Who owns the evidence after closing?
Assign responsibility for historical versions, accepted job terms, changes, code maps, and claim records. The buyer may need access later when a customer questions an invoice or a prior promise. The actual terms and privacy controls should govern that access.
Confirm the provider and agency roles involved. A working system can still depend on a seller or third party for archived information. The buyer needs a supported retrieval path for the relevant records.
Record what is unavailable and how the parties will handle the limitation. Do not promise complete preserved history from an export or an account role change. Acceptance should describe the actual evidence and its scope.
What belongs in the final pricing handoff file?
Keep the version map, customer terms, approved changes, code differences, provider response, test results, exceptions, and responsible contacts together. State which future prices and existing commitments the accepted plan covers.
The sale process guide connects those findings to the wider transition. A useful file helps staff apply approved pricing and find the evidence for existing work. It does not assume that a sale or software update changes every customer obligation.