Document data extraction

Requirements describe capabilities the pattern needs in your environment, not the vendors you must buy. Any system that fills a requirement satisfies it — that’s what makes the catalog portable across the long tail of SMB tooling.

1. document_intake_channel

   REQUIREDREADevent

   Where documents arrive for processing. Most clients have several channels feeding the same workflow.

   DATA SHAPE

   Document files in common formats (PDF, image, sometimes Word or HTML email) with arrival metadata: source, timestamp, sender if known.
   COMMONLY FILLED BY

   • email inbox where suppliers send invoices
   • shared drive folder where scanned documents land
   • upload portal for customers or partners
   • vendor portal that pushes documents via API
   • OCR feed from a multi-function printer
2. extraction_schema_definitions

   REQUIREDREADcorpus

   What fields to extract per document type. Different document types have different schemas; the pattern needs explicit definitions, not guessing.

   DATA SHAPE

   Per-document-type field definitions: name, type, required-or-optional, validation rules, example values.
   COMMONLY FILLED BY

   • configuration maintained per document type by the engagement team
   • small admin UI for the operations team to manage schemas
   • templates derived from sample documents during build phase
3. reference_data_for_validation

   REQUIREDREADrequest

   Known-good data the extracted values get checked against: supplier list, product catalog, customer roster, GL codes.

   DATA SHAPE

   Reference tables with the canonical entities and their identifiers. Lets the pattern check that 'Acme Corp' on an invoice matches the supplier record and isn't a new supplier.
   COMMONLY FILLED BY

   • supplier master in the ERP or accounting system
   • product catalog with SKUs
   • customer database keyed by name and tax ID
   • chart of accounts
4. structured_output_destination

   REQUIREDWRITEevent

   Where the extracted, validated records land. Usually the system of record the documents would have been keyed into by hand.

   DATA SHAPE

   Structured records matching the destination system's schema, with a reference back to the source document.
   COMMONLY FILLED BY

   • bill or invoice created in the accounting system
   • purchase order record in the ERP
   • claim record in the operations platform
   • structured entry in the workflow management tool
5. human_review_queue

   REQUIREDREAD + WRITErequest

   Where low-confidence extractions go for human verification. Reviewer sees the source document and the proposed values side by side, with the uncertain fields highlighted.

   DATA SHAPE

   Document + extracted fields + per-field confidence + reviewer actions (confirm, edit, reject).
   COMMONLY FILLED BY

   • review UI built for the engagement showing document and fields side by side
   • queue inside the accounting or ERP system
   • dedicated app for the operations reviewers
6. exception_workflow

   REQUIREDWRITEevent

   Where documents that fundamentally can't be processed go: unknown supplier, malformed document, suspected duplicate, suspected fraud.

   DATA SHAPE

   Document with exception classification, evidence, and routing suggestion.
   COMMONLY FILLED BY

   • exception queue in the accounting system
   • ticket created for finance operations
   • dedicated investigation folder with notifications
7. source_document_archive

   RECOMMENDEDWRITEcorpus

   Long-term storage of original documents, linked from the structured records for audit and reference.

   DATA SHAPE

   Original files preserved with metadata: extraction date, links to created records, retention schedule.
   IF MISSING

   Compliance and audit trail are weaker; in regulated industries this is effectively required. Strongly recommend in any client with audit obligations.
   COMMONLY FILLED BY

   • document management system with retention policies
   • archived folder in the file store with structured naming
   • attachment field on the destination record