Define the accounting unit
Decide whether an example represents a complete invoice, one page, or a line item. Preserve the relationship between those units. A model that identifies a total correctly can still assign it to the wrong invoice when attachments contain several documents. Include document boundaries in the annotation plan.
Separate source text from normalized values
Keep the observed currency symbol, date string, and supplier name alongside any standardized output. A date such as 03/04/25 requires a stated interpretation policy. Define how credit notes, negative amounts, missing purchase order numbers, and tax-inclusive totals should appear rather than letting annotators invent conventions.
Sample difficult layouts deliberately
Request a coverage table for multi-page invoices, scanned pages, skew, small print, handwritten additions, and repeating headers. Count vendors as well as pages. Thousands of nearly identical invoices from one template do not test unfamiliar layouts. Reserve some suppliers or layout families for evaluation.
Inspect errors at the field level
Review invoice number, amount, currency, and line-item association separately. Ask for evidence locations so reviewers can distinguish recognition failures from mapping mistakes. Before discussing a larger sourcing project, send Fiund an example schema, excluded document types, and the permitted handling of account and contact details. For example, include an invoice whose subtotal is repeated in a payment slip. The review should reveal whether the expected label points to the invoice total or a duplicate-looking amount elsewhere. Record that decision in the schema so the same visual ambiguity is handled consistently across vendors and future batches.
Review checklist
- Choose document and line-item identifiers
- List required fields and normalization rules
- Request vendor and layout coverage counts
- Specify sensitive-field handling before sample review