What a Xactimate line item is
A Xactimate estimate is made up of line items. Each line carries a product code, a description, a quantity, and a price. When ESXPress converts an insurance carrier's estimate PDF, the scope, into a Xactimate .esx estimate file, the line items, quantities, and unit prices travel straight from that PDF into the file.
The code is the part that rewards a lookup. It names the product, and the same base text can mean different products depending on the characters around it. Before searching, it helps to know how codes are written and grouped, because the grouping is what makes the search fast.
One more thing to keep in mind: the price on the line is the customer's own price. In ESXPress the PDF price is the source of truth. Nothing in the conversion silently re-prices a line, so when you look up a code you are confirming the product, not second-guessing the number.
The .esx format is what Xactimate reads, which means the conversion does more than copy text: the result is an estimate already shaped the way the software expects. The look-up step is what keeps you confident in each line of that file.
How to look up Xactimate line items in the code dictionary
The ESXPress Xactimate code dictionary is public and free. It has 1,480+ dedicated pages, one per code, and a free code search up front. Each page shows the description in plain English, the category, and related codes, so a lookup is usually one search and one read.
Start with what the scope shows you. The carrier's PDF usually prints the full code on the line. Type that code into the dictionary search, or type a word from the description, and the matching page comes up. For example, the drip edge line is documented at /xactimate-codes/RFG-RFGDRIP: description, category, and related links on one page.
If you have a whole estimate instead of a single line, the free ESX validator checks the file itself and its lines, and the reprice checker shows which lines carry a code we recognize. One-line lookup and whole-file validation are both free, in the same toolset.
The dictionary is not a pricing table and does not pretend to be one. Prices stay with the customer's PDF; the dictionary explains what each code means so the line can be checked against the scope.
Read the category first, then the code
Xactimate codes are organized by category, and the category shows at the start of the code. In the dictionary the URL pattern is /xactimate-codes/-: RFG-RFGDRIP is a roofing-category item for drip edge, and the page states the category next to the description.
The category tells you the trade or work type the line belongs to. When a scope prints codes in all caps with short descriptions, the category prefix plus the description is usually enough to confirm you are looking at the right product, and it tells you which group of codes to search when the exact code is cut off.
If a scope line shows only part of a code, search the category alone and browse the matching pages. The related links on each page are grouped per code, so moving from a partial code to the correct page is usually a couple of clicks.
Each page also links related codes. If the code on your scope is a variant, same product family, different configuration, the related links usually get you there in one click, and the page description tells you whether that variant actually matches your scope line.
The dictionary is built on measurements, not guesses: it comes from the claim scopes processed through ESXPress, so the codes you search are the codes that actually appear in claims.
Act codes: what the <, >, and & characters mean
Some Xactimate codes carry one of three characters, <, >, or &, as part of the code itself. These are not stray marks or formatting artifacts. They are fixed, live characters that belong to the code, and they can appear anywhere inside it, not only at the end. Real codes look like RFGFL>>P or FNCCWNM>5, with the arrow inside the string.
The arrow also records the activity of the line. In a Xactimate file, every line says whether it is an add (act=+) or a remove (act=-). A code such as STEEP> points at the steep-roof addition line, while the removal line for the same roof appears as STEEPL or as RFG|STEEP|-, two different identities, each with its own product meaning in a real estimate.
This is why a lookup must never strip the arrow. Reducing STEEP> to STEEP changes which product the line means, and a look-alike code is exactly how the wrong price ends up on the wrong line. The dictionary treats <, >, and & as part of the code: copy the code character for character, search it as-is, and you land on the matching page.
The same rule applies when you rebuild an older scope or work with a code from another list. Keep the characters exact, and when in doubt run the reprice checker after conversion to see which lines actually matched the reference.
When a code is not in the dictionary
Even with a deep claims data, not every scope line matches. Measured across 289 real claim files and 7,525 line items, 36.6% of line items carry a code we recognize; the median estimate file moves 17% of its lines on reprice, and 39 files move none.
The behavior is deliberate. 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, and the total never silently changes. You see exactly which lines need a human decision before the estimate goes anywhere.
A lookup that finds nothing is not an error, it is a signal. Check the flagged line against the scope, confirm the product from the description, and keep the PDF price as the honest baseline.
For a file-level view, the reprice checker is the instrument: it reports which lines resolved and which kept their PDF price, so the review time goes to the flagged lines instead of the whole estimate.
Using the dictionary in your daily workflow
A short habit pays off: read the code off the scope line; search it in the dictionary; confirm the description and category; check the related links when the line is a variant; and if you are working from an .esx file, run the ESX validator before you hand anything over.
When you convert a scope with ESXPress, the resulting .esx keeps the carrier's own prices. That makes the estimate easy to compare against the scope: the dictionary explains what each line means, the validator checks the file, and the reprice checker tells you which lines the reference recognized.
The glossary covers the everyday terms, line item, act code, scope, so everyone on the team uses the same words, and the guides walk through the same look-up path step by step.
When a line still does not resolve, use the flag instead of guessing. The line keeps the PDF price, so the estimate stays consistent with the scope, and the flag tells you where a human check is worth it. Look-ups are cheap; mistaken prices are not.
If you convert several scopes a week, the repeatable loop is the value: convert, look up the unfamiliar codes, review the flags, validate the file, hand over. Each pass gets faster because the dictionary answers are already familiar.
Related: how to write clear Xactimate estimates, and search Xactimate line-item codes.