Failed Uploads: Retry or Discard

Every document you hand Verinode (an upload, a forwarded email, a bulk import, a photo) goes into a processing queue. IQ reads it, extracts the data, and files it into the right place: an invoice,…

5 min read·Updated July 13, 2026
On this page

What this page is

Every document you hand Verinode (an upload, a forwarded email, a bulk import, a photo) goes into a processing queue. IQ reads it, extracts the data, and files it into the right place: an invoice, a job, a client record. Most documents clear on the first pass. Some do not, and Verinode does not give up on the first miss. It automatically retries a failed document twice more, waiting longer between each attempt, before it stops trying on its own.

Failed uploads is where those documents land once Verinode has exhausted its automatic retries. Nothing here has been silently dropped. It is parked, waiting for you to tell Verinode whether to try again or let it go.

Where to find it

Failed uploads lives at /data/failed, one level under Vault in the My Data section of the sidebar. There is no separate top-level nav entry for it. You land there one of two ways:

  • Click a failed item in the upload tray (the processing indicator near the top of the app). Failed items are listed there right under anything still in flight, above completed ones, so they surface before you have to go looking for them.
  • Click a "Processing failed" notification from the bell. Verinode fires one of these the moment a document exhausts its retries: a single failure reads "Processing failed: [filename]," a batch reads "N documents failed processing," and both link straight here.

The Vault nav item itself carries a badge with the combined count of failed uploads and documents waiting in your review queue, so if that number is up, some of it may be sitting on this page.

What each row shows

The page lists your failed documents newest first, up to 100 at a time. Each row shows:

  • Document name. The filename if there is one, otherwise the email subject line it arrived under, otherwise "Untitled document."
  • Source and timing. Where it came from (Upload, Email, Bulk, Photo, depending on how it reached Verinode) and how long ago it landed here, shown as "just now," a number of minutes, hours, or days.
  • Attempt count. "3 attempts" in almost every case. Three failed attempts is exactly the threshold that moves a document here (Verinode tries once, then twice more with a growing wait in between), so by the time you see a row, it has already had three tries.
  • The reason it failed, in red text under the filename. Verinode never shows you the raw error text or echoes back content from inside the document itself (an extraction error can otherwise quote a dollar figure or a name straight out of the file, which is not something the rest of your team should see on a shared failures list). Instead you get one of a fixed set of plain-language reasons, each paired with what to do about it:

- Processing timed out. Try again, large or complex documents sometimes need a second pass. - Rate limit hit. Try again in a few minutes. - Could not parse the document. Re-upload it or convert it to PDF first. - AI extraction failed. Try again, this can be a transient error. - Could not read the uploaded file. Re-upload the document. - The extracted data didn't pass validation. Open the document and check for missing dates or amounts. - Authentication issue. Sign out and back in, then try again. - Internal processing error. Engineering has been notified.

Retry or Discard

Every row carries two buttons.

Retry puts the document back at the front of the processing queue: its attempt count resets to zero and it gets a full three fresh tries. Use it when the reason is something that plausibly clears on its own (a timeout, a rate limit, a transient AI error) or when you have fixed the underlying problem (converted a scan to PDF, re-uploaded a file that failed to read). If the same root cause is still there, an immediate retry will most likely fail the same way again. For Could not parse the document or The extracted data didn't pass validation, fix the file first (re-upload as PDF, or open the source document and confirm the dates and amounts are actually present and legible) rather than retrying the same file as-is.

Discard deletes the row permanently. Verinode asks you to confirm ("Discard this upload? This cannot be undone.") because there is no undo: the document is gone from the queue and nothing gets filed from it. Discard the documents you know you do not need processed, duplicates, test uploads, anything superseded by a later, cleaner file.

Both buttons show a loading state while the action runs and disable the row until it resolves, so you cannot double-click into two competing requests. If either action fails outright (a permissions issue, a dropped connection), the page shows the error inline under the buttons and the row stays exactly where it was.

Empty state

When there is nothing to review, the page reads:

"Nothing here. Failed uploads appear after Verinode has tried three times and given up."

with a link back to Vault. This is the healthy state. It means every document you have sent through has either processed cleanly or is still working its way through its automatic retries; nothing has needed your judgment call yet.

Note

This page shows only documents tied to your operator account. A document that fails for a teammate on a shared Vault shows here too, since Failed uploads reflects everything in your account's queue, not just what you personally uploaded.

Tip

If you are seeing the same reason repeatedly on a specific document type (say, every scanned invoice from one vendor hits "Could not parse the document"), that is worth fixing at the source rather than retrying each one: re-scan at a higher resolution, or ask the sender for a native PDF instead of a photographed page.

Heads up

Discard has no undo. If you are not sure whether a document matters, retry it once or leave it here rather than discarding. A document you are unsure about costs you nothing sitting in this queue; a wrongly discarded invoice is gone.

Was this helpful?