One Queue, Two Kinds of PDF: Handling Mixed Scanned and Text-Based Invoices in Skavio Flow
Most invoice backlogs are not purely digital or purely scanned. A single supplier folder will hold a selectable PDF from one vendor and a phone photograph of a supplier invoice from another, and the team handling them often splits into two informal processes — one tool for text files, another for scans, two sets of field names, two review habits. Skavio Flow supports a single review workflow for mixed input: the same custom fields, the same source evidence and the same human checks before anything is exported to XLSX, CSV or JSON.
The input paths differ; the review surface can stay shared
Inside Skavio Flow, the technical difference between a digital invoice and a scanned one is handled at the reading stage rather than at the process level. For PDFs, embedded text is read locally. Pages that carry no usable text layer are routed to Worker Fabric OCR. Structured extraction then runs with the configured OpenAI model against the fields the company has defined. The practical consequence is that a mixed batch can be reviewed against one set of column names rather than as two separate exports that someone has to reconcile by hand afterward. The split still exists; it is contained inside the pipeline instead of being duplicated in your spreadsheet.
- Embedded-text PDFs: the existing text layer is read locally before extraction.
- Scanned pages or images: OCR runs through Worker Fabric to produce machine-readable text.
- Both routes then feed the same structured extraction step and the same output formats.
- The reading route changes; the need for human review remains.
Define the fields once, then reuse them across the batch
A common source of mess in mixed intake is naming. If the digital lane calls a field "invoice_no" and the scanned lane calls it "Invoice Number", the merged sheet needs manual repair before it can be used. Skavio Flow uses custom fields and saved company workflows: field definitions can be kept with the workflow, so a new document of either kind can be extracted into the same structure. This matters most for recurring supplier formats, where the same vendor sends the same layout every month — one page in March, three pages in April with a different table break. The workflow can keep field names stable even when the page count and layout change.
- Decide header fields and line-item fields separately, and name them once.
- Keep references distinct: contract reference, order reference and invoice reference are not interchangeable.
- Treat saved workflows as the durable asset — they can carry field definitions into future batches.
- Keep the intake decision explicit: confirm which documents belong in the batch before extraction.
What the review step is actually for
Skavio Flow returns source evidence and review warnings alongside extracted values, which supports a comparison-based review rather than a pure spot check. The fields most worth confirming are the ones where an OCR pass and an extraction pass can plausibly disagree: dates written in different regional orders, totals that appear both in a header and as a sum of line items, quantities with ambiguous units, and tax labels. A header total that does not match the sum of the visible line items is a review exception, not something to smooth over. The same applies to VAT and currency labels: they should be flagged for a human, not resolved by the tool, because deciding what a tax line means is an accounting judgement rather than a data-entry one.
- Check dates, totals and line items against the source — these are the fields explicitly in scope for review.
- Compare any reported header total with the line-item sum before approving.
- Treat currency and tax-label ambiguity as an exception to be described, not silently corrected.
- If the source evidence is incomplete, the document should not become an approved ledger source.
Corrections without rerunning source extraction
A frequent argument for splitting text and scanned workflows is that corrections are easier when the two lanes are separate. In practice, the correction step is where mixed batches cost the most attention, so it is worth being precise about what Skavio Flow does and does not promise here. In a dated internal acceptance test on 1 October 2026, two synthetic PDF invoices were extracted and exported, and a scalar (single-value) correction regenerated the results without a second job. That is a record of one internal test with synthetic documents, not a customer reference and not a claim about time saved. A practical review routine is to correct the reviewed value, regenerate the results, and keep the original file as the reference point.
- Review corrections in the context of the source evidence before export.
- A scalar correction in that internal test regenerated results without a second job.
- Keep the original file alongside the corrected output so a reviewer can trace a value back to its source.
- Internal synthetic tests are not customer testimonials or independent benchmarks.
Choose the export format after review, not before
Output format is an operational decision, and it is better made once the batch has been reviewed than at intake. Skavio Flow produces an XLSX workbook with document and line-item worksheets, plus CSV, JSON, source evidence and review warnings. For a finance handoff where someone will read and annotate, the workbook is usually the right artefact. For a machine-readable handoff into an internal tool, CSV or JSON is cleaner, provided the receiving system's expectations around decimal separators, date formats and currency labels have been checked first. None of these exports implies automatic posting to an accounting system; the reviewed file remains a draft until a person approves it in the destination system.
- XLSX: document-level and line-item worksheets for human review and annotation.
- CSV or JSON: structured handoff for internal tooling, subject to the receiving system's format rules.
- Source evidence and warnings are part of the result and belong in the review record.
- The reviewed export is a handoff draft; automatic ERP posting is not claimed.