Recovering failed uploads

7 min read·Updated July 13, 2026

On this page

What Failed uploads is
Where to find it
Why a document ends up here
Every element on the page
Empty state
What happens if you do nothing
Related reading

What Failed uploads is

Every document you send Verinode, an upload, a forwarded email, a photo, a pasted note, a voice capture, flows through the ingestion pipeline before it becomes a vendor record, a job, or a margin figure. Most documents move through quietly. Occasionally one does not: the file cannot be read, an AI extraction step trips on it, a provider hits a rate limit, or the data that comes out fails a basic check. Verinode does not give up on the first miss. It retries automatically, waiting longer between each attempt, and only after three real attempts have failed does a document stop retrying on its own.

Failed uploads is the page that holds those documents. Nothing on it is a dead end: every row is either fixable (retry it, sometimes after you address whatever tripped it up) or safe to remove (discard it). A document never sits unprocessed without you being able to see exactly why.

Where to find it

Failed uploads lives at /data/failed. It does not have a permanent row of its own in the sidebar. You land on it three ways:

The upload tray. Click the ingestion progress icon in the top bar (the small activity indicator that tracks documents moving through the pipeline). Open it and any recent failures are listed there, under "Ingestion status." Click a failed entry and you land on this page directly.
A notification. When a document exhausts its retries, Verinode sends a notification headlined "Couldn't process [filename]" with an Open Failed Uploads button that goes straight here.
The Vault badge. Under My Data in the sidebar, the Vault row carries a small number badge combining documents waiting in your review queue with documents that have failed outright. While My Data is collapsed, that same combined count rolls up onto the section header, so the number is visible even when Vault itself isn't expanded.

Failed uploads is the sibling of the review queue: the review queue holds documents that processed successfully but need you to confirm an uncertain match, Failed uploads holds documents that did not process at all.

Why a document ends up here

Every document you send in becomes a row in Verinode's ingestion queue, tagged with where it came from: Email, Upload, Photo, Paste, Bulk, Voice, or Shared Folder. A background process checks that queue every couple of minutes and works through whatever is waiting.

If an attempt fails, Verinode does not mark the document dead right away. It backs off and tries again:

After the first failure, it waits roughly 30 minutes before a second attempt.
After the second failure, it waits roughly 90 minutes before a third and final attempt.
If the third attempt also fails, the document stops retrying on its own and appears on this page.

That is the retry limit the page's own subhead refers to: "Documents that hit the retry limit during processing. Retry sends them through the pipeline again. Discard removes them permanently." A document showing up here has already had three real chances before you ever have to look at it.

Note

A document does not need to be broken to land here. A rate limit, a slow storage read, or a passing AI provider error can trip an attempt just as easily as a genuinely corrupt file. That is exactly why Verinode retries automatically before asking you to step in, and why Retry alone is often all a failed item needs.

Every element on the page

Page header. "Failed uploads," with the subhead above it, always visible whether the list is empty or full.

The list. One row per failed document, most recent failure first, up to 100 at a time. Each row shows:

Document label. The filename if one exists, otherwise the email subject line, otherwise "Untitled document" when neither is available (typical for a pasted note or a voice capture that never had a file name).
Source, time, attempts. A single meta line reads, for example, "Email · 2h ago · 3 attempts." Source is humanized from the channel the document arrived through: Email, Upload, Photo, Paste, Bulk, or Shared Folder. Time is relative, "just now" for under a minute, then minutes, then hours, then days as the failure ages. The attempt count only shows when it is above zero, which in practice is every row here, since a document only reaches this page after multiple failed attempts.
The failure reason, in red text under the meta line, capped at two lines. It always has two parts: a short classification of what went wrong, followed by a plain next step. Verinode sorts every failure into one of these categories rather than showing a raw error stack:

| You will see | What it means | What to do | |---|---|---| | Processing timed out | The document took too long to process in one pass. | Try again, large or complex documents sometimes need a second pass. | | Rate limit hit | A processing provider was temporarily throttled. | Try again in a few minutes. | | Could not parse the document | The file's structure could not be read. | Re-upload the document or convert it to PDF first. | | AI extraction failed | The extraction step itself failed. | Try again, this is often a transient error. | | Could not read the uploaded file | The stored file could not be retrieved. | Re-upload the document. | | The extracted data didn't pass validation | Data came out, but it failed a required check. | Open the document and check for missing dates or amounts. | | Authentication issue | A credential or session problem interrupted processing. | Sign out and back in, then try again. | | Internal processing error | An unclassified internal error occurred. | Engineering has been notified. |

Heads up

Verinode never shows you the raw error text or echoes content back out of your document. Raw LLM failures sometimes surface fragments of the document itself, a dollar figure, a name, a line item, and that is not something that belongs in a shared, team-visible failure log. Every error is sorted into one of the categories above before it is ever stored, so what shows on this page never leaks invoice details or claimant names, even though everyone on your team with access can see this list.

Discard and Retry. Every row ends with two buttons:

Discard removes the document from the queue for good. Clicking it asks you to confirm: "Discard this upload? This cannot be undone." Once confirmed, the row and its failure record are gone. Use this for documents you do not actually need: duplicates, junk mail forwarded by mistake, a test file.
Retry puts the document back at the front of the normal queue. It resets the attempt count to zero, clears the stored error, and picks the document up again on the pipeline's next pass, typically within a couple of minutes. If the cause was transient (a rate limit, a timeout, a momentary AI error), Retry alone is usually enough. If the cause was structural (an unreadable file, bad formatting), fix that first: convert the file to PDF, re-send it, then discard the old failed row so you are not tracking the same document twice.

Both buttons show a loading state while the action runs, and disable the other button so you cannot fire off a discard and a retry on the same row at once. If an action itself fails outright (a network hiccup, a permissions issue), a short error message appears under the buttons and you can try again.

Empty state

When there is nothing here, the page reads: "Nothing here. Failed uploads appear after Verinode has tried three times and given up." Below that is a Back to Vault link to /data. An empty Failed uploads page is a good sign: every document you have sent in has either processed successfully or is still working through its retries.

What happens if you do nothing

A document you neither retry nor discard is not lost or silently deleted. Verinode keeps failed documents on file for a long window so you have plenty of time to notice and act, well beyond a normal working cadence, after which they roll off automatically along with other terminal, audit-only ingestion records. There is no upside to leaving one sitting here: retrying costs a click, and discarding something you genuinely do not need keeps the list meaningful for the rows that still need a decision.

1Open Failed uploads from the notification, the upload tray, or the Vault badge under My Data.
2Read the red reason line under the document, it names what went wrong and what to try.
3If the cause looks transient (timed out, rate limited, a passing AI error), click Retry. It goes back into the normal queue with a clean slate.
4If the cause is structural (could not parse, could not read the file), fix the file first, convert it or re-export it, send it back in, then Discard the old failed row.
5If the document was never needed (duplicate, spam, a test), click Discard and confirm.

Data sources

1.Your uploaded, forwarded, and connected documents. Your business.
2.Verinode's ingestion pipeline (extraction, validation, and retry logic). Verinode processing.