The Internal QA Gate: How to Quality-Check a Roofing Supplement Before You Submit It

Most supplement kickbacks are not caused by a desk adjuster being difficult. They are caused by a packet that left your office before it was ready. A line item with no photo behind it. A code reference with no jurisdiction attached. A quantity that does not match the diagram. A starter row added to a hip-and-ridge roof where the original estimate already paid for it. None of those are coverage disputes. They are documentation defects, and they are entirely yours to fix before anything gets sent.

An internal QA gate is the step that sits between "the estimator finished writing" and "the homeowner has a clean repair estimate in hand to give their carrier." It is a second set of eyes, run against a fixed checklist, that asks one question of every supplement: would a careful reviewer who has never spoken to us be able to follow this from the photo to the measurement to the line item to the price, with no leaps of faith? If the answer is no anywhere, it does not go out.

This is a process article for the people who actually build these packets — supplement managers, production managers, estimators, and owners who still touch files. It walks through what a real QA gate checks, in what order, with worked examples and the edge cases that trip people up. It also draws a hard line that you have to respect to stay on the right side of the law: a roofing contractor documents damage and writes an accurate repair estimate for their own scope of work. The homeowner files the claim. The insurer decides coverage. Your QA gate exists to make your documentation and your estimate defensible — not to negotiate, adjust, or "handle" anyone's claim. We will come back to that line repeatedly, because crossing it is how good contractors end up in front of a state insurance department.

Why supplements get kicked back (and why almost none of it is about coverage)

If you log the reasons your supplements come back for more than a quarter, a pattern shows up fast. The rejections cluster into a handful of buckets, and the large majority are self-inflicted:

• No supporting photo. A line item is requested but there is no image that shows the condition justifying it. The reviewer cannot see the thing they are being asked to pay for.
• Photo exists but does not prove the item. There is a picture of the roof, but it does not show the specific defect, the measurement, or the manufacturer requirement that the line depends on.
• Quantity mismatch. The line item quantity does not reconcile to the roof diagram, the measurement report, or the waste already paid in the original estimate.
• Code citation with no jurisdiction or no text. "Code requires it" is written, but the actual adopted code section, edition year, and authority having jurisdiction are missing — so the reviewer has nothing to verify.
• Duplicate of something already paid. The supplement asks for an item the original estimate already includes, usually because nobody compared the two documents line by line.
• Math and pricing that do not tie out. Unit prices, quantities, and totals do not reconcile, or a price is asserted with no basis.
• Scope that is not yours to write. Language that reads like coverage interpretation, a guaranteed approval, or a promise about the homeowner's deductible. This one is not a documentation defect — it is a legal exposure, and it should stop a packet cold.

The first six are fixable at a desk in your own office in the time it takes to read this paragraph. That is the entire argument for a QA gate: you are not trying to win an argument with an adjuster, you are trying to make sure the argument never has to happen because the packet answers every reasonable question on its own.

The mental model: every line item is a small claim of fact

Treat each supplemented line as a claim you are making about the roof. A claim of fact needs three things to be credible: something that shows it is true (a photo or measurement), something that explains why it is required (a manufacturer instruction, a published code section, or a field condition), and a number that is calculated, not guessed (quantity times a defensible unit price). If a line item is missing any of those three legs, it is going to wobble. The QA gate is just a disciplined way of checking all three legs on every line, every time, before the packet ships.

The QA gate in seven stages

Think of the gate as a pipeline. A packet enters at stage one and only advances when it passes. If it fails a stage, it goes back to the estimator with specific notes, not a vague "needs work." Here is the full sequence; the rest of the piece walks each stage in detail.

1. Intake completeness — do we even have the raw materials to review this?
2. Document reconciliation — does the supplement agree with the original estimate, the measurement report, and the photos?
3. Line-item evidence anchoring — does every supplemented line have a photo and a reason tied directly to it?
4. Code and manufacturer justification — are code-required and manufacturer-required items cited correctly and verifiably?
5. Quantity and pricing math — does everything reconcile and total correctly?
6. Compliance and language review — does the packet stay on the documentation/estimate side of the line?
7. Packet assembly and final read — is it ordered, labeled, and readable by someone who has never seen the file?

A note on who runs the gate

The person who wrote the estimate should not be the only person who QAs it. People cannot proofread their own logic — they read what they meant to write, not what they wrote. On a small team, that can mean the production manager checks the estimator's work and the owner spot-checks a sample. On a larger team, a dedicated supplement QA role pays for itself the first month, because every avoided kickback is a cycle you do not have to re-run and a homeowner who is not calling you asking why their claim is stalled. Even a rotating peer review — estimator A checks estimator B's packets and vice versa — beats no second read.

Stage 1: Intake completeness

Before anyone evaluates the merits of a supplement, confirm the file is reviewable at all. This stage takes two minutes and saves hours, because there is no point line-checking a packet that is missing the original estimate.

Intake checklist:

• Original carrier or contractor estimate is in the file (the document the supplement is built against).
• A measurement report or roof diagram with squares, ridge/hip/eave/rake/valley lengths, and pitch.
• A dated, organized photo set keyed to roof locations (slopes, penetrations, edges, accessories).
• The property address and claim identifier on every document, matching across all of them.
• The date of the inspection that the photos and notes come from.
• Any prior correspondence already exchanged on the file, so the supplement does not contradict it.

If any item is missing, the packet does not advance. A common failure is photos that exist but are not dated or not organized by location — a reviewer who cannot tell which slope a photo came from cannot anchor it to a line item. Fix the organization at intake, not at assembly.

Worked example: a packet that fails intake

An estimator hands you a supplement requesting drip edge, ice-and-water shield at the eaves, and a second layer of tear-off. The file contains the supplement and a measurement report — but the only photos are four wide shots of the roof from the ground. There is no close-up of the existing eave showing the absence of drip edge, no photo of the layers at a cut test, and nothing showing the eave detail. This fails intake immediately. You cannot anchor three of the requested items to any image. The note back to the estimator is specific: "Need eave close-up showing no existing drip edge; need a cut-test or rake-edge photo showing layer count; need eave photo for the ice-and-water justification." That is a five-minute fix on the next site visit, versus a kickback two weeks from now.

Stage 2: Document reconciliation

Now that the file is complete, the next read is comparative. Lay the supplement next to the original estimate and the measurement report and reconcile them against each other. You are looking for three things: duplicates, contradictions, and gaps.

Duplicates are the fastest way to lose credibility. If the original estimate already paid for hip-and-ridge cap, and your supplement adds a separate ridge line, a reviewer will assume the rest of your packet is just as sloppy. Read every supplemented line against the full original estimate before it stays in.

Contradictions happen when the supplement assumes a different roof than the original. If the original estimate is written for 28 squares and your supplement's quantities imply 33 squares, one of them is wrong, and you need to resolve it with the measurement report before either number leaves your office.

Gaps are the legitimate core of a supplement — items the roof clearly requires that the original estimate omitted. Those stay, but only after they survive the rest of the gate.

The reconciliation worked example

Original estimate pays: shingles for 30 squares with 10 percent waste, hip-and-ridge cap for 110 linear feet, and 12 pipe-jack flashings. Your estimator's supplement adds: starter course at the eaves, drip edge at 140 linear feet of eave plus rake, and replacement of 14 pipe jacks. Walk it:

• Starter at the eaves — check the original. If the original already paid a starter line, this is a duplicate; pull it. If not, it stays pending evidence.
• Drip edge at 140 LF — pull the measurement report. If eave plus rake totals 138 LF, your 140 is within a defensible rounding margin tied to stock lengths; note the basis. If the report shows 120 LF, your 140 has no support and gets corrected before it ships.
• 14 pipe jacks — the diagram and original both reference 12 penetrations. Where do the extra two come from? Either there are two penetrations the original missed (and you have photos of all 14), or someone miscounted. Resolve it now.

The point of the gate is that you, not a reviewer, find the 140-versus-120 discrepancy. By the time it leaves, every quantity ties to a document in the file.

Stage 3: Line-item evidence anchoring

This is the heart of the gate and where most packets are won or lost. The rule is simple and absolute: every supplemented line item must be anchored to a specific photo and a specific reason, both attached to that line. Not a photo somewhere in the packet. The photo that proves that line.

Build a one-row-per-line anchoring table. For each supplemented item, fill in the photo reference, what the photo shows, the reason the item is required, and the source of that reason. If you cannot fill a cell, the line is not ready.

When this table is complete and honest, the packet practically reviews itself, because the reviewer's first three questions — show me, why, says who — are already answered on every row.

Photos that actually anchor a line

A photo that anchors a line item has three properties. It is specific (it shows the exact condition, not a wide shot you hope implies it). It is located (the reviewer can tell which slope, edge, or penetration it came from). And it is legible (in focus, well lit, with the relevant detail filling enough of the frame to be obvious). A blurry ground shot of a whole roof does not anchor a step-flashing line, no matter how clearly you can see the wall in person.

For measurement-dependent items, the strongest anchor is a photo with a tape measure or other scale in frame. A drip-edge line is far more defensible when one of the eave photos shows a tape against the edge. A decking line is stronger when the photo shows the deteriorated area with a reference for scale and clearly exposed sheathing rather than a shingle surface.

The "why this item" evidence chain

For every line, you should be able to state the chain out loud in one breath: here is the photo, here is what it shows, here is the field condition or requirement that makes the item necessary, here is the source of that requirement. If you stumble — if the honest version is "we always add this" — the line is not ready. "We always add it" is not a reason a reviewer can verify, and it is exactly the kind of padding that gets your whole packet scrutinized line by line. Pull anything you cannot chain.

Stage 4: Code and manufacturer justification

Code-required and manufacturer-required items are some of the most defensible lines in a supplement — when they are cited correctly — and some of the weakest when they are hand-waved. The difference is verifiability.

A code citation that a reviewer can act on has four parts:

1. The authority having jurisdiction. Which city, county, or state adopted the code, because adoption and amendments vary by jurisdiction. "Code" in the abstract is not verifiable.
2. The code and edition. The specific model code (for residential roofing, typically a state-adopted edition of the International Residential Code or a state amendment of it) and the edition year that the jurisdiction actually adopted.
3. The section. The exact section that drives the requirement, so the reviewer can read it.
4. The short statement of what it requires as it applies to this roof.

If you assert "ice-and-water shield is code-required" without naming the jurisdiction, the adopted code edition, and the section, you have given the reviewer nothing to verify, and a defensible item turns into a soft one. Confirm what your jurisdiction has actually adopted — codes and local amendments differ, and the requirement that applies in one county may not apply in the next. Do not cite from memory; pull the adopted code.

Manufacturer requirements work the same way. If a shingle manufacturer's published installation instructions require a specific starter, a specific number of fasteners, or a particular underlayment to maintain the system, name the manufacturer and the instruction, and keep a copy in the file. The instruction is the source; the photo is the proof the condition exists; the line is the cost. Same three legs.

Code-justification checklist

• Jurisdiction (city/county/state) named and correct for the property.
• Adopted code and edition year confirmed against the jurisdiction, not assumed.
• Exact section identified, not a general "the code."
• Short plain-language statement of the requirement as applied.
• A copy of the relevant code text or manufacturer instruction kept in the file.
• The field photo that shows the condition the requirement applies to.

Edge case: code upgrades versus existing-condition items

Keep two categories mentally separate. A code-upgrade item is required because the adopted code mandates it when the roof is replaced (edge metal, certain underlayments, fastening patterns). An existing-condition item is required because of damage or deterioration you photographed (delaminated decking, corroded flashing). They are justified differently — one points to a code section, the other to a photo of the actual condition — and conflating them weakens both. Tag each supplemented line as one or the other so the justification matches the item.

Stage 5: Quantity and pricing math

By this stage every line has survived evidence and justification. Now confirm the numbers reconcile. This is mechanical, and it is the stage most likely to be skipped under deadline pressure — which is exactly why a reviewer who finds one math error starts re-checking all of them.

Quantity reconciliation. Every quantity ties to a source: squares to the measurement report, linear feet to the measured edge/valley/ridge lengths, counts to the diagram, areas to a marked-up sketch. Rounding to stock or bundle increments is fine and expected — note the basis so it does not read as a guess.

Waste. Do not double-count waste. If the original estimate carries a waste percentage on field shingles, your supplement should not silently re-add it. If the roof's geometry (steep, cut-up, lots of valleys) genuinely warrants more waste than the original carried, that is a legitimate item — but justify it with the diagram complexity rather than inflating the number.

Pricing. Unit prices should rest on a defensible basis — a standard estimating database for the region and period, or a documented actual cost — not a number someone typed. A price with no basis is the easiest line in the packet to challenge. Where a line falls outside what the standard pricing covers, document why with the field condition, the manufacturer requirement, or the actual cost.

Totals. Quantity times unit price equals the line total, line totals plus applicable overhead reconcile to the packet total, and the math is internally consistent. A supplement whose own arithmetic does not add up signals that nothing in it was checked.

Stage 6: Compliance and language review

This stage is short, it is non-negotiable, and it can stop a packet that passed every other check. Read the entire packet — every line description, every note, every cover communication — for language that crosses from documenting your own scope into handling someone else's claim.

The line is established by what unlicensed public adjusting is. A roofing contractor may inspect a roof, document damage with photos, prepare an accurate repair estimate for the work they will perform, and state facts about that scope. The homeowner files their own claim. The insurer decides coverage. A contractor may not, for compensation, negotiate or adjust the claim on the homeowner's behalf, interpret the policy or what is covered, promise a specific payout or approval, promise that the deductible will be waived/absorbed/covered, advertise a "free roof," or otherwise represent the homeowner against their insurer. That last set of activities is regulated, and in many states it requires a public adjuster license that a roofing contractor does not hold.

So the compliance read is a do-not-say scan. Flag and remove anything in the packet that:

• Interprets coverage — "this is covered," "your policy pays for this," any statement about what the policy means.
• Promises an outcome — "this will be approved," "the carrier will pay," any guarantee about the carrier's decision.
• Touches the deductible improperly — "we'll cover your deductible," "no out-of-pocket," "deductible waived," or anything that absorbs or erases the homeowner's deductible.
• Advertises a free roof — any framing where insurance is positioned as making the roof free.
• Negotiates on the homeowner's behalf — language positioning you as representing the homeowner against the insurer rather than documenting your own scope.

Replace that language with what is true and defensible: here is the damage we documented, here is the accurate estimate to repair it, here is the basis for each item. The homeowner takes that to their carrier. You are the documentation and estimating side of the equation, and the QA gate's job is to make sure no line in the packet drifts off that side. When you train a new estimator, teach this do-not-say list explicitly — it is far easier to never write the offending sentence than to catch it at the gate.

Why this protects you as much as the homeowner

It is tempting to treat the compliance read as box-checking. It is the opposite. The activities on the do-not-say list are exactly what a state insurance department investigates when a homeowner or carrier complains. A packet that promises an approval or erases a deductible is not a stronger packet — it is evidence in a complaint. The clean version, restricted to documented damage and an accurate estimate, is both more defensible to the reviewer and safer for your business. Compliance and quality point the same direction here.

Stage 7: Packet assembly and the final read

The last stage assembles everything into a packet a stranger can follow, then reads it once more as that stranger.

Assembly order that reviewers can navigate:

1. A short summary of what is being supplemented and why, in plain language.
2. The reconciled line items, each tagged code-upgrade or existing-condition.
3. The measurement report / diagram the quantities tie to.
4. The photo set, labeled and organized by location, with the references used in the anchoring table.
5. The code sections and manufacturer instructions cited, with the relevant text included.
6. The math that foots to the packet total.

The final read is done by someone who pretends they have never seen the file. They start at line one and try to follow each item to its photo, its reason, and its number without asking anyone a question. Every time they have to ask "where's the photo for this" or "why is this here" or "where did 140 come from," that is a defect the actual reviewer would have hit. Fix it now. Only when the stranger-read produces no questions does the packet pass the gate and go to the homeowner to submit.

Packet-completeness scoring

To make the gate measurable instead of a vibe, score every packet on completeness before it ships. A simple rubric: each line item earns a point for a valid photo anchor, a point for a verifiable reason/source, and a point for a reconciled quantity and price. A packet that is not at 100 percent does not leave. Tracking the score over time tells you where your estimators are weakest — if photo anchors are the recurring miss, that is a field-process problem, not a desk problem, and you fix it at the inspection.

A full packet, walked end to end

It helps to see the whole gate run on one file rather than stage by stage in isolation. Take a representative residential reroof: a two-story home, asphalt shingles, a moderately cut-up roof with two valleys, a chimney, a sidewall dormer, and a small detached solar array. The original carrier estimate paid for shingle replacement at 32 squares with 10 percent waste, hip-and-ridge cap, and standard pipe-jack flashings. The estimator's supplement requests: ice-and-water at the eaves, drip edge at eave and rake, step and counter flashing at the sidewall and chimney, replacement of a soft section of decking on the rear slope, and detach-and-reset of the solar array.

Run the gate. Intake confirms the original estimate, a measurement report showing 31.6 squares and the linear lengths, and a dated photo set organized by slope are all present — pass. Reconciliation compares each requested line to the original: none of the six are already paid, the implied square count is consistent with 32, and no waste is being re-added — pass, with a note that drip edge LF will need to tie to the measured eave-plus-rake length. Evidence anchoring builds the table: the eave close-up showing no existing edge metal anchors the drip edge; the eave detail in a cold climate zone anchors the ice-and-water; the corroded sidewall flashing photo anchors the reflash; the exposed delaminated sheathing photo anchors the decking; the array-footprint photo anchors the detach-reset. Every line has a specific, located, legible image — pass. Code and manufacturer confirms the jurisdiction's adopted IRC edition and the exact section behind the eave membrane and edge metal, with the text pulled into the file, and tags the decking line as existing-condition rather than code-upgrade — pass. Math ties drip edge to the measured length (rounding to stock lengths, basis noted), confirms unit prices against the regional estimating database, and foots the line totals to the packet total — pass. Compliance reads every description and the cover note and finds no coverage language, no promised approval, no deductible language — pass. Assembly orders the packet, the stranger-read produces zero questions, and the completeness score lands at 100 percent. It ships to the homeowner to submit. The discipline is unremarkable line by line; the result is a packet a careful reviewer cannot pick apart, because every question they would ask is already answered on the page.

Closing the loop back to the field

The single most common QA failure — a missing or weak photo — is not a desk problem. It is a field problem that only shows up at the desk. The estimator at the office cannot photograph an eave that the field crew never shot. That means the gate is only as good as the feedback loop you build back to whoever is on the roof.

When a line fails evidence anchoring for lack of a photo, the note should go back to the estimator and the recurring gaps should also go back to the field as a shot list. If decking photos keep coming in without a scale reference, the inspection checklist gains a line: "decking close-up with tape in frame." If sidewall flashing is routinely shot from too far away, the crew gets a one-page reference of what an anchoring photo looks like for each common item. Over a few months this collapses the most expensive part of the gate, because the photos arrive already strong and the desk review stops sending files back for re-inspection. The gate, in other words, is a measurement instrument as much as a checkpoint — it tells you exactly which field habits are costing you cycles, and the teams that act on that signal stop fighting the same kickback every week.

The complete pre-submission checklist

Print this. A supplement does not leave the building until every box is checked.

Intake

• Original estimate in file
• Measurement report / diagram in file
• Dated, location-organized photo set in file
• Address and claim ID consistent across all documents

Reconciliation

• No item duplicates the original estimate
• Square count agrees with the measurement report
• No double-counted waste
• Accessory and penetration counts match the diagram

Evidence anchoring

• Every line has a specific, located, legible photo
• Every line has a stated reason tied to it
• No line rests on "we always add this"

Code & manufacturer

• Jurisdiction named and correct
• Adopted code and edition confirmed (not assumed)
• Exact section cited, text in file
• Manufacturer instructions named and in file where relied on
• Each line tagged code-upgrade or existing-condition

Math

• Every quantity ties to a source document
• Unit prices have a documented basis
• Line totals and packet total foot correctly

Compliance

• No coverage interpretation anywhere
• No promised approval or payout
• No improper deductible language / no "free roof"
• Nothing that represents the homeowner against the insurer

Assembly

• Logical order, labeled sections
• Stranger-read produced zero open questions
• Completeness score at 100 percent

What pros get wrong

Even experienced teams make the same handful of mistakes, and they are worth naming so your gate catches them.

They QA the estimate, not the evidence. The estimator double-checks their line items and prices but never confirms a photo exists for each one. The fix is the anchoring table — it forces the photo check to happen.

They cite "code" generically. "Code requires it" feels authoritative and verifies as nothing. Every code line needs the jurisdiction, edition, and section, confirmed against what was actually adopted.

They add the same items reflexively on every roof. A boilerplate set of supplement lines that goes on every file regardless of the actual roof is the fastest way to lose credibility, because the moment a reviewer catches one item that the roof does not support, they re-scrutinize all of them. Anchor every line to that specific roof or pull it.

They double-count waste. The original carries 10 percent waste; the supplement quietly adds waste again. A reviewer who catches this assumes the rest is padded too.

They let sales language into the packet. A line description or cover note picks up marketing phrasing — a promise, a coverage statement, a deductible reference — that has no place in a repair estimate and creates real exposure. The compliance read exists to strip it.

They skip the math under deadline. The packet is due, the totals "look right," and nobody re-foots them. One arithmetic error is all it takes to make a reviewer distrust the whole document.

They run the gate inconsistently. A great checklist applied only when there is time is not a process. The gate has to be the same every time, or it is just occasional luck.

Running the gate in RoofPredict's RoofClaim

A checklist on paper works until volume goes up; then the manual reconciliation and photo-matching become the bottleneck, and packets start skipping the gate because there is not time. RoofPredict's RoofClaim is built to run this exact gate as part of the file rather than as a separate chore.

When claim documents come in — the original carrier or contractor estimate, photos, invoices, denial letters — RoofClaim ingests and OCRs them and links them to the specific home, so intake completeness is a state you can see rather than a folder you have to dig through. Its opportunity detection does the document reconciliation and evidence work that stages two through four describe: it maps the estimate's line items against a roofing knowledge base and flags missing scope, code-required items, and missed supplements, attaching the evidence anchors and pricing basis to each flag. That is the anchoring table and the code-justification check, generated against the actual estimate instead of built by hand — and because each flag carries its evidence and pricing, the "show me / why / says who" chain is already assembled for the reviewer.

Packet-completeness scoring is built in, so stage seven's rubric is a number on the file, not a judgment call — a packet that is not complete is visibly not complete, and it does not advance. Supplement aging and a follow-up cadence keep packets from stalling silently after they ship. And the documents the system produces — supplement packets, depreciation-release letters, deductible invoices, missing-docs letters, audit reports — are generated on locked, UPPA-gated, contractor-documentation-only templates. That is the compliance read of stage six enforced at the template level: the language stays on the documenting-your-own-scope side because the template will not let it drift into negotiating or interpreting coverage. Honest limit worth stating plainly: the tool flags scope gaps and assembles defensible documentation faster and more consistently than a manual gate — it does not, and must not, decide coverage or speak for the homeowner against their carrier. That decision stays with the insurer, and the filing stays with the homeowner.

Recoverable depreciation and deductibles, run the same way

Two other parts of the revenue cycle benefit from the same discipline. RoofClaim's recoverable-depreciation autopilot runs a completion-evidence and final-invoice checklist, so when work is done the depreciation-release documentation is assembled with the proof it needs rather than reconstructed weeks later. Deductible tracking keeps the homeowner's deductible visible and correctly stated on every document — which is also a compliance safeguard, because the templates ensure the deductible is tracked and invoiced honestly rather than "absorbed," "waived," or written away in a manner that would put your license at risk. The same gate that protects packet quality protects you legally, because the system was built around the do-not-say line from the start.

Building the gate into your operation

A process only survives if it is the path of least resistance. A few practical moves make the QA gate stick:

Make it a status, not a step. A supplement should have an explicit "in QA" state that it cannot leave without passing. If "submitted" can happen directly from "drafted," the gate will get skipped on busy weeks.

Separate writer and reviewer. Whoever wrote the estimate should not be the only one who clears it. Even a quick peer review catches the things the author's eyes skate over.

Log the kickback reasons. When a supplement does come back, record why in the same buckets used above. After a few months you will know whether your gate's weak point is photos, code citations, math, or language — and you can tighten that specific stage instead of guessing.

Train the do-not-say list first. New estimators should learn the compliance line before they learn the estimating software, because unlearning bad phrasing is harder than never writing it. Make the list visible at every desk.

Measure the gate. Track packet-completeness scores and first-pass acceptance rate over time. The gate is working when fewer packets come back and the ones that do come back for reasons outside your documentation rather than because of a missing photo.

The goal is not a thicker stack of paper. It is a packet where every line stands on its own three legs — a photo that shows it, a reason a reviewer can verify, and a number that reconciles — and where nothing in it strays from documenting your own scope into handling a claim that is not yours to handle. Get that right consistently and most kickbacks simply stop happening, because there is nothing left for a careful reviewer to question.

If you want the gate to run itself as volume grows — reconciliation, evidence anchoring, code flags, completeness scoring, and compliance-locked templates as part of the file instead of a manual checklist — that is what RoofPredict's RoofClaim is for. Document thoroughly, write an accurate estimate, score it complete, and hand a clean packet to the homeowner. The insurer decides coverage; your job is to make the documentation impossible to argue with.

FAQ

What is an internal QA gate for roofing supplements?

It is a fixed review step between finishing an estimate and submitting it, where a second person checks the supplement against a checklist: intake completeness, reconciliation with the original estimate, a photo and reason anchored to every line, correct code and manufacturer citations, math that foots, and language that stays on the documentation side. A packet only ships after it passes every stage.

Why do roofing supplements get kicked back most often?

Most kickbacks are documentation defects, not coverage disputes: a line item with no supporting photo, a photo that does not actually prove the item, a quantity that does not match the diagram or measurement report, a duplicate of something already paid, a code citation with no jurisdiction or section, or math that does not reconcile. Nearly all of these are fixable at your own desk before submission.

How many people should review a supplement before it is submitted?

At least one person other than the estimator who wrote it. People read what they meant to write, not what they wrote, so a second set of eyes catches missing photo anchors and logic gaps the author skates over. On a small team this can be the production manager or a peer estimator; at higher volume a dedicated QA role usually pays for itself by avoiding re-work.

What makes a photo strong enough to support a supplement line item?

It has to be specific (it shows the exact condition, not a wide shot), located (the reviewer can tell which slope, edge, or penetration it came from), and legible (in focus, well lit, detail filling the frame). For measurement-dependent items, a tape measure or scale in frame makes the line far more defensible than an unscaled photo.

How should I cite building code in a supplement so it holds up?

Name four things: the jurisdiction (city/county/state) that adopted the code, the specific code and edition year actually adopted there, the exact section, and a short statement of what it requires as applied to this roof. Confirm what your jurisdiction adopted rather than citing from memory, because codes and local amendments differ. Keep a copy of the relevant text in the file.

What language must never appear in a roofing supplement packet?

Anything that interprets coverage ("this is covered"), promises an outcome ("this will be approved"), touches the deductible improperly ("we'll cover your deductible," "no out-of-pocket"), advertises a free roof, or positions you as representing the homeowner against their insurer. Those activities can constitute unlicensed public adjusting. The packet should only document damage and present an accurate repair estimate for your own scope.

Can a roofing contractor negotiate the supplement with the insurance company?

No. A contractor may document damage, prepare an accurate repair estimate for the work they will perform, and state facts about that scope. The homeowner files the claim and the insurer decides coverage. Negotiating or adjusting the claim on the homeowner's behalf for compensation is regulated and in many states requires a public adjuster license a roofer does not hold. Keep your role on the documentation and estimate side.

What is packet-completeness scoring and why use it?

It turns the gate into a number instead of a judgment call. Score each line for a valid photo anchor, a verifiable reason and source, and a reconciled quantity and price; a packet that is not at 100 percent does not ship. Tracking the score over time shows where estimators are weakest, so you fix the recurring miss at its source rather than catching it again every file.

How do I keep my team from double-counting waste in supplements?

During reconciliation, compare every supplement quantity to the original estimate's waste factor. If the original already carries a waste percentage on field shingles, the supplement should not silently re-add it. If the roof's geometry genuinely warrants more waste, justify the increase with the diagram complexity rather than inflating the number, and note the basis.

How does RoofPredict's RoofClaim help run a supplement QA gate?

RoofClaim ingests and OCRs claim documents, links them to the home, and runs opportunity detection that maps the estimate against a roofing knowledge base to flag missing scope, code items, and missed supplements with evidence anchors and pricing. It scores packet completeness, tracks supplement aging and follow-up, and generates packets and letters on locked, UPPA-gated, contractor-documentation-only templates. It does not decide coverage or speak for the homeowner; the insurer decides and the homeowner files.