Xactimate to PDF: why your PDF estimate is not the end of the line
Most teams work with PDFs from day one. Here is what stays true when an estimate never leaves PDF, and how the round trip to Xactimate really works.
Why an insurance estimate still lives in a PDF
When a carrier's scope lands on your desk, it lands as a PDF. Adjusters and restoration contractors work with PDFs every day, because a PDF is the one file everyone can open: email, phone, tablet, printer, file cabinet. The PDF survives all of them untouched. When a team searches "xactimate to pdf", the question underneath is rarely about converting an Xactimate file. It is usually: "I have these PDFs. What can I actually do with them, and what happens when the estimate has to change?"
The PDF is also the record. The carrier's scope carries the numbers the whole job runs on — line items, quantities, and unit prices — and the PDF keeps them readable years later. For sharing and sign-off, that is a feature, not a problem.
The limits show up the moment the estimate has to change. A PDF is a finished picture of the work. It does not know what a line item is, which product code it should carry, or what the same repair would cost against a different price list. Those answers exist — they just do not live in the PDF.
We know what these documents look like at scale. Our claims claims data is built from real insurance claim documents: an August 2026 wave alone produced 33,076 line items and 6,648 distinct product codes. Those are the same documents teams like yours handle every week, and the common starting point is the carrier's PDF.
So the honest question is not "PDFs or Xactimate?" Both belong in the workflow. The question is which file carries the work, and which one gets revisited when the numbers need to move.
What an estimate loses when it stays a PDF
A PDF-only estimate can be viewed, printed, and shared. It cannot be worked on. The moment someone needs to change a quantity, add a line, or fix a typo, the line has to be retyped — and retyping is where errors and disagreements begin. The PDF also never records what changed, or who changed it.
There is a practical ceiling too. Every correction, every addition, and every re-sort in a PDF-only file is a small data-entry job on a document that was never meant to be edited. Cleanup time is the quiet cost of keeping the estimate frozen.
The bigger loss is import. Xactimate reads estimate files, not carrier PDFs. An estimate that stays a PDF never becomes a file that the estimator's software can sort, merge, reprice, or hand to a colleague as an editable work product.
It also means line-item mapping never happens. Measured across 289 real claim files — 7,525 line items total — 36.6% of line items carry a code our catalog recognizes. Those are the lines that can be matched to a known Xactimate product code. In a PDF-only workflow, none of that association takes place.
The rest keep their PDF price, and that is the rule, not an exception: the PDF price is the source of truth. If a product code is not recognized, the PDF price is kept and the line is flagged — the total never silently changes.
A PDF also hides the math from your own team. Without a price-list check, no one can say whether the carrier's numbers would move on your list until someone rebuilds the estimate by hand. Rebuilding by hand is exactly what the round trip is designed to replace.
None of this means the PDF has no use. It means a PDF is the wrong file the moment the estimate turns into work that somebody has to do.
The round trip: carrier PDF into a working Xactimate file
For teams that receive PDFs from carriers, the useful direction is PDF to .esx — the Xactimate estimate file format. That is the direction ESXPress is built for: it reads the carrier's estimate PDF and produces a Xactimate .esx estimate file with the line items, quantities, and unit prices from that PDF.
Nothing is guessed. Every line carries the price from your PDF, and if a product code is not recognized, the line keeps its PDF price and is flagged for review. Your total does not change behind your back. In most estimates, most lines stay exactly where they are: measured across 289 real claim files, the median estimate file moves 17% of its lines when it is repriced, and 39 files move none.
The difference between a PDF and an .esx is not the numbers — the numbers can be identical. It is what you can do after. A PDF is a page; an .esx is a file of structured line items that Xactimate can open, sort, and reprice.
The file also arrives without a false identity. Our exported .esx carries no price-list name, no tax block, and no minimums — it assumes nothing about your market. Xactimate's receiver applies its own list when importing, and a real import test in Xactimate confirmed the file opens clean. The software then asks to reprice, and that is the intended design: your chosen price list does the pricing.
Scopes with floor plans do not lose the drawings. Floor plans in the scope PDF can be exported as Xactimate-ready .skx sketch files — one per floor page, or as a zip. The first export builds the rooms and takes a few minutes; later exports are quick. Sketch exports run through the same pipeline as production uploads.
The result is an estimate your team can actually work: open it in Xactimate, re-sort the lines, correct the quantities, and reprice against the list you trust — with every line still traceable to the price in the carrier's PDF.
Teams often keep both files on purpose: the carrier PDF for the record, the .esx for the work. That split is healthy once the conversion step is a routine part of the workflow.
Xactimate to PDF: the honest end of the round trip
Now the honest part. ESXPress does not convert an .esx file back into a PDF, and we will not claim otherwise. When a team types "xactimate to pdf", it usually wants one of two things.
The first is to share the estimate with someone who does not have Xactimate. The carrier's PDF already does that job: it is the record, it opens anywhere, and it prints exactly as written. If you simply need the estimate in PDF form and it never needed to change, you probably already have it.
The second is a PDF of the worked-up Xactimate estimate — the version your team actually corrected and repriced. That is a Xactimate feature: once the file is open, the estimate can be printed or exported to PDF from within Xactimate. It is not a conversion service, and it does not need to be.
So the round trip is complete: the carrier's PDF is the record; ESXPress converts it into an .esx; your team opens, edits, and reprices it in Xactimate; and the finished job is printed or exported from Xactimate as a PDF to share back with the carrier and the customer.
If someone opens the final PDF and wants to change a number, the PDF is not where that happens — the .esx is. The PDF is the answer sheet; the .esx is the working paper.
Our job is the middle leg, and we keep it narrow: a clean, importable estimate file carrying your PDF's prices. Everything after that happens in Xactimate, on your price list, under your review. Before an .esx file goes anywhere important, run it through the free ESX validator — a quick check for common file problems, which beats an import surprise.
A practical workflow for carrier PDF estimates
Here is the workflow, end to end, for the next scope that arrives as a PDF.
1. Keep the PDF. It is the carrier's record and the source of truth for every price on it.
2. Convert it. Run the scope through ESXPress to get a .esx with line items, quantities, and the unit prices from the PDF.
3. Review the flags. Lines whose codes are not recognized keep their PDF price and are flagged — no one has to guess or invent a number.
4. Open it in Xactimate. The file imports clean — confirmed in a real import test — and asks to reprice against your list. That prompt is the design working: your list does the pricing.
5. Work it. Sort, add, correct, and reprice. Measured across 289 real claim files, the median file moves 17% of its lines; the rest hold their PDF prices.
6. Close the loop. Print or export the finished estimate to PDF from Xactimate for the carrier and the customer.
Two free resources help between steps 3 and 4: the code dictionary, with 1,480+ dedicated Xactimate code pages for looking up what a code actually does, and the reprice checker, which shows how a file would move before you commit. The free guides walk through the same workflow in more depth, scenario by scenario.
And one reliability note, because the file is the product: the upload, convert, and download path is smoke-tested automatically every 30 minutes, and sketch exports go through that same production pipeline. What you receive is a tested file, not an untested guess.
Frequently asked questions
Can ESXPress convert a Xactimate .esx file back to a PDF?
No, and we say so plainly. ESXPress works one direction: it converts an insurance carrier's estimate PDF into a Xactimate .esx estimate file, with the line items, quantities, and unit prices from your PDF. If you need a PDF of the estimate after it has been worked in Xactimate, print or export it from Xactimate. Our part ends at a clean, importable .esx.
Why do carriers still send PDFs instead of Xactimate files?
A PDF is the universal version of the estimate: it opens anywhere, prints the way it was sent, and it survives email, phones, and file cabinets. It is also the record. What a PDF cannot do is become the working file — it is not editable, and Xactimate cannot import it directly. Send the PDF for the record; convert it when the estimate actually needs to be worked.
What happens to an estimate if it stays PDF only?
It stays viewable, printable, and shareable — and frozen. Nobody can change a quantity without retyping the line, the file cannot be imported into Xactimate, and reprice differences never surface. For context on what is missed: measured across 289 real claim files (7,525 line items), 36.6% of line items carry a code our catalog recognizes, and the median file moves 17% of its lines when it is actually repriced. In a PDF-only workflow, that mapping simply never happens.
Can Xactimate open a carrier PDF directly?
No. Xactimate works with its own estimate file format, the .esx, and a carrier PDF has to be converted into that format before Xactimate can use it. That is the step ESXPress performs. A real import test in Xactimate confirmed the converted file opens clean — and then asks to reprice against your own list, which is the design working as intended.
Will the converted file keep the prices from my PDF?
Yes — that is the rule. The PDF price is the source of truth: every line carries the price from your own PDF. If a product code is not recognized, the PDF price is kept and the line is flagged, so the total never silently changes.
When Xactimate asks to reprice, will my numbers change?
The reprice prompt is the intended design, not a problem. The exported .esx carries no price-list name, no tax block, and no minimums, so Xactimate applies its own list when importing — your chosen price list does the pricing. Measured across 289 real claim files, the median estimate file moves 17% of its lines, and 39 files move none. Most lines keep their PDF price, and the ones that move do so openly, under your review.
How do I share a PDF-only estimate with my team or the customer?
For reading, the PDF is already the shareable version: email it, print it, file it. What it cannot share is work — nobody can add a line, fix a quantity, or reprice, because the PDF is not editable. If the estimate is going to be worked on, convert it to .esx first, then hand the file to the people working in Xactimate. Run it through the free ESX validator before it goes anywhere important.
Can I print my Xactimate estimate to PDF?
Yes — that is the natural last step of the round trip. The carrier PDF stays the record; your team converts it to .esx, works it in Xactimate, and then prints or exports the finished estimate to PDF from Xactimate to share back. ESXPress does not do that final conversion; Xactimate does, once it has the file.