Negotiating a supplement starts at the line level
When an adjustment comes back - a supplement requested, a scope modified - the conversation happens at line items, not at page numbers. The carrier approved a quantity for a drip edge or a steep-roof removal at a certain price; you believe the conditions on the job say otherwise. Without a working estimate, explaining why means quoting pages. With one, you point at a line.
The estimate file organizes the carrier's scope into something you can sort by category, filter by trade, and line up against the numbers your own estimator produced. That comparison is the whole game in supplement work.
Line-level work is not a preference; it is how the system works and how the conversation goes. Carriers build scopes line by line. Adjusters review them line by line. If your side of the comparison is a stack of pages, you are arguing from reading, while the other side is arguing from data.
What a PDF to ESX conversion gives you in Xactimate
A native .esx opens in Xactimate as a real estimate: line items with product codes, quantities, and properties you can filter and sort. You can group by category, look at one trade at a time, and see exactly which lines carry the values the carrier approved and where your proposal differs.
The conversion does not invent values. The PDF price is the source of truth in ESXPress - every line carries the unit price from the customer's own PDF. Codes that are not recognized keep their PDF price and are flagged, so you always know which lines arrived as the carrier wrote them and which ones deserve your attention.
Sorting is only useful if the lines are real, and conversion is where that is decided. The lines you see in Xactimate are the lines from the PDF - same descriptions, same quantities, same unit prices - not a cleaned-up or guessed-at version of the scope.
When you open the file, the numbers you see are the PDF numbers, and the flag next to an unmatched code tells you where to look. Nothing gets reworded or reclassified behind your back, which is exactly what makes a line-by-line comparison worth doing at all.
How to compare a supplement line by line
Start with the lines that are flagged and the lines where your number differs. 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. The lines you are tallying are the ones to check against the code dictionary and your own production figures.
For each line you question, the free code dictionary is the reference: 1,480+ dedicated Xactimate code pages, each with a description, category, and related links, plus a free code search. The ESX validator confirms the file structure before it goes anywhere. The reprice checker shows which lines carry a recognized code - the ones where a review of the price would actually change something - without touching the PDF prices on unmarked lines.
Keep a short ritual: identify the trade, list the flagged lines, look up the codes, then compare quantities and prices. The dictionary pages give you a description and a category for each code, which is usually enough to tell a genuine difference from a code mismatch before the conversation even starts.
Prices come from your PDF, so the comparison is fair
Every line keeps its PDF price, so the comparison you make is between that price and your price - not between a converter's guess and a carrier's number. The exported file carries no price-list name, no tax block, and no minimums, and Xactimate's receiver applies the price list you choose when importing. A real import test in Xactimate confirmed the file opens clean, and the software asked the operator to reprice, which is the intended design: your chosen price list does the pricing.
In practice: open the .esx, let Xactimate apply your list, and compare the visible result with the carrier's approved lines one at a time.
Fair does not mean agreeing with you. It means neither side is arguing against a number the converter invented. What you argue for is what the PDF says, what your list says, or what the job conditions say - each one traceable.
What to look for in a converter for supplement work
Three features matter. The converter must keep the PDF price on every line. It must flag unrecognized codes instead of guessing at them. And it must not stamp a price-list or tax identity onto your job. The ESXPress code book is built from a real claims claims data - 33,076 line items and 6,648 distinct product codes extracted from real insurance claim documents - which is what makes a flagged line meaningful rather than routine.
When the scope also has floor plans, the same pipeline exports them as Xactimate-ready .skx sketch files, one per floor page or as a zip. A sketch that comes from the same source PDF as the estimate keeps the supplement and the drawing consistent.
The converter is only half the workflow. The checking tools are the other half, and they are free: the ESX validator, the reprice checker, the code search, the glossary, and the guides all live on the same site as the converter.
One more test is worth doing before you rely on any converter. Take a scope you know well, convert it, and check the totals against the PDF. If they match line for line, the converter is doing what it should; if they do not, nothing else about the tool matters.
A review routine that works with a native .esx
Filter the estimate to the trades in question. Check flagged lines against the code dictionary. Compare your proposed lines with the carrier's lines side by side. Where the difference is real, you have a line, a code, and a price to point at; where the difference is a mismatched code, the dictionary page usually settles it.
Run the exported file through the free ESX validator before it goes anywhere, and use the reprice checker on the lines you care about. Then the conversation with the adjuster is about the estimate, not about getting the document to behave.
No converter decides an outcome; estimates get negotiated, not auto-approved. What it changes is the quality of the conversation: differences get stated as lines, codes, and prices, and the record - the PDF - stays intact for anyone who asks.
Turning the review into the supplement itself
When the review is done in the estimate, the supplement is mostly written: the lines you questioned, the codes you checked, and the prices you compared are all there. Add a short explanation for each difference and the supporting reference from the dictionary, and the document that goes to the carrier is built on lines instead of paragraphs.
The same pipeline carries the whole job. An automated upload-to-convert-to-download smoke test runs every 30 minutes, so conversion is exercised continuously, and a sketch that ships with the supplement comes from the same source PDF as the estimate.