Build the mapping layer before the spreadsheet
Recurring procurement formats are recurring only in the loose sense. The same invoice number appears as Rechnungs-Nr., Invoice No. or a reference tucked into a table header, while quantities, tax labels and totals shift position from supplier to supplier. The practical task is not to ask a system to understand every invoice in the abstract. It is to establish a small canonical schema that each supplier label maps into. Skavio Flow supports custom fields and saved company workflows, with XLSX, CSV and JSON outputs that include document and line-item worksheets, source evidence and review warnings. That makes the mapping layer the durable asset, not any single exported workbook.
Start with meanings, not supplier labels
A mapping layer begins with internal field names that mean one thing each. A supplier invoice number, a purchase order number and a credit note reference should not collapse into a single reference field just because they look similar. For example, Rechnungsnummer, Invoice No. and Beleg-Nr. may all map to a supplier_invoice_number field, but only after the document context confirms the value is an invoice number. Dates, currency, net total, tax total and gross total belong in document-level fields. Description, quantity, unit, unit price, line total and tax label belong in line-item fields. The names should be stable enough to reuse across saved workflows, while supplier-specific labels remain translations into that schema.
- One internal concept gets one stable field name, not one column per supplier wording.
- Supplier labels are mapped into the schema; ambiguous meanings become review exceptions rather than guesses.
- Document references should stay distinct: invoice number, order number and credit note reference are different concepts.
- Illustrative schema names are workflow examples, not evidence of broad extraction performance.
Separate header, line-item and evidence context
Skavio Flow's outputs include both document and line-item worksheets in XLSX, and that separation should survive the mapping decision. Header fields answer questions about the document: which supplier, which document type, which date, which currency and which totals. Line-item fields answer questions about the position: what was bought, in what quantity, at what unit price and under which tax treatment. Evidence fields answer a third question: where in the source was this value found, and what warning applies? Keeping those layers apart prevents a page reference from becoming a data value, or a header total from being mistaken for a line-item sum. It also helps keep supplier invoices, purchase orders and credit notes as distinct document contexts rather than one undifferentiated table.
- Map header fields to document-level meaning, not to a line-item row.
- Keep evidence and review-warning context visible during review instead of discarding it at export.
- Preserve document type and sign conventions explicitly; do not mix invoices, orders and credit notes by accident.
- Treat missing or contradictory values as visible exceptions, not fields to fill by inference.
Use saved workflows for repetition, then expose the exceptions
A saved company workflow is useful when a procurement format repeats: it applies a repeatable extraction setup instead of rebuilding the same field approach each time. The mapping discipline is what makes that repetition legible. For a recurring supplier, record which labels map to which canonical fields and where the format creates known ambiguity. Does the document call a value a due date or only mention payment terms? Is the tax label explicit or merely a percentage? If the source is a scan rather than an embedded-text PDF, the same schema still applies, but the review burden may be higher. Mapping should reveal those differences. It should not imply that every supplier format will map cleanly or that a low-quality scan can be accepted without human escalation.
- Use saved company workflows to repeat the extraction setup, not to pretend every supplier document is identical.
- Keep missing due dates, unclear tax labels and unreadable totals as explicit review points.
- Reject or escalate source documents whose evidence is too poor to support the mapped value.
- Do not claim automatic supplier-format detection or a visual mapping interface unless it is separately verified.
Review before export, and correct at the review layer
The export is a handoff, not an approval by itself. Before accepting dates, totals or line items, review the source evidence and review warnings that accompany the mapped fields. A supplied acceptance note dated 2026-10-01 records two synthetic PDF invoices being extracted and exported, with a reviewed scalar correction regenerating results without a second job. That supports a useful correction loop for reviewed values, but it is not a customer testimonial or a broad claim about production performance. XLSX is suitable when people need document and line-item worksheets to inspect; CSV suits a tabular handoff; JSON suits a structured application handoff. None of those outputs should be treated as automatic ERP posting. The mapping layer remains the place where meaning is made explicit, and the review step remains the place where the export is approved.
- Check source evidence and review warnings before accepting dates, totals and line items.
- When a reviewed scalar value is corrected, the supplied acceptance note records that results can be regenerated without a second extraction job.
- Choose XLSX, CSV or JSON according to the receiving workflow, not as a substitute for approval.
- Treat exports as reviewable handoffs rather than automatic accounting or ERP writes.