Use case · Invoices

Invoice processing, from file to fields.

Invoice processing starts with reliable data extraction. Configure vendor details, invoice numbers, dates, line items, taxes, and totals as structured JSON, then validate the result before your AP or ERP workflow uses it.

What invoice processing includes

Accounts payable teams need more than a text transcript. They need the right invoice number, supplier, currency, amounts, and line-item associations in the format their receiving system accepts. Vendor layouts, tax breakdowns, credit notes, and multi-page tables make that mapping difficult. Cogneris supplies the document extraction step; the full processing workflow combines that output with your checks, review decisions, and business systems.

Use the AI document processing overview for the general journey and the data extraction API for integration details. This page focuses on the choices specific to invoice data.

Configure an invoice extraction schema

  • Header fields — request supplier and customer names, invoice number, issue date, due date, purchase-order reference, and currency when present.
  • Amounts and taxes — define subtotal, tax, discounts, shipping, and total separately so your application can compare the arithmetic.
  • Line items — describe the row fields you need, such as description, quantity, unit price, and line amount. Test wrapped descriptions, repeated headers, and tables continued across pages.
  • Missing information — decide how the receiving system handles an absent PO number, unclear tax identifier, unreadable amount, or credit note. Avoid filling a gap with an assumed business value.

The schema is configured for your tenant; the list above describes possible requested fields, not a fixed response guaranteed for every invoice. Accepted file types and limits follow the document extraction API contract. Test the actual source files you intend to send, including scans and image quality problems.

Invoice fields as JSON

This synthetic, shortened response fragment illustrates three requested fields. Field names inside data.metadata are defined by the template. Confidence values use the API's 0–100 scale; these sample scores are illustrative, not a benchmark.

{
  "data": {
    "metadata": {
      "invoiceNumber": { "value": "INV-1042", "confidence": 96 },
      "total": { "value": "125.50", "confidence": 94 },
      "currency": { "value": "USD", "confidence": 98 }
    }
  }
}

The complete response uses the documented service envelope. Source locations, when returned, help a reviewer find the supporting page or area; they may be absent for some fields. Do not treat a high confidence score as an approval decision or assume that a missing location proves an extraction error.

From capture to the receiving system

  • Capture — collect the invoice in your application and check file completeness. Inbox ingestion, attachment handling, and vendor-specific routing are integration decisions.
  • Extract — submit the file with the appropriate configured template. Preserve your own invoice reference so results can be associated with the input.
  • Validate — compare subtotal, tax, and total; normalize dates and currency explicitly; check required fields against your business rules.
  • Review exceptions — route ambiguous values through your application's review policy or an agreed tenant workflow with configured manual-review phases.
  • Deliver — map accepted fields to the ERP or AP record, record the result of the write, and prevent a retry from creating a duplicate transaction.

Keep business decisions explicit

Purchase-order and goods-receipt matching require access to those records and customer-specific rules. Duplicate detection requires a defined key and a record store. GL coding requires your chart of accounts and accounting policy. These are separately scoped integration responsibilities; the extraction response does not establish that they ran.

Likewise, extraction does not release payment, automatically post an invoice, or approve it because a score exceeds a threshold. Decide who owns approval, how exceptions are resolved, and what evidence must be retained before connecting a live AP process.

Test invoices that represent the real workload

Include different vendors, languages, tax layouts, multi-page tables, credit notes, blurred scans, and invoices with missing references. Compare each requested field against a reviewed answer set. Measure line-item completeness and amount correctness separately from general text accuracy. Count review effort and failed submissions alongside operation cost. The OCR accuracy evaluation guide explains how to avoid relying on a single headline percentage.

Integration, pricing, and controls

Start with the quickstart and API examples. REST APIs and documented signed webhooks can support custom ERP integrations; confirm the delivery contract for the operation you choose. Vendor-specific mapping, master-data lookups, attachment storage, and record write-back remain part of your integration.

Review classification and extraction pricing against the number of operations your flow uses. Invoices may contain bank details and tax identifiers: check security and retention boundaries before submitting production material. Tenant retention and additional platform modules depend on configuration and contract.

Evaluate before connecting AP

Use the trial with representative documents, a defined schema, and measurable acceptance criteria. For the wider software decision, see the IDP selection guide. Related use cases include receipt extraction and bank statement extraction.

Summarize this page with an AI assistant

Open this page in an assistant with the summary prompt already written. We publish the whole site as plain text at llms-full.txt, so an assistant can read what we actually wrote instead of inferring it.

Assistants summarize, and they get things wrong. Check anything that matters against this page, or ask us directly.