The scope PDF is not the estimate: it is the record
An insurance carrier scope arrives as a PDF: pages of line items, quantities, descriptions, and unit prices approved after a claim. That PDF is the authoritative record of what the carrier accepted. It is also frozen - you cannot filter it, sort it by trade, or pull a single line out to discuss it with an adjuster.
The estimate you actually build on lives in Xactimate, where line items carry product codes, quantities, and prices in a structure the software understands. The bridge between the carrier record and your working estimate is conversion: turning the scope PDF into a native .esx file. If the conversion is honest, the file you export still says exactly what the PDF said - it just becomes something you can actually use.
Something else separates the two: structure. A PDF is laid out for reading - pages, columns, and totals at the end. An estimate is laid out for work - codes in the right fields, quantities counted, prices attached to lines. When a scope stays a PDF, everyone works from printed pages. When it becomes a .esx, the same content becomes the thing Xactimate can open, sort, and build on.
What conversion really does with your prices
The most important thing about converting a scope is what happens to the money. In ESXPress, the PDF price is the source of truth: every line carries the unit price from the customer's own PDF. If a product code is not recognized, the PDF price is kept and the line is flagged - the total never silently changes.
Measured across 289 real claim files and 7,525 line items, 2,756 line items (36.6%) carry a code our catalog recognizes. The rest keep their PDF price. The median estimate file moves 17% of its lines, and 39 files move none. For a typical scope that means most lines arrive exactly as the PDF printed them - which is what a carrier record should look like after an honest conversion.
Those numbers are measured, not claimed. They are also why the flags matter. A flagged line tells you the code was not matched, so the price you are looking at is the PDF price and the call on that line is yours to make.
There is no mystery to that behavior because it is deliberate. The converter is built to reproduce the document, not to replace it. What the PDF says is what the file carries, and where the file cannot match a code it says so instead of guessing.
Why the exported file asks Xactimate to reprice
Many exported estimates carry a price-list name, a tax block, and minimums baked in - a price identity that came from somewhere else. The exported ESXPress file carries none of it. No price-list name, no tax block, no minimums. Xactimate's receiver applies its own price list when importing.
A real import test in Xactimate confirmed the file opens clean, and the software asked the operator to reprice - which is the desired result. The reprice request is the design, not a defect: your chosen price list does the pricing, instead of a list a converter stamped in without knowing your market.
That distinction matters when you price work. Your business has its own list, your state has its own taxes, and your jobs have their own minimums. If a converter stamps an identity in, you are either fighting it or silently pricing against numbers that came from a list you never chose. With no identity in the file, the estimate stays yours to price, and the PDF prices stay visible underneath.
What the bridge unlocks once the estimate is in Xactimate
With the scope as a native .esx, the estimate stops being a page-by-page read. You can open it in Xactimate, sort line items, group them by category, and compare what the carrier wrote next to your own numbers. The code dictionary supports that work: 1,480+ dedicated Xactimate code pages, each with a description, category, and related links, plus a free code search.
When a scope includes floor plans, the same bridge extends to sketches. Floor plans in a scope PDF can be exported as Xactimate-ready .skx sketch files - one per floor page, or a zip. The first export builds the rooms in a few minutes; later exports are fast. Every sketch export goes through the same pipeline as production, and an automated upload-to-convert-to-download smoke test runs every 30 minutes.
The free tools around the converter cover the rest of the routine. The ESX validator checks the file structure before it goes to anyone. The reprice checker looks at which lines carry a recognized code, so you know what a review of the numbers would touch. The glossary and guides explain the workflow, and the profit calculator handles the business side. All of it sits on the code dictionary, which is public and free.
The PDF stays the record. The estimate is where the work happens.
None of this means the PDF stops mattering. The scope remains the paper trail: it is what the carrier signed off on, and it is what the claim file points back to. Keeping the document as a record and the .esx as the working estimate keeps those two roles separate and both useful.
When you need to explain a difference to an adjuster, you can point at a line in the estimate and at the corresponding page in the record. When the claim moves forward, you leave behind a working file that carries the same prices and quantities, structured for the software the work will be priced in.
That separation is worth protecting. A document that got edited silently is no longer a record; an estimate that cannot be changed is no longer an estimate. Conversion done honestly keeps both roles intact.
What to check in a converter before you trust it with a scope
Three things decide whether a converted estimate is safe to work with. First, does it keep the PDF price? It should, line by line, with no silent total changes. Second, what does it do with codes it does not recognize? It should keep the price, flag the line, and leave the call to you. Third, does the exported file push a price list or tax identity onto the job? It should not.
The data behind a converter matters too. The ESXPress code book was built from a real claims claims data: 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents. When the groundwork is real, flags mean something - and you can check the result yourself with the free ESX validator and the reprice checker before the file leaves your desk.
None of these are exotic requirements. They are what a file has to do to be worth opening, and they are all verifiable: convert a scope, open the result, and check the totals against the PDF. If anything disagrees, the converter has not done its job.
Real claims, not samples: where the numbers come from
The measurements in this article come from real work: 289 real claim files and 7,525 line items measured for reprice behavior, with 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents for the code book. That claims data is why the numbers describe actual conversions rather than rehearsed ones.
It is also why the flags are worth trusting. A code is recognized because it appeared in real scopes and was matched against the dictionary, not because a page said it would be. When a line keeps its PDF price, you have the record you started with - and the flag hands you the next step.