Two Pairs of Eyes: A Maker–Checker Review Workflow in Skavio Flow
Extraction produces a draft, not an approved ledger source. The gap between the two is a review step — and a review step is only as good as its ability to point back at the page a value came from. This guide sets out a two-person workflow for Skavio Flow: a preparer runs the extraction and records every uncertain field against the source evidence and review warnings Flow already returns, while a second reviewer independently checks headers, dates, totals, currencies and line items before an export leaves the workspace. It is a discipline you build on top of the product, not a certification the product issues. This is an operating-control guide, not a compliance certification or an offer of immediate purchase.
The division of labour: preparer and checker
Skavio Flow is live on web and API and turns invoices, orders, scans and text into reviewed XLSX, CSV and JSON, using custom fields and saved company workflows. Its outputs include an XLSX document worksheet and line-item worksheets, CSV, JSON, source evidence and review warnings. The two-person split here is procedural; do not treat it as a native permission rule unless your workspace has been separately verified to enforce one. One person runs the job and documents what they could not settle; a second person reads the same evidence and owns the acceptance decision. Write the split down, name the two people, and keep your own log if you need to show who approved what and when.
- Preparer: uploads the source documents, selects the saved workflow and custom field set, and records every field flagged by review warnings.
- Reviewer: re-reads the stated values against the source evidence and accepts, corrects or returns the document.
- Shared rule: the person who extracted a document does not also sign it off, so a second reading actually happens.
Preparer: extract, then record what remains uncertain
Flow's processing path shapes how the preparer works. Embedded PDF text is read locally, scans go through Worker Fabric OCR, and structured extraction uses the configured OpenAI model. Each of those steps can leave a field ambiguous, which is why the output carries review warnings and source evidence rather than a bare table. The preparer's discipline is simple: never settle an ambiguity by typing a plausible value. Record it instead. A four-column note — field name, page or evidence reference, the warning or observation, and the decision the reviewer needs to make — keeps a batch moving without hiding doubt. On 2026-10-01, a verified acceptance run extracted and exported two synthetic PDF invoices and showed that a scalar correction at review regenerated the results without a second extraction job. The synthetic invoices are illustrative, not customer references. That note covers scalar corrections in that run; it is not a statement about every field type.
- Log the evidence pointer, not just the value: page number, surrounding label, and what made the field uncertain.
- Track document quality separately from data quality — a tidy table can still sit on an unreadable scan.
- Leave unresolved fields visible in the draft rather than filling them from a similar earlier invoice.
Reviewer: a checklist that does not depend on trust
The reviewer's job is not to repeat the extraction. It is to test the draft against the document. Start with identity: do the supplier name, invoice or order number and reference format match the page? Then dates — issue date and due date, and whether the day/month order is the one the supplier actually used, which matters in mixed German and English paperwork. Then money: the currency label, the header total, and whether that total equals the sum of the extracted line items. Then tax: which lines carry which rate, and whether the document itself supports the split. Finally coverage: is there evidence behind every value about to be accepted? A field with no traceable evidence is a return, not a correction.
- Supplier identity, invoice or order number, and reference format.
- Issue and due dates, including the day/month convention in use.
- Currency labels, and whether any conversion has been applied or assumed.
- Header total against the sum of extracted line items.
- Tax lines as the document states them, not as the reviewer expects them.
- Evidence coverage for every accepted field; unreadable evidence means re-scan or reject.
Corrections that keep their receipt
A correction is only useful to the next person if it stays attached to its origin. When the reviewer changes a scalar value, the corrected export should still be read alongside the evidence that justified the change — otherwise the workbook records an opinion and loses its argument. Keep a correction log beside the export: document identifier, field, original value, corrected value, evidence reference, reviewer, date, and whether the change fixed an extraction error or clarified an ambiguous label. The verified Flow acceptance supports regenerating exports after a scalar correction without rerunning extraction, which keeps the source stable and the log short. It does not cover structural edits to line items, and do not assume Flow provides immutable audit logs or e-signatures; if your process needs those, they come from your own systems.
- Log original and corrected values together, with the evidence reference that settles the difference.
- Distinguish an extraction error from an ambiguous source label; they need different follow-up.
- Treat line-item restructuring as a separate case from a scalar correction, and route it accordingly.
Where the process stops
Two things can be said plainly. First, the review is an operating control, not a compliance certification: it does not constitute segregation-of-duties enforcement in Flow unless separately verified, and it does not turn an export into an approved accounting entry. Flow produces exports and review outputs; posting into an ERP remains your own step. Second, extraction quality depends on the document. Scanned and low-quality pages can produce fields that should be rejected or re-scanned rather than corrected, and no workflow design removes that possibility. Flow uses the shared Pricing V2 credit wallet: 29 credits per page, minimum 29 credits per document. A 1,000-credit company trial is subject to current signup policy and backend eligibility. Prepaid credits do not expire; monthly credits roll over. This article is informational, so confirm current availability and the live quote in your workspace before planning a batch; the live backend quote remains authoritative for the final job price.
- Extraction quality varies with document type; review warnings are inputs, not decoration.
- Do not claim automatic ERP posting or accounting approval; this workflow does not provide a compliance certification.
- Confirm current availability, the live quote and trial eligibility before a batch, because published rates are a snapshot.