Document Reading, Parsing, and Classification in Reindeer

Overview

Reindeer document workflows are designed for real operational documents, not only clean digital PDFs. Reindeer can read business documents, parse them into structured information, classify them, and show reviewers the evidence used to support important fields.

Document processing is most useful when a workflow receives PDFs, scans, images, emails with attachments, multilingual documents, handwritten annotations, or document packets that need to be turned into reviewable cases. Depending on the agent, Reindeer can identify what each document is, decide whether pages belong together, extract the fields needed by the workflow, and route exceptions for human review.

Questions This Article Answers

• What does document processing include in Reindeer?
• How does Reindeer read, parse, and classify documents?
• How are multi-document packets handled?
• How does Reindeer use evidence, reasoning, and confidence?
• What are bounding boxes, and why do they help reviewers?
• What information should teams provide when setting up a document workflow?

Designed for Real Operational Documents

Many business processes depend on imperfect documents. A customer may send a clean PDF, a scanned image, a mixed packet of supporting documents, a document in a different language, or a form that includes handwritten notes.

Reindeer handles this by combining document reading, visual layout analysis, classification, structured extraction, evidence mapping, and review routing. This layered approach helps the workflow capture useful information when the document is readable, and escalate the case when the source is incomplete, ambiguous, or too unclear to trust automatically.

What Document Processing Includes

Document processing usually includes several related capabilities.

The exact behavior depends on the agent design, the document types, and the case schema used for the workflow.

How Reindeer Reads Documents

Reindeer uses more than one method to understand documents. This helps the agent handle both clean digital documents and challenging scanned documents without depending on a single signal.

Using multiple methods is important because documents are rarely perfect. A vendor invoice may include tables, stamps, handwritten notes, repeated headers, missing page numbers, multiple languages, or several supporting documents in the same file.

This approach also makes the workflow easier to inspect. When Reindeer extracts a value or classifies a document, the case can show the extracted field, the supporting evidence, and the reason the case needs review when confidence is lower.

How Multi-Document Packets Are Handled

Some workflows receive one file that actually contains several logical documents. Reindeer can review the pages and decide where one document ends and another begins.

When splitting and grouping pages, strong signals can include:

• Page numbers, such as "Page 1 of 3."
• Document titles or section headers.
• Matching document numbers, reference numbers, or invoice numbers.
• Continued tables, line items, totals, or narrative text.
• A new document type or a new business identifier.
• A page that clearly restarts the document structure.

Weak signals should be treated carefully. A logo, footer, signature block, standard legal text, or repeated disclaimer may appear across many pages and may not prove that pages belong to the same document.

How Classification Works

Classification identifies what kind of document or page the agent is looking at. The classification list should match the business process and should include a fallback category for documents that do not clearly match the expected types.

Good document type lists are:

• Specific enough to support routing and extraction.
• Short enough for reviewers and administrators to understand.
• Written in business language.
• Designed with an "Other" or "Unrecognized" option when appropriate.
• Tested against real examples, not only ideal samples.

For example, an invoice workflow may classify documents as invoice, credit memo, purchase order, delivery proof, statement, supporting document, or other.

How Parsing and Data Extraction Work

After a document is read and classified, Reindeer can extract the structured values needed by the workflow. Those values are usually stored on the case and shown in the case UI.

Extracted fields may include:

• Business identifiers.
• Document dates.
• Customer, supplier, or account information.
• Amounts, totals, taxes, and currencies.
• Line-item details.
• Validation results.
• Review recommendations or exception reasons.

Parsing works best when the expected fields are defined clearly in the case schema. The schema should describe which fields are required, which are optional, which can be corrected by reviewers, and which fields should be used for search, routing, or reporting.

Evidence and Bounding Boxes

A bounding box is a visual location on a source document that shows where a value was found. In review workflows, bounding boxes help users understand why the agent selected a value.

Bounding boxes can help reviewers:

• Verify that an extracted value came from the correct place.
• Compare a case field to the original document.
• Understand why the agent made a recommendation.
• Find source evidence faster during exception review.
• Explain corrections during audits or customer follow-up.

Not every field will always have a bounding box. A field may be inferred from several places, carried forward from another source, entered by a user, received from a connected system, or unavailable in the visible document. In those cases, the case should still make clear whether the value was extracted, inferred, corrected, or supplied from another source when that distinction matters to the workflow.

Reasoning and Confidence

Reindeer can include reasoning and confidence to make document decisions easier to review. Reasoning explains the signals the agent used, while confidence helps identify cases that may need human attention.

Reasoning and confidence should support review, not replace business judgment. If a value is material to the workflow and the source is unclear, the case should route to a user or exception queue.

Handling Scans, Multiple Languages, and Handwriting

Reindeer can be configured to process documents that are not clean digital PDFs. This includes scanned documents, image-based files, multilingual documents, and documents that include handwritten fields or annotations.

For challenging documents, the workflow makes uncertainty visible. If a value is hard to read, missing, handwritten, or inconsistent with other fields, the case can be routed to a reviewer instead of being treated as fully automated.

This is an important part of the design: Reindeer does not need every document to be perfect in order to be useful. The goal is to automate the parts that can be read reliably and give reviewers clear evidence for the parts that need human judgment.

What Helps Reindeer Handle Challenging Documents

Reindeer can process challenging documents, and the workflow works best when it is configured with examples of the document conditions it will see in production. If scanned, multilingual, handwritten, or rotated documents are common in the process, those examples should be included during setup.

For example, if a customer often receives scanned invoices with handwritten corrections, Reindeer can be configured to read the printed invoice, look for relevant handwritten changes, and route the case for review when the handwritten value is material but unclear.

What to Provide During Setup

When setting up or improving a document-processing workflow, provide Reindeer with:

• Sample documents for each expected type.
• Examples of difficult documents, including scans, handwriting, multilingual content, stamps, tables, and unusual layouts.
• A document type list and definitions.
• The fields that should be extracted.
• Examples of correct extracted values.
• Validation rules and exception conditions.
• Review decisions users need to record.
• Business identifiers used to search for existing logical cases.
• Any sensitive fields that should be hidden, masked, or restricted.

The more representative the examples are, the easier it is to design a workflow that handles real documents rather than only ideal documents.

Common Mistakes

• Defining document types that are too broad to drive routing or extraction.
• Defining document types that are too narrow for users to maintain.
• Treating a repeated logo or footer as proof that pages belong together.
• Making every extracted field required, even when source documents may not include it.
• Skipping fallback categories for unexpected documents.
• Testing only clean documents when the real process includes scans, handwriting, or multiple languages.
• Showing extracted values without enough source evidence for review.
• Adding fields to the case schema that are not used by users, reporting, or downstream workflows.
• Relying only on confidence instead of routing ambiguous cases for review.

Related Articles

• What Dynamic Case UI Allows
• Manage an Agent Case Schema
• Avoid Duplicate Logical Cases
• Writing Effective Contexts for Reindeer Agents