Processing one invoice and processing eight hundred are not the same activity performed more times. At volume, the constraints move: what matters is no longer how well a single document is read but how the queue behaves when it is full, what happens when document 431 fails, and whether the whole batch has to be repeated because of it. This page is about running invoices in bulk without creating a second manual job cleaning up after the first.
Reads digital PDFs, scans and phone photos. Exports to Excel, CSV and JSON.
Compare the extracted fields and line items against your own document.
Upload your invoices
Drop files here or click to upload
Up to 50 files
Uploading...
A bulk upload should be a queue, not a transaction. Each document is an independent job: it is accepted, queued, processed and completed on its own timeline, and results become available as each one finishes rather than when the last one does.
That distinction has a practical consequence you will notice within the first hour. With a queue, a reviewer can start clearing exceptions from the first fifty documents while the remaining seven hundred are still working. With a transactional batch, everyone waits for the slowest document in the set, which is usually a 40-page consolidated bill from a telecoms supplier.
Parallelism is how throughput scales, and it is bounded by the service rather than by your upload. Sending a thousand documents does not make them process a thousand at a time; they are accepted immediately and worked through at whatever concurrency the queue allows. What you should expect to see is steady completion, not a long silence followed by everything at once.
In any batch of several hundred real invoices, some will fail. A file will be a password-protected PDF, a scan will be blank because someone loaded the page face down, a document will turn out to be a delivery note rather than an invoice, one will be corrupt.
The design question is what that does to the other 997. A batch that is all-or-nothing turns four failures into a repeat of the entire run, which at volume is not a minor inconvenience. It is the reason people stop using bulk upload and go back to processing documents one at a time.
The behavior to look for is per-document isolation: each failure is recorded against its own document with a specific reason, the rest of the batch continues untouched, and the failures are re-runnable as a set once fixed. "17 documents failed: 12 unreadable scans, 3 password-protected, 2 not invoices" is actionable. "Batch failed" is not.
Bulk uploads frequently contain files that are not one invoice. A scanning session produces a single PDF holding forty bills; a supplier sends a monthly pack of every invoice they issued you; someone merges a folder before uploading it because it seemed tidier.
Splitting is a document-boundary problem. The signals that mark a new document are a fresh supplier header, a new invoice number, a page numbered "1 of 3" where the previous page said "3 of 3", and a layout change. Where the signals agree, the split is safe. Where they conflict, a supplier whose continuation pages repeat the full header, for instance, the boundary is genuinely ambiguous and should be confirmed by a person rather than guessed.
The failure mode worth guarding against is a silent bad split, because it produces two invoices where there was one, each with half a line-item table and totals that do not reconcile. Arithmetic validation catches most of these before they reach your ledger.
Invoice volume is not evenly distributed and never has been. The last three working days of a month, the week after a quarter end, and the run-up to year end produce volumes several times the daily average, and they coincide exactly with the periods when the finance team has least slack.
Two things follow from that. Capacity should be sized against the peak rather than the mean, which is worth checking against your own history before choosing a plan. Pull twelve months of invoice counts by day and look at the busiest week, not the average one.
The second is that exception review, not processing, is usually the real bottleneck at peak. If your exception rate is five percent, a normal day produces a handful of reviews and month-end produces sixty. Grouping similar exceptions so one person can clear them as a set, rather than opening sixty documents individually, is what keeps the spike manageable.
Bulk upload is designed around hundreds to thousands of documents in a single submission. They are accepted immediately and queued, then processed in parallel at whatever concurrency the service allows, with each result appearing as it completes rather than after the whole batch.
Failures are isolated to the individual document. Each one is recorded with a specific reason, unreadable scan, password-protected file, not an invoice, while the rest of the batch continues, and the failed set can be re-run once the underlying problem is fixed.
Yes. Document boundaries are detected from layout signals such as a new supplier header, a fresh invoice number and page numbering that restarts. Where the signals are ambiguous, the split is surfaced for confirmation rather than made silently, because a bad split produces two half-invoices that reconcile against nothing.
Per document, no. Processing is parallel, so a batch completes far faster in total than the same documents submitted individually. What changes is that you see a stream of completions rather than an immediate single result.
Size capacity against your busiest week rather than your monthly average, and pay attention to exception review rather than processing throughput. Grouping similar exceptions so they can be cleared as a set is usually what makes the difference at peak.
Invoice processing software for teams handling steady invoice volume: automatic capture, validation rules, exception queues and clean export to your accounting system.
An invoice OCR and data extraction API for developers: asynchronous job model, webhook and polling, JSON response shape, idempotency, error handling, rate limits and a sandbox environment.
Accounts payable OCR for teams still handling paper: digitizing an invoice backlog, running a mailroom scanning process, matching scanned bills to purchase orders and archiving originals.
Invoice automation software that takes a bill from the moment it arrives to the moment it is posted. Capture, validation, approval and export, without manual data entry.
Convert PDF invoices to Excel or CSV. How to choose between one row per invoice and one row per line item, which formats survive Excel intact, and how to produce pivot-ready output.
Upload a few of your least tidy supplier invoices and compare the extracted fields against the documents. That tells you more than any feature list.
