---
url: "https://dfylegitscript.com/blog/refiling-after-a-denial-without-repeating-it"
title: "Refiling after a denial, without spending the fee twice"
description: "The LegitScript application fee is charged per website and is not refunded whatever the reviewer decides, so a refiling spends it again, and the most common way businesses spend it twice is resubmitting quickly with one correction rather than diagnosing what actually generated the decision."
published: "2026-07-08T14:49:47+00:00"
modified: "2026-08-03T15:18:23+00:00"
---

# Refiling after a denial, without spending the fee twice

The LegitScript application fee is charged per website and is not refunded whatever the reviewer decides, so a refiling spends it again, and the most common way businesses spend it twice is resubmitting quickly with one correction rather than diagnosing what actually generated the decision.

## Key takeaways

- Sort the cause into structural, evidential or presentational before doing anything else, because those three need completely different work.
- Fix the class of problem rather than the sentence that was quoted, since the same claim almost always appears in four other places on the estate.
- A second review is a careful review, which is why a fast refiling carrying one correction is the most reliable way to spend the fee twice.
- Moving to a new domain does not shed the history, because the entity, the principals and the public record travel with the next application.

A denial is a decision on the application as filed, and refiling is possible. It
is also the point at which businesses make their most expensive mistake, which
is to treat the notice as a single fault to be patched rather than as evidence
about how the file was read.

The cost of getting that wrong is not one application fee. It is another full
cycle with everything downstream still blocked, which
[what a denial actually costs](/blog/what-a-denied-legitscript-application-actually-costs)
sets out in the terms that matter.

## First, read the notice literally

The stated reason is usually accurate and usually narrower than the panic
suggests. Read it for what it says rather than for what you fear it says, and
write down exactly which facts it turns on.

Then separate two questions that feel like one. What did the notice cite? And
what made the file look the way it did? The second is almost always larger than
the first, because a reviewer cites what settles the decision rather than
everything they saw.

## Sort the cause into one of three buckets

**Structural.** Something about the business rather than its presentation: a
model where the prescribing decision is not real, prescribers not licensed where
patients are, a compounder whose scope does not cover what you sell, a supply
route that cannot be lawful. No refiling reaches this. The business changes or
it does not apply.

**Evidential.** The facts were fine and the file did not establish them:
documents not supplied, a partner who never sent their registration, answers
that described rather than evidenced.

**Presentational.** The website said something it could not support, or said
something different from the application.

Only the second and third are refiling problems, and they have different fixes.
Businesses that skip this sort refile against the wrong bucket.

## Fix it completely rather than narrowly

The instinct after a denial is to change the specific sentence the notice
mentioned. That produces a second application that differs from the first in one
paragraph, filed by a business that has demonstrated it did not understand why
the first failed.

Fix the class of problem instead. If a claim on the product page was cited,
sweep every channel for the same claim: quiz result screens, email sequences,
support macros, affiliate creative, packaging inserts and the review widget. If
the pharmacy documentation was thin, assemble the whole supply-chain section
rather than the missing item.

## Assume the second review is careful

A refiled application arrives with a history. That is not a punishment, it is a
reasonable posture, and the planning consequence is that the second file should
be able to answer more than the first rather than exactly as much.

Two additions help more than anything else. A short covering account of what was
wrong and what changed, dated, so the reviewer is not left inferring it. And
evidence rather than description everywhere the first file used description.

## Decide about the timing

Fast refiling is the mistake. Sensible refiling waits until the fix list is
closed, which is usually an engineering and copywriting timeline rather than a
compliance one, and
[getting that work scheduled](/blog/getting-the-website-fix-list-through-your-engineering-team)
is the actual critical path.

Expedited processing is worth thinking about differently here. It buys a start
within two business days of submission, and after a denial the constraint is
almost never the queue. It is whether the file is ready, which is exactly the
situation expedited processing does nothing for.

## Should the refiling be the same domain

Occasionally somebody suggests filing a different domain instead, on the theory
that a fresh application is cleaner than a corrected one.

Treat that carefully. Certifying a second domain because the first was denied,
while the first remains the business you actually operate, is a structure that
invites the question of why. Where the domain genuinely is changing for
commercial reasons, that is a different conversation and it is
[a migration with its own sequence](/blog/rebranding-or-migrating-a-certified-telehealth-domain).

The version that never works is presenting the same business at a new address
and hoping the history does not follow. Ownership, principals and the public
record are the same in both applications, and they are the first things
established.

## Tell the counterparties before they find out

An acquirer, an ad platform or a partner who learns about a denial from you,
with a plan and a timeline attached, is in a different conversation from one who
learns it from a listing lookup.

Say what happened, say what is being changed, and give a realistic account of
the two clocks rather than a date. Businesses lose merchant accounts over the
silence far more often than over the denial.

## What to keep from the whole episode

Write down what generated the questions, in detail, while it is fresh. That
record is what stops the same cause recurring on the next domain you certify,
and a multi-domain business is going to certify another one.

Keep the corrected allowlist, the closed fix list and the assembled evidence in
[the file](/blog/what-a-complete-legitscript-application-file-looks-like) rather
than in an email thread. The second application is cheaper than the first only
if the work survives it.

## The uncomfortable possibility

Sometimes the honest conclusion is that the model needs changing rather than the
file. That is a worse answer commercially and a much better one financially than
a third application, because the fee is spent every time and the downstream
blockage persists throughout.

A business that reaches that conclusion after one denial has spent one fee to
learn something structural. One that reaches it after three has spent three.

## Frequently asked questions

### Can I refile after a denial?

Yes. A denial is a decision on the application as filed rather than a permanent bar. The application fee is charged again on refiling, which is why the cheapest second attempt is the one that fixes the whole class of problem rather than the specific sentence cited.

### Is there an appeal process?

Certification is a commercial decision by a private company applying its own standards, so there is no regulator to appeal to. The remedy is a corrected application rather than a hearing.

### Should I buy expedited processing for the refiling?

Usually not for that reason. Expedited processing buys a review start within two business days of submission, and after a denial the constraint is almost always whether the file is ready rather than how long the queue is.

## Disclaimer

LegitScript is a trademark of LegitScript LLC. VeriScripts is an independent application-preparation service. It is not affiliated with, endorsed by, or certified by LegitScript LLC, and claims no sponsorship or partnership with it. We prepare, submit, and manage the application; LegitScript alone decides whether certification is granted. "LegitScript" is used here only to name the certification these applications are for.