The CSV Export Is a Release Gate, Not a Save Button
A CSV that leaves a document workflow and enters bookkeeping, purchasing or a machine import stops being a draft: those rows become the record. Yet in many small teams the decisive step is still one click, taken before anyone has confirmed that every required field can be traced back to a page in the source document. Skavio Flow's output model — structured fields alongside source evidence and review warnings — makes a stricter habit possible. The point is not to trust the file more, but to define, in advance, which rows are allowed to leave.
Incomplete evidence rarely announces itself
Evidence gaps seldom look like failures. They look like ordinary spreadsheet rows: a plausible total, a vendor name spelled consistently across the batch, a line-item table that survived OCR with two columns quietly shifted. A CSV is especially unforgiving here because it flattens context. A cell that was never found and a cell that was deliberately left empty can render identically, and the page reference that would tell them apart is usually not part of the file. That is why the review question is not “does the export look right?” but “can I show where each required value came from?” The distinction matters most for the fields that downstream systems treat as keys: invoice numbers, supplier identifiers, dates, currency labels, tax amounts and line-item totals.
- Identify the required fields first, then check evidence for those fields — a complete-looking sheet with an untraceable invoice number is still incomplete.
- Compare extracted totals against the sum of extracted line items rather than reading the header total in isolation.
- Treat shifted or merged table columns as a source-quality problem, not a formatting problem to be patched later in the CSV.
- Check dates, totals and line items against the original document; Skavio's Flow guidance treats that review as required before downstream use.
Three states, decided before anyone exports
A release gate works only if the outcomes are named in advance. Before a batch is approved, each document should resolve to one of three states: block, hold or approve. Block means a required field has no traceable source reference, or the source page is unreadable in the region that matters. Hold means the value exists but an open warning or ambiguity needs a second reader. Approve means every required field ties to a specific document and page, and every warning has been reviewed and dispositioned — corrected, accepted with a note, or escalated. The value of writing this down is consistency: two people reviewing the same batch should reach the same decision, and a rejected document should not quietly reappear in the next export because nobody recorded why it was stopped. Note that this is a recommended review discipline, not an automatic completeness detector inside the product; the judgement stays with the reviewer.
- Block: required field missing, unreadable, or not attributable to a page in the source document.
- Hold: value present but an unresolved warning or an ambiguous label (a tax column, a unit, a reference format) requires a second opinion.
- Approve: evidence located, warnings reviewed, and the decision recorded with the reviewer's name and date.
- Record the reason for every block and hold, so the same document is not re-litigated from scratch in the next batch.
Read warnings as prompts, not as verdicts
Flow surfaces review warnings alongside extracted output, and the temptation is to treat them as a pass/fail signal. They are not. A warning is an invitation to look at the source; its absence is not a certificate that everything was captured. What can be verified depends on the document itself. Flow reads embedded PDF text locally, uses OCR for scans, and applies the configured model to structured extraction — three different paths that can fail in different ways. A text-layer PDF can still contain a malformed table; a scan can lose a decimal separator; a clean scan of a poorly printed original can produce confident-looking nonsense. Treating the warning list as the whole review shortens the process in exactly the cases where it should slow down.
- Open the source evidence for a sample of approved rows, not only for the rows that triggered warnings.
- When a warning is resolved by correction, keep the note — a silent fix leaves the next reviewer with no history.
- Treat the document type as part of the risk assessment: scanned pages and mixed batches deserve a broader sample than clean digital invoices.
- Do not convert an ambiguous label into a decision; ambiguous tax or currency fields belong on an exception list.
Corrections belong upstream of the file
There is a quiet failure mode in document workflows: the export is wrong, so someone opens the CSV and edits a cell. The file is now correct and the evidence is gone. Skavio Flow supports a different order of operations. In a verified acceptance run on 2026-10-01, two synthetic PDF invoices were extracted and exported, and a scalar correction regenerated the results without starting a second extraction job. The editorial lesson from that run is about sequencing, not about extraction quality: fix the field while the page is still on screen, then regenerate. The correction stays attached to the document it belongs to, the reviewer can see what changed, and the export is a product of the review rather than a patch applied after it. It also avoids the more expensive variant of the same mistake — re-running an entire batch because one value was wrong.
- Correct at field level with the source visible, then regenerate the output.
- Avoid hand-editing the CSV; an edited cell with no page reference is indistinguishable from an invented one.
- Where a correction changes a total, re-check the affected line-item sum before approving.
- Keep the corrected result and the pre-correction version together when the batch feeds an auditable process.
The file lands; the trail should survive it
CSV is a good handoff format because it is plain, portable and machine-readable. It is a poor evidence format for the same reasons: rows lose their page, their document identity and their review history. Flow produces XLSX with separate document and line-item worksheets, plus JSON and CSV, alongside source evidence. For any batch where someone may later ask why a figure was accepted, export in a form that keeps the document and row identifiers attached — or preserve a mapping between exported rows and the source documents. The decision to release should also have an owner. A gate that nobody signs is a formality, and a CSV approved by nobody in particular is the same as one approved by accident.
- Prefer a workbook with document and line-item worksheets when reviewers need to see structure, and CSV when a downstream system needs flat rows.
- Preserve document identifiers, page references and review notes next to the export, not in a separate folder nobody opens.
- Name the approver and the approval date for each released batch.
- Treat the export as an input to a controlled import, not a completed accounting entry; do not assume an ERP posting step.