Why contractors convert PDF estimates to Xactimate
The short answer is compatibility. A carrier scope PDF describes the work: the scope of loss, the line items, the quantities, and the unit prices. But the working format for the estimate is Xactimate ESX, the .esx file the estimate lives in from first write to final supplement. A PDF is a picture of the estimate. The .esx file is the estimate. Converting the PDF into that format means the estimate starts the day the scope lands, with the same line items, quantities, and unit prices the carrier listed — no retyping, no second entry, no drift between what was approved and what was built.
One thing worth knowing about the conversion is what it deliberately does not do. The exported .esx file carries no price-list name, no tax block, and no minimums. Nothing about the pricing is stamped into the file, because the pricing belongs to whoever reviews the estimate with their own list. The receiver in Xactimate applies its own list when the file is imported. A real import test in Xactimate confirmed the file opens clean, and the import asked the operator to reprice — which is the desired result. In the intended design, your chosen price list does the pricing.
So the question is not whether the carrier scope ends up in Xactimate. It always does, one way or another. The question is whether it arrives ready to work or gets rebuilt by hand. Contractors who convert the PDF into a Xactimate estimate pick the first route, and the difference shows up in the first working day of the job, not the last.
Less rework on every claim
Every line an adjuster types from a PDF into Xactimate is a line that can be typed wrong. The manual route means copying hundreds of lines — the item, the quantity, the unit, the price — into a different screen, in a different program, from a document that may have been scanned, printed, and re-saved along the way. It is slow work, and it is exactly the kind of work where small mistakes hide. A transposed quantity or a price typed into the wrong column turns a clean scope into a small argument.
The measured picture is worth knowing here. Measured across 289 real claim files and 7,525 line items, 2,756 line items — 36.6% — carry a code our catalog recognizes, and the rest keep their PDF price. The median estimate file moves 17% of its lines, and 39 files move none at all. In plain terms: most lines keep the price that came out of the carrier scope, and the lines that move are the ones a recognized code supports. No line loses its price. The PDF price is the source of truth on every line, and the total never silently changes.
That rule matters more than the percentage. When a line is unresolved, the converter does not guess a code and it does not change the price. It keeps the PDF price and flags the line so you can see exactly where to look. That is the reason rework drops from re-entry to review: you are checking lines that already carry their own prices, not rebuilding an estimate out of a document.
For a contractor, the effect is a file you can trust on the first open. The scope you discussed with the carrier is the scope in the estimate, priced the way the carrier priced it.
Line-level visibility without the typing
A converted estimate is line-level, not page-level. Each line from the scope arrives as a line item with its quantity and its unit price, so it can be reviewed, edited, and supplemented on its own. You can see exactly what the carrier priced for each item, question one line without touching the others, and hand the file to the adjuster with every number in its place. When the conversation moves from tell me about this estimate to tell me about this line, the file is already shaped for it.
The code dictionary is the other half of that visibility. The real claims data explains why a dictionary matters at all: 33,076 line items and 6,648 distinct product codes were extracted from real insurance claim documents in the August 2026 wave. Nobody keeps 6,648 codes in their head. The public code dictionary — 1,480+ dedicated Xactimate code pages, each with a description, category, and related links, plus a free code search — turns an unfamiliar code into a readable product listing at the moment you need it.
Line-level visibility also means better conversations. When the carrier questions a line, you point at the line: here is the code, here is the quantity, here is the unit price from the scope. When a supplement arrives, you add a line, not a page. Visibility is what makes an estimate discussable instead of defensible.
Move supplements faster
A supplement is a conversation about scope. Something was found, something has to be added, and the estimate has to change. Speed matters here more than in almost any other part of the claim, because the job is usually waiting on the answer. When the working file is already in Xactimate form, the supplement is an edit: add the line, mark it, price it from the scope, and the conversation moves forward. When the file has to be rebuilt from a PDF first, the job waits twice — once for the rebuild and once for the answer.
Sketch work follows the same path. Floor plans inside a scope PDF can be exported as Xactimate-ready .skx sketch files, one per floor page, or a zip with all of them. The first export builds the rooms — a few minutes of work — and later exports are fast, because the rooms are already there. Sketch exports run through the same pipeline as production conversions, so sketches are not on a separate, flimsier path.
Reliability is part of speed too. The conversion pipeline is exercised by an automated upload, convert, download smoke test every 30 minutes, and every sketch export goes through the same production pipeline. When a contractor has to explain to an adjuster why an estimate is late, the explanation should never be that the converter is down.
What ESXPress is — and is not
Be clear about what a converter does: it converts. ESXPress is not a replacement for Xactimate, and it does not try to be. The carrier scope PDF becomes a starting .esx estimate — line items, quantities, and the unit prices from the PDF — and the estimate still gets reviewed, adjusted, and supplemented in Xactimate by people who do that work. The converter gets out of the way the moment the file is in the right format.
The design follows from that boundary. The exported file asks Xactimate to reprice on import, and that is the intended design: your chosen price list does the pricing. The converter keeps the scope; the estimator keeps the judgment. If a product code is not recognized, the PDF price is kept and the line is flagged — never guessed, never silently changed. That is the difference between a tool that converts an estimate and a tool that pretends to be one.
Where does that leave the contractor? With a working file on day one, prices that came from the carrier scope, and the same Xactimate workflow you already use. The conversion does not change your role in the estimate. It just gets the estimate to you sooner.