File Processing Stages and What Each Status Means

The filter chips at the top of the screen — PROCESSING, REJECTED, and PROCESSED — group your files by outcome. A Status column in the grid repeats the same words per file.

• Processing — the file is either waiting to start or actively being extracted. From the screen, you cannot tell which. Both states show the same label and there is no visual distinction anywhere you can see.
• Rejected — extraction failed or the file was blocked before it started. A Notes column shows why, but it is hidden while the PROCESSING filter is active — to see rejection reasons, you have to switch to the REJECTED chip first.
• Processed — extraction finished successfully. Depending on document type, this means transactions were imported, statement periods were created, or check images were catalogued.

The frontend groups two backend-distinct states into one. A file that just finished uploading and hasn't been sent for extraction yet shows Processing. A file that's been dispatched to an external extraction service and is actively being read also shows Processing. There is no intermediate label like "Waiting" or "Extracting" that you can see on this screen — both are simply Processing until extraction finishes or fails.

While a file shows Processing, only four columns are visible: filename, upload date, size, and page count. The Notes, Txn Qty, and Completed Processing Date columns only appear once the file moves to Rejected or Processed, so a file stuck mid-extraction has no visible field where a status update or reason could appear even if one existed on the backend.

CSV files — Transaction Lists (CSV) and Check Item Lists (CSV) — are imported synchronously when you click Start Extraction. The browser waits while the work happens, so these move directly from upload to Processed or Rejected with no externally visible delay. There is no background job and no polling for these types.

PDF files — Bank Statements (PDF), Brokerage Statements (PDF), and Check Images (PDF) — are dispatched to an extraction service and processed asynchronously. Once sent, the platform waits for that service to report completion. How the platform learns a file finished depends on the extraction pathway the project is configured to use, and that configuration is not something you can see from the ALL FILES screen. One pathway posts a single callback when it finishes; the other is polled periodically because no callback exists. Either way, the file stays in Processing until the platform receives confirmation or a rejection reason.

A file can appear stuck in Processing even when extraction actually finished on the backend if the completion signal never arrived. This happens in a few specific ways:

• The callback pathway posts its completion notice once, with a 60-second timeout and no retry. If the callback address is misconfigured or the platform is temporarily unavailable when the notice arrives, the notification is lost and nothing later detects the miss. The file remains Processing indefinitely on the platform side while the extraction service considers it complete.
• A container crash or critical failure during extraction deliberately does not notify the platform at all. From the platform's perspective, the file is still working; from the extraction service's perspective, it failed and is done.
• On the polling pathway, if the project is deleted or otherwise becomes unreachable before a poll completes, the file's final state is never retrieved and no rejection is recorded.

In each of these cases, there is no self-service action that moves the file forward — the completion signal either arrives or it doesn't, and the platform has no independent way to detect that it was missed. See Is My File Stuck or Still Running? for how to tell whether a file is legitimately working or stranded, and what to send support if it appears stuck.

Files rejected as duplicates never reach Processing at all. The duplicate check runs during or immediately after upload, and a file identified as a duplicate is placed directly into Rejected with a note explaining it. See How Duplicate Detection Works for what the check actually compares, and Replacing a File That Was Rejected as a Duplicate if you need to delete and re-upload a file that was caught by it.

The type you select on the first step of the Load Evidence wizard — Bank Statements (PDF), Brokerage Statements (PDF), Transaction Lists (CSV), Check Images (PDF), or Check Item Lists (CSV) — determines everything downstream: which extraction pathway the file is routed to, what account types are offered, and what validation the file goes through.

Document type is a label you declare at upload time. Nothing opens the file afterward to confirm that its content actually matches that type. A brokerage statement uploaded as a bank statement, or a credit card statement uploaded as a check file, is evaluated as if it really were the type you selected and typically fails with a generic message that doesn't explain the mismatch.

This plausibly explains some tickets reporting files "that look the same as ones that succeeded" being rejected with messages like "document type not supported" — the successful ones may have been uploaded under the correct type while the rejected ones were mistyped, or the rejected ones contain content that subtly differs from the platform's expectations (loan account statements, CD statements, or retirement account statements uploaded as checking/savings, for instance).