Roofing Supplement Packet Checklist: Photos, Measurements, Notes, And Files

A roofing supplement packet should make each requested estimate revision easy to trace. The practical test is simple: can a reviewer open the packet, see the requested change, find the supporting photo, verify the measurement source, read the estimate note, and understand which file supports the request without calling your office for a missing detail?

That is the job of the packet. It is not a promise that an insurer will agree. It is not a substitute for policy language, carrier review, licensed estimating judgment, or legal advice. It is a contractor documentation file that connects field facts to estimate review.

Use this structure when your team is preparing a supplement after a roof inspection, reinspection, production review, or office estimate audit. The clean packet has five working parts:

• Photos that show the condition, location, and context.
• Measurements that show where the quantity came from.
• Notes that explain what changed and why it belongs in the estimate review.
• Files that support the request, such as roof reports, invoices, receipts, product documents, correspondence, and weather records.
• An item support log that ties the requested revision to the supporting evidence.

Official Xactware documentation describes attaching notes, images, sound files, and documents to line items in Xactimate X1, while mobile photo documentation describes adding images to a project photo area. Those features are useful because a supplement packet should not be a loose pile of pictures. It should be an indexed file where every attachment has a job.

The Supplement Packet Spine

Build the packet in the same order every time. The order matters because supplement review slows down when the reviewer has to rebuild the story from scattered files.

The revision summary is the most important page in the packet. It should not read like a demand letter. It should read like a clean index:

This layout keeps the packet grounded. It does not say the item is owed. It says the contractor is requesting review and points to the support.

Roofing Supplement Packet Checklist

Use this Checklist before anyone sends the supplement.

This checklist is intentionally strict. A shorter packet may be enough for a small revision, but the same logic should still apply: one request, one explanation, one evidence trail.

Photos: What To Capture And How To Label It

The photo packet should answer four questions: what is the condition, where is it, how does it relate to the estimate, and what else in the file supports it?

Start with orientation photos. These are not glamorous, but they keep the packet understandable. Include front, rear, left, and right elevations from safe ground positions when available. Add roof-face orientation photos from safe, authorized inspection positions only when your company safety plan permits it. If the crew cannot access a roof face safely, record that limit instead of forcing the shot.

Then move into item photos. For each requested revision, collect enough context to show location before the close-up. A close photo of a vent, ridge, valley, skylight, gutter, flashing, fascia, or interior stain is weaker when the reviewer cannot tell where it sits on the building. Pair close photos with wider photos and use roof-face labels consistently.

A useful file naming pattern is:

P-021_south-slope_plumbing-vent_close_2026-05-23.jpg

The file name should not carry an argument. Avoid names like carrier-missed-this.jpg or must-pay-vent.jpg. The packet should feel professional because the facts are organized, not because the file names are dramatic.

Do not over-edit photos. Cropping for focus, redaction for privacy, and arrows or callouts can be useful, but the original image should remain available when possible. If you annotate a photo, keep the original and the annotated version in the index. Label the annotated version as an annotation.

For supplement work, the strongest photo set usually includes:

• Safe exterior orientation photos by elevation.
• Roof-face overview photos where safe and authorized.
• Close-up item photos tied to a roof face, slope, elevation, room, or component.
• Collateral photos such as gutters, downspouts, soft metals, fencing, screens, or other exterior context when relevant to the requested review.
• Interior photos for water entry, ceiling stains, attic conditions, or temporary mitigation when relevant.
• Access and staging photos when labor, disposal, material movement, or steep/height access is part of the review.
• Inaccessible-area notes when a roof section, attic area, or exterior side could not be documented safely.

OSHA materials on roof inspection, tarping, and repair describe hazards from ladders, raised work surfaces, damaged roofs, steep or slippery surfaces, tools, and power lines. The supplement packet should never pressure the field team into unsafe collection. If a needed angle cannot be captured safely, the packet should say so and use safer context photos, roof reports, or later qualified inspection.

Measurements: Show The Source Before The Quantity

A supplement packet gets weaker when it argues about a quantity without showing where the number came from. Before asking for a quantity change, identify the measurement source.

For roof work, the measurement support should usually include:

Official Xactware roof and estimate-item documentation shows roof objects, roof dimensions, and estimate line items working together in the estimate workflow. That does not make any one sketch automatically correct. It does support a basic packet rule: the sketch, photo log, and estimate should speak the same language.

If the photo log calls a face S2, the sketch should show S2. If the supplement asks for review of a rear-slope accessory count, the measurement log should not leave the reviewer guessing whether that count came from aerial imagery, a field photo, or a roof report.

Roof waste deserves its own note. Xactware's roof-waste documentation shows that waste review belongs in the estimating workflow rather than in a fixed, universal percentage claim. That is why a supplement packet should avoid a bare statement like "waste should be higher." A better note says which roof geometry or material assumption is being reviewed and where the supporting file lives.

Example waste note:

Review waste setting for Roof1. Packet support: roof sketch MEAS-ROOF-01, valley photo group PHOTOS-VLY-01, material assumption note MAT-01. Request is based on roof geometry and waste-factor review, not a fixed percentage rule.

That wording does not guarantee agreement. It gives the reviewer a clean path to the supporting facts.

Estimate Notes: Make The Item Easy To Review

Good supplement notes are short, factual, and traceable. They should not argue like a social media post or guess at coverage. A strong note uses five fields:

Use this template:

Location: [roof face/elevation/component]. Condition: [observed condition]. Quantity support: [measurement source or count]. Attachments: [file IDs]. Requested review: [estimate section or item context].

Example:

Location: East slope, lower dormer return. Condition: Field photos show a separate return area not visible in the overview photo. Quantity support: MEAS-ROOF-02 and photos P-044 to P-049. Requested review: confirm roof sketch area and related estimate quantity for this roof section.

Xactimate line-item documentation supports reviewing category, selector, activity, quantity, formulas, notes/images, item details, tags, and unit-price settings. The packet should use that structure without turning it into a public code sheet. You do not need to publish a list of selectors to write a clear note. You need to make the estimate context clear enough that the licensed user or reviewer can examine the item in the actual estimate.

Files: Build An Attachment Index, Not A Junk Drawer

Every supplement packet should have a file index. If the file index looks tedious, that is usually a sign it is doing valuable work. It saves the reviewer from opening every attachment just to find the one roof report or invoice that matters.

Include only files with a purpose:

• Current estimate version being reviewed.
• Prior estimate version if the supplement compares versions.
• Roof measurement report or sketch export.
• Field photo folder or photo PDF.
• Annotated photo set, clearly labeled as annotated.
• Invoices, receipts, supplier quotes, or purchase records when the requested review depends on actual job cost.
• Manufacturer or product document only when directly relevant to the requested item.
• Permit, code, or local requirement document only when sourced and applicable to the job location.
• Correspondence log that shows dates and topics, not private commentary.
• Weather report or NOAA/SPC record for date and area context.
• Safety or access note explaining why a photo, roof face, attic area, or measurement could not be collected.

FEMA's home insurance claim information points to documenting date, time, cause, damage description, photos or videos, damaged item lists, and receipts. NAIC consumer guidance also supports documentation basics such as photos, videos, lists, deductible awareness, and insurer or agent contact. For a contractor packet, those sources support organized documentation. They do not authorize the contractor to interpret coverage or decide the claim.

The file index should have four columns:

Weather Records: Context, Not Damage Proof

Weather files can be useful, but they are often overstated. NOAA's Storm Events Database contains records used to create the official Storm Data publication. The Storm Prediction Center also publishes storm reports and marks those reports as preliminary. Those sources can help establish date, area, event type, and severity context.

They do not prove that hail hit a specific shingle, broke a specific vent, or caused a specific leak at one address. Keep weather files in the packet, but label them correctly:

• Use weather records to support date and area context.
• Pair weather records with field photos, roof inspection notes, and measurement files.
• Do not use preliminary reports as final property-level proof.
• Do not make the weather file the whole supplement argument.

The safer wording is:

Weather context: NOAA/SPC files are included for date and area context. Property-specific conditions are documented separately in photos, inspection notes, and measurement files.

That one sentence prevents a common overclaim.

Pricing And Labor Notes: Describe The Job Condition

Supplement packets often become sloppy around pricing. A contractor may know the job is harder than the estimate shows, but the packet still has to show the job condition.

Verisk pricing methodology materials describe local and regional pricing research, item detail review, and job-specific variation. Verisk's labor productivity materials explain that productivity can be affected by accessibility, location, quantity of work, and supporting tasks. Those sources support a practical packet standard: if the supplement asks for pricing or labor review, show the job condition.

Useful support can include:

• Access photos showing height, slope, rear-yard constraints, narrow side yards, landscaping limits, or disposal constraints.
• Quantity notes showing why the amount of work differs from the prior estimate.
• Supplier or invoice documents when actual material or job cost is part of the review.
• Production notes showing sequencing, protection, setup, or cleanup conditions.
• Estimate notes that identify what item detail or assumption is being reviewed.

Avoid broad claims like "Xactimate is too low" or "this carrier always misses labor." Those claims are weak and usually unsourced. A better packet says:

Requested review: rear elevation access condition. Support: PHOTOS-ACCESS-01, production note PROD-02, and estimate section [roof removal/access]. The photos show restricted material movement and staging conditions for this job.

That language stays close to the facts.

The Pre-Send Review Pass

Before sending the packet, have someone who did not build it run this review:

1. Can they find the estimate version being reviewed in under 30 seconds?
2. Can they tell what changed from the prior version?
3. Does every requested review point to at least one file ID?
4. Are photos numbered and tied to locations?
5. Do close-up photos have wider context photos?
6. Do roof-face labels match between photo log, sketch, and notes?
7. Are quantities tied to a measurement source or formula?
8. Are roof waste assumptions documented without a fixed universal rule?
9. Are weather files labeled as date and area context only?
10. Are invoices, receipts, or supplier documents attached only when they support a request?
11. Are product or code documents current and directly relevant?
12. Are unsafe or inaccessible areas noted?
13. Are line notes factual instead of argumentative?
14. Are private homeowner details redacted where needed?
15. Does the packet avoid coverage decisions, legal advice, and approval promises?

If the answer to any of those questions is no, fix the packet before it leaves the office.

Where RoofPredict Fits

RoofPredict can help keep the supplement workflow from turning into a scattered set of folders, messages, and unlabeled photos. Use it to organize roof age, storm exposure, photo groups, inspection reports, measurement files, notes, documents, and follow-up status in one place before the estimator or supplement coordinator sends the packet.

The product role should stay narrow and useful:

• Create a clean packet workspace for each property.
• Track photo groups by roof face, elevation, room, or component.
• Store roof reports, estimate versions, invoices, product documents, and weather context.
• Keep a supplement review checklist and follow-up status.
• Help the team see which requested revisions still lack support.

RoofPredict does not inspect the roof, replace Xactimate, decide coverage, act as a public adjuster, give legal advice, verify storm damage, or approve a supplement. Its value is organization: fewer missing files, clearer notes, and a packet that a reviewer can follow.

Source Limits

FAQ

How many photos should a roofing supplement packet include?

Use enough photos to prove location and context for each requested review. A smaller packet with labeled overview and close-up photos is stronger than a large folder of unlabeled images. Every photo group should connect to a roof face, elevation, room, component, or estimate item.

Should the packet include Xactimate line-item codes?

The packet should identify the estimate section or item context being reviewed, but it should not publish a generic code list or treat any code as always owed. Use the actual estimate, licensed software access, and reviewer workflow for specific item work.

What if a roof face was unsafe to photograph?

Do not force access. Record the safety limit, collect safer context photos, attach roof reports or other measurement files when available, and note what could not be verified safely. A clear safety note is better than a risky photo.

Can NOAA or SPC storm reports support a supplement?

They can support weather date and area context. They should not be presented as proof that a specific roof was damaged. Pair weather files with photos, inspection notes, and measurements.

Should invoices and receipts be included?

Include them when actual job cost, material cost, disposal, access, labor condition, or replacement documentation supports a requested review. Redact private information where needed and make the purpose clear in the file index.

What is the most common packet failure?

The most common failure is a missing link between the request and the evidence. A packet may have good photos, a roof report, and estimate notes, but if the revision summary does not connect them, the reviewer has to rebuild the packet manually.

What should RoofPredict track for supplement work?

Track the estimate version, requested revisions, photo groups, roof-face labels, measurement files, invoices, weather context, missing evidence, follow-up dates, and review status. The goal is a packet your team can understand a month later without relying on memory.