Docs
Help Center

Document troubleshooting

Choose the right recovery action for an upload, text-recognition issue, review failure, or combined PDF.

Processing allowance or uncertain provider result

For trial and prepaid workspaces, expiry, exhausted limits, a purchase hold, or an uncertain provider outcome can stop new work. Check processing and purchase status before retrying. Re-uploading, creating another key, or restarting the same file does not clear an uncertainty hold. Contact support when reconciliation is required.

A platform failure without a usable packet report releases the reserved review credit after the related work settles; processing already performed remains counted. Platform retries for the same review share its operation. A new review or changed source snapshot can use another credit. Previously saved, authorized files and results remain readable.

Start in the project's Documents view. Check the affected file and its current version before choosing an action. A failed background step does not mean every step failed, and a completed individual-document review does not mean the whole project is ready or approved by a utility.

When an application form is refused

The current failed form review can show a wrong-form, different-revision or could-not-verify explanation in its Documents row, with the recorded reason and observed differences. Check that the PDF belongs to the project's selected program and use the correct utility form before retrying. Both normal and compact document rows show the same explanation. A successful retry or replacement clears the old refusal; a refusal is not an upload-transfer failure.

When progress stops updating

A live-update connection warning describes how the browser receives fresh information, not whether the upload or review failed. Do not replace an accepted file or restart a completed review just to clear that warning. Check the affected document's separate processing outcomes below.

With permission-aware live updates enabled, successful periodic refreshes stay quiet. Some live updates are unavailable. means at least one required source or connection remains unavailable; use its refresh/retry action. While offline, displayed information may be out of date. If the session cannot recover, use Sign in. Previously displayed data stays visible during temporary connection failures, but is removed when a fresh authorization check confirms lost access.

This recovery behavior is a gated rollout. A tab opened before the upgrade needs a refresh to use the new behavior; reconnecting alone does not upgrade it.

Self-service processing limits

Self-service processing remains unlaunched. Its guarded recovery path keeps the original review, funding, and source versions together. A retry does not create a new trial or erase processing costs. Retrying an unchanged upload does not count the same source twice, but deleting a source does not restore its lifetime upload allowance. Archive containers, expanded entries, and linked file versions also count toward that allowance.

A platform failure can return an unused packet-credit hold only after the related work settles. A usable report already delivered remains consumed, and incurred or uncertain provider costs are retained. An eligible retry must be recorded by the server, have available credit, and pass the original source and funding checks again. An expired trial or unresolved provider outcome cannot be bypassed by repeated retries. Ask support to resolve the underlying issue before trying again; these restrictions do not authorize a new paid run or make self-service available.

Unsupported source format

If your workspace is limited to PDF review, use standalone PDFs. The server refuses images, ZIP archives, and native CAD files in that scope, including saved File Library attachments and sources already attached to a packet. Repeated retries, another client, or an earlier upload cannot override the restriction. Supply supported source files without treating a PDF-only review as a waiver of the utility's required evidence.

A format refusal does not establish a completed upload or review. If an assistant or integration returned upload, job, or review-run identifiers before an interruption, check those same operations before starting another attempt. Preserve the report's document and page citations when sharing findings so the result stays connected to its source evidence.

Read the three outcomes separately

One document, three independent outcomes

Synthetic example: an accepted PDF can have failed text recognition and a completed document review at the same time.

  1. Upload

    Were the bytes accepted?

    Complete means the server accepted the uploaded source. A transfer reaching 100% alone is not acceptance.

  2. Text recognition

    Is searchable text available?

    Text recognition, also called OCR, extracts text and locations. Its failure can limit search without invalidating a completed review.

  3. Document review

    Did the review finish?

    A completed result belongs to the reviewed document version. A failed review needs its own recovery; retrying the upload is not the same action.

Source anchors: lib/documents/intake/intake-status.ts, lib/documents/ocr/state.ts, lib/console/review-progress.ts

The safe viewing copy is prepared separately from text recognition. If preview is still preparing, wait for that step; do not assume an OCR failure means the original PDF was lost. If no status is available, the outcome is unknown—not proof of failure or success.

Choose the action that matches the problem

Which action should I choose?

Use the narrowest recovery action that matches what happened. Do not repeatedly restart a platform error.

  1. Transfer failed

    Retry upload

    Use Retry when the original bytes were not accepted. An interrupted transfer may support Resume; expired authorization requires a fresh attempt.

  2. Content changed

    More → Replace

    Use Replace for a corrected PDF in an editable project. The new version is separate from historical reviews and submitted-package evidence.

  3. Review failed

    Retry review

    Use the document review retry action for a failed review after the underlying issue is resolved. It does not upload a new file or retry OCR.

  4. Several documents in one PDF

    More actions → Split PDF

    For an eligible accepted PDF, preview and confirm complete page ranges. Assigned or reviewed PDFs can be split; do not infer duplicate content from filenames.

Source anchors: components/console/views/packets/packet-documents-manager.tsx, lib/console/intake/intake-uploads-controller.ts, app/actions/combined-document-split.ts

Retry upload

  1. Read the failure message and its suggested next action.
  2. Check the limit shown by the project upload control. Project sources are limited to 30 MB each.
  3. For a paused transfer, use Resume when available. For an expired authorization or an interrupted attempt that cannot resume, use Retry to obtain a new authorization and path.
  4. If the server rejected the upload protocol, stop repeated retries and contact support. Repeating the same request does not correct a platform configuration error.
  5. If finishing reports that the upload changed, another retry replaced this attempt. The card refreshes; use Retry if it is still offered. This is not a locked submission.
  6. Wait for server acceptance and the document's safe viewing copy. Do not rely only on 100% progress.

Retry preserves prior attempt history. Refreshing a page does not turn a reported failure into a successful upload, but bytes the server already verified count even if the browser reported a failure. Reporting a failure never makes a file less retryable. If its upload batch expired or was abandoned, the batch stays closed history; use the file's own Retry instead of reselecting it.

Replace a corrected PDF

In an editable project's Documents view, choose More → Replace on the intended document. Select the corrected PDF and wait for the new current version. If someone replaced the document while your upload was in progress, refresh and select the intended version again.

Working versions and historical evidence

Synthetic example: replacing Site plan v1 with v2 does not rewrite the results produced from v1.

  1. Historical

    Site plan v1 and its review

    The earlier version, its results, and any formal submitted-package copy retain their original relationship.

  2. Current

    Site plan v2

    The replacement becomes the current working version only after acceptance. Its preparation and review have their own outcomes.

  3. Optional split

    Confirmed children

    A split preview leaves the parent usable. Confirmation creates child documents and retires the active parent together, retaining historical results.

Source anchors: lib/documents/intake/acceptance.ts, app/actions/combined-document-split.ts

Retry a document review

Open the affected document's review controls and use Retry review when offered. If support has asked you to wait for a fix, wait for confirmation that this specific review can be retried. Do not replace an unchanged PDF just to restart a review. Keep individual-document results separate from a whole-project review. If the utility's published requirements changed since the failed review, support recovery may create a new review under the current rules while preserving the earlier failure in history.

A packet review appears stuck

Open Review Actions → Cancel Packet Review and confirm the active run. The action is available only if you have permission to run reviews in that same applicant or utility review lane. If the action is missing, contact support with the project and approximate start time.

Cancellation stops that run from saving further packet results and preserves completed document findings. An external provider request already in progress may finish in the background. If the workflow's stop cannot be confirmed, the interface shows a warning; contact support before starting another packet review. Cancellation does not fix the cause of a crash or restart OCR.

Use Findings or the Partial report — document checks to read completed current document results while the packet review is running, failed or cancelled. The Individual-document review results label means these are not whole-project results or utility approval. Current completed packet results take priority; old file versions or earlier successful checks are not used to hide a newer failed document review.

Split a combined PDF

Use More actions → Split PDF for an eligible accepted PDF in an editable project. An assigned role, earlier review, or missing possible-combined hint does not prevent splitting. The supported range is 2–250 pages. Review the parent/child preview, cover every page exactly once, and assign a role to each retained range. Discard only genuine blank or separator pages.

Analysis and preview preserve the parent's type and historical reviews. Confirming pauses new reviews and submission while the split runs; only success retires the active parent and creates children needing fresh review. If the version changed after preview, analyze it again. A failed attempt offers Retry split or Keep original; keeping it preserves the original and history.

See Split a combined PDF for permissions and details.

When text recognition fails

Text recognition powers search and text-location features. It is not the same as document review. Check the safe preview and any completed review results independently. There is no general customer OCR-retry control described here: contact support for a scoped reprocessing decision. Replacing an unchanged file or repeatedly retrying review is not an OCR repair. If recognition output is cut off by a processing limit, support must address that limit or its cause before repeating the same recovery. A green status must reflect usable text, not a cleared error.

Support may be able to recover processing from an accepted file without asking you to upload it again. Provide the project, filename and affected outcome, and wait for confirmation before repeated retries. OCR recovery does not require rerunning a successful document review. Support will verify the resulting text or review findings; a completed background job alone is not the same as confirming the result is usable. If the original bytes were never accepted, you may still need the original file for Retry upload.

If the document or project review inputs change while support prepares recovery, tell support: the earlier approval no longer applies. This includes changing only the project's state. Support must check the current inputs again; an older recovery must not update a newer file or use outdated project details.

What to send support

Include the project, affected document/version, approximate time and time zone, the visible status, and the action you tried. Include packet, upload, job, and review-run identifiers when returned by your assistant or integration. A screenshot of the message can help. Do not send passwords, API keys, signed download links or unrelated confidential documents. Follow the support guidance.

On this page