AI Document Processing and Extraction

Native PDFs, scanned PDFs, TIFF images, JPEGs, PNGs, Word documents, Excel files, CSVs, HTML, email with attachments, and fax-to-email. Handwritten content is supported through Textract's handwriting model with accuracy that depends on handwriting clarity (we publish the accuracy by document type during calibration so the team knows where human review is required). Multi-page documents with mixed content (native text on some pages, scanned images on others, embedded spreadsheets) are fully supported. Password-protected documents require the password in advance. Documents under 100 pages process in under 30 seconds; larger documents stream through without timeout.

Low-quality scans go through preprocessing (deskew, denoise, contrast enhancement) before extraction. If the post-preprocessing quality is still below a calibrated threshold, the document routes to human review with the raw image attached and the extraction fields pre-populated with whatever the system could read. Unusual layouts are handled through a layout-aware vision model rather than a template-matching OCR tool. When the layout is truly novel, the system flags the document for manual handling and, if a pattern recurs, we add a new template during the monthly configuration review. Nothing processes silently with poor data.

A new document type with a consistent format takes 1-2 weeks: defining the extraction schema, providing 20-50 sample documents for testing, running accuracy measurement, and calibrating confidence thresholds. Highly variable document types (e.g. loss runs that vary dramatically by carrier) take longer, typically 3-4 weeks, because we need enough samples to cover the variation. We assess this during discovery using a sample of your actual documents rather than estimates. Document types that share a common structure (e.g. all ACORD forms) share configuration work, so types 2, 3, 4+ are incrementally faster than the first.

Documents below the configured confidence threshold route to a human review queue with the extracted data pre-populated and the source document displayed alongside. The reviewer corrects any errors and the correction writes back to the training signal for that document type. Nothing is dropped. The review queue is prioritized: oldest first, with an SLA on queue depth so documents don't sit indefinitely. Reviewer throughput is typically 3-5x what it was before the agent because they're correcting pre-populated fields rather than keying from scratch. The fraction of documents requiring human review usually drops from 100% to 10-20% within 60 days as the agent learns.

Edge cases fall into three buckets. Documents of a type the system doesn't know (new state form, new broker template) route to manual classification and processing, and if the pattern recurs we add it as a new configured type. Documents with novel fields within a known type are extracted with lower confidence and flagged for human review, and the reviewer's correction can either be one-off (rare) or feed a schema update (common). Documents with unusual content within standard fields (e.g. a multi-currency amount written in a format the parser doesn't handle) are flagged at the field level rather than rejecting the whole document. The agent never silently guesses on edge cases.

Validation rules catch the majority of errors before they reach downstream systems: range checks, cross-field consistency, reference-data lookups. When an error passes validation but is caught by a reviewer or downstream user, the correction writes back with the reason code, and the system tracks error rate by document type and field. If error rate on a field exceeds 2%, the field is moved to mandatory human review until the root cause is fixed (usually a prompt or schema update). Every decision is reversible: we log enough context to trace a wrong extraction back to its source document and reprocess with an updated model or schema.

Yes, with some trade-offs. For on-premise or VPC-only deployments we replace cloud-hosted model APIs with self-hosted alternatives: open-weights models via vLLM or TGI, Tesseract plus a fine-tuned layout model for extraction, or Azure OpenAI in a customer-controlled subscription for organizations that accept Azure as the boundary. Accuracy on the open-weights path runs 3-5 points below the Claude Sonnet 4.5 cloud path in our benchmarks, which matters on low-confidence edge cases but rarely on high-volume standard documents. For truly air-gapped environments we've deployed on Nvidia A100 clusters with no internet egress. The configuration work is 20-30% heavier because you lose model-provider updates.

Every document processed writes a record to an append-only log: document ID, source, timestamps, classification decision and confidence, extraction JSON with per-field confidences and bounding boxes, validation results, human reviews if any, and the downstream system response. The log exports to CSV, Parquet, or direct push into your audit tool (AuditBoard, Workiva, TeamMate). For regulated data we add field-level PII redaction with a key-escrow mechanism so auditors can retrieve specific records under controlled access. Several insurance clients use the log to answer regulator questions about submission handling consistency, where previously that answer required manual sampling across paper files.