Document Types

Every document is automatically classified into a canonical type from a 529-type ontology (e.g., "Employment Contract", "Invoice", "Bill of Lading (Ocean)"). Types are resolved automatically — you never create them manually. The classifier works across all languages: a German *Arbeitsvertrag* and an English *Employment Contract* map to the same type.

Documents sharing the same ontology type are automatically merged into one document type. When a new canonical type appears, it is auto-created with ontology metadata including category, subcategory, and typical fields. Unresolvable documents are assigned "Unclassified Document" — they can still be processed and extracted, but the platform cannot map them to a specific type in the ontology.

Classification is verified in a two-step process. First, Document AI OCR produces an annotation with a free-text type label during the OCR pass. Then, a type resolution step verifies that label against the actual document content. If the label and content disagree — for example, a German *Arbeitsvertrag* incorrectly labelled as "Service Agreement" — the system trusts the content and resolves the correct canonical type. This ensures accurate classification regardless of the OCR engine's labelling bias.

Document types drive several downstream features. The platform auto-generates a schema for each document type, pre-populated with fields discovered from documents of that type. Routing rules can be configured per document type to automatically assign schemas or trigger jobs when new documents arrive. The Field Registry tracks which fields appear in which document types, building a cross-type knowledge graph over time.

Example Ontology Types

• Financial — Invoice, Purchase Order, Credit Note, Bank Statement, Tax Return
• Legal — Employment Contract, Non-Disclosure Agreement, Lease Agreement, Power of Attorney
• Logistics — Bill of Lading (Ocean), Commercial Invoice, Packing List, Certificate of Origin
• Healthcare — Medical Record, Lab Report, Insurance Claim, Prescription
• Corporate — Articles of Incorporation, Board Resolution, Annual Report, Meeting Minutes

Working with Document Types via API

The REST API exposes classification results so you can build type-specific processing pipelines. GET /v1/document-types lists the document types resolved for your workspace, ordered by document count, and GET /v1/document-types/ontology returns the canonical category summary the classifier uses. The type is assigned automatically during classification and included on every document response as type_detected, so you can route processing logic based on the type without any manual tagging: for example, sending invoices to a financial reconciliation workflow and employment contracts to an HR onboarding integration.

curl https://api.talonic.com/v1/document-types \
  -H "Authorization: Bearer $TALONIC_API_KEY"

{
  "data": [
    {
      "id": "dt_1a2b3c",
      "name": "Invoice",
      "document_count": 89
    },
    {
      "id": "dt_4d5e6f",
      "name": "Employment Contract",
      "document_count": 34
    }
  ]
}

The classification system works particularly well with mixed-document uploads. When you upload a ZIP archive or folder containing invoices, contracts, and receipts, each document is classified independently. You can then use type-based filtering to process each category through its own schema and job pipeline, even though they were uploaded together. This makes it practical to ingest heterogeneous document batches without pre-sorting.

Behind the scenes, classification uses a two-step verification process. First, Document AI OCR produces a free-text type label during the initial processing pass. Then, a type resolution step verifies that label against the actual document content by checking it against the full 529-type ontology. If the label and content signals disagree — which commonly happens with multilingual documents or ambiguous formats — the system trusts the content and resolves to the correct canonical type. For example, a German Arbeitsvertrag might initially be labelled as "Service Agreement" by the OCR engine, but the content-based resolution correctly identifies it as "Employment Contract" based on the actual text.