Problems & Solutions
The Real Cost of Manual Document Processing
Document processing problems are rarely dramatic. They do not cause outages or make headlines. Instead, they create a persistent, background drag on organizational efficiency — staff time absorbed by low-value data entry, results delayed by manual routing, errors accumulating silently across thousands of transactions.
The Document Automation Transformer (DAT) model addresses these problems systematically, at each stage of the document pipeline. This page describes the six most common problems organizations face, and how Ocriva's DAT approach solves each one.
Problem 1: Manual Data Entry
The Pain
Someone in your organization is typing data from documents into a system. Probably many people, doing it many times a day.
A single invoice can take 5–15 minutes to process manually: open the document, read the relevant fields, open the target system, navigate to the right screen, type each field, verify the total, save, and close. Multiply that by the number of documents your team handles daily.
The compounding effects are significant:
- Transcription errors — humans make mistakes at predictable rates; a 1% error rate on 1,000 invoices per month means 10 incorrect entries that need correction
- Inconsistent field naming — different staff use different abbreviations, capitalizations, or date formats, polluting downstream data
- Backlog accumulation — when volume spikes, processing falls behind; manual processes cannot absorb sudden increases
- Staff turnover risk — institutional knowledge about document formats and filing conventions walks out the door when staff leave
- Opportunity cost — skilled employees spending hours on data entry are not doing the work they were hired to do
The DAT Solution
Ocriva's Extract stage replaces manual data entry entirely. Documents submitted to Ocriva are processed by AI models that read and understand each document's content, extract the configured fields, and return structured data — all in seconds.
A template configured for invoices will extract vendor name, invoice number, line items, totals, and due dates from every invoice submitted, regardless of which supplier sent it or how the document is formatted.
Result: An invoice that took 15 minutes to process manually takes under 10 seconds. Error rates drop from human-range (~1–3%) to AI-range (typically below 0.5% for well-configured templates).
TIP
The quality of your template instructions directly determines extraction accuracy. A well-written instruction set — specifying date formats, null handling, and field-specific rules — is as important as the AI model you choose.
Problem 2: Format Chaos
The Pain
Documents come from many sources. Each source has its own format, layout, and conventions.
Your top supplier uses a two-column PDF invoice. A new supplier sends Word documents. A government vendor uses forms that look like they were designed in 1998. A freelancer sends photos of handwritten receipts.
Traditional rule-based OCR systems require fixed template positions — the system is configured to look for "total amount" at coordinates (x: 540, y: 720) of the page. When the layout changes, accuracy falls off a cliff. Maintaining a separate configuration for each document variant is expensive and fragile.
The chaos compounds at the metadata level too: date formats (DD/MM/YYYY vs YYYY-MM-DD), currency formats (1,000.00 vs 1.000,00), name ordering (First Last vs Last, First) — each difference is a potential downstream error.
The DAT Solution
Ocriva's Extract stage uses AI Vision Models that understand documents contextually, not positionally. The AI reads the document the way a knowledgeable human would — recognizing that "Amount Due", "Total Payable", "ยอดที่ต้องชำระ", and "Grand Total" all mean the same thing, regardless of where they appear on the page.
This means:
- One template handles all variants of a document type — no per-supplier configuration required
- Format normalization is built into the template configuration: instruct the AI to return dates as YYYY-MM-DD, amounts as numbers without currency symbols, names in First Last order
- Handwritten documents are handled without special configuration
- Mixed Thai-English documents are processed in a single pass
Example: A finance team processing invoices from 40 different suppliers in varying formats uses a single Ocriva template. No per-supplier configuration, no format-specific rules, no maintenance when a supplier changes their invoice layout.
Problem 3: Disconnected Systems
The Pain
Your team extracts data from documents. The data ends up in a file. Then what?
Someone downloads the file. Opens it. Copies the relevant rows. Pastes them into the accounting system. Or the CRM. Or the expense management tool. Or all three.
Extracted data that sits in a local file is not integrated data. The gap between "we have the extracted data" and "the data is in the system where it needs to be" is still a manual gap — and it introduces all the same problems as manual data entry: delay, error, and human dependency.
This is the integration failure that traditional OCR tools leave unaddressed. They extract data. They do not deliver it.
The DAT Solution
Ocriva's Integrate stage closes the gap between extraction and delivery. Results do not wait for a human to pick them up — they are pushed to your systems automatically.
Webhooks are the primary mechanism. Configure a webhook URL in your Ocriva project, and every time a document is processed, Ocriva sends an HTTP POST to your endpoint with the full result payload:
IMPORTANT
Always verify the X-Ocriva-Signature header on incoming webhook requests. Skipping signature verification exposes your system to spoofed payloads from third parties.
{
"event": "document.processed",
"processingId": "proc_abc123",
"status": "completed",
"result": {
"vendor": "Acme Corp",
"invoice_number": "INV-2026-0042",
"total_amount": 15000.00,
"due_date": "2026-04-30"
}
}Your accounting system receives this payload and creates a record automatically. No human in the loop.
REST API is available for pull-based integrations. WebSocket provides real-time updates to web UIs. LINE notifications push alerts to team members on mobile. Every integration path requires zero manual download-and-copy.
Example: A logistics company processes 200 shipping documents per day. Each processed document triggers a webhook that updates their shipment tracking database in real time. No one logs into Ocriva to check results — the results arrive where they are needed.
Problem 4: No Scalability
The Pain
Manual document processing scales linearly with headcount. Double the document volume, double the staff hours.
This creates a ceiling. Organizations that want to grow cannot do so without proportionally growing the operations team. Seasonal peaks (year-end financial close, peak sales periods) cause backlogs that take weeks to clear. The process that works at 50 documents per day breaks at 500.
Beyond headcount, traditional systems hit technical limits too — single-threaded processing, no queue management, no retry logic, no monitoring. Processing failures surface days later when someone notices missing data.
The DAT Solution
Ocriva's Automate stage is designed for volume. Processing cost is measured in credits and seconds, not in staff hours and days.
Key capabilities:
- Batch processing — submit up to 50 documents in a single batch; the system processes them in parallel with real-time progress tracking
- Processing queue — documents are queued and processed reliably; spikes in volume are absorbed without manual intervention
- Retry logic — failed documents are automatically retried; persistent failures are flagged for review
- Cron scheduling — configure overnight batch jobs so high-volume processing happens outside business hours
- Credit-based pricing — usage scales with volume without requiring infrastructure changes or headcount increases
Example: An accounts payable team processes 50 invoices per day during normal operations, and 500 during year-end close. The same Ocriva configuration handles both volumes without staff changes or system modifications.
Problem 5: Single AI Lock-in
The Pain
Organizations that adopt AI-powered document processing often commit to a single provider. This creates several risks:
- Accuracy ceiling — no single AI model is best at everything; a model excellent at English invoices may struggle with Thai medical records
- Pricing changes — a provider's pricing change can significantly affect processing costs across your entire pipeline
- Service reliability — if a single provider has an outage, all document processing stops
- Innovation lag — new, potentially more accurate models from other providers are unavailable without a platform migration
Single-provider lock-in trades short-term simplicity for long-term fragility.
NOTE
Switching AI providers in Ocriva requires only a template update — no code changes or redeployment. This makes provider switching a configuration decision, not an engineering project.
The DAT Solution
Ocriva connects to six AI providers simultaneously. Each template specifies which provider and model to use — meaning different document types can use different AI models, optimized for their specific requirements.
| Provider | Models | Best For |
|---|---|---|
| OpenAI | GPT-4o, GPT-4o-mini | General documents, complex instructions |
| Google Gemini | Gemini 2.0 Flash, Gemini 2.5 Pro | High-speed processing, large documents |
| Anthropic | Claude Sonnet, Claude Haiku | Nuanced extraction, long-form contracts |
| DeepSeek | DeepSeek V3, DeepSeek R1 | Cost-efficient processing |
| Qwen | Qwen VL | Multi-language, Asian scripts |
| Kimi | Moonshot Vision | Document understanding, long context |
This means:
- Use GPT-4o for invoice extraction where accuracy is critical
- Use Gemini Flash for high-volume receipt processing where speed matters more
- Switch providers per template based on cost or performance benchmarks
- Continue processing if one provider experiences downtime by switching templates to an alternative
Example: A healthcare company uses Anthropic Claude for medical record extraction (high accuracy requirement), DeepSeek for billing document preprocessing (cost optimization), and Gemini Flash for intake forms (speed requirement). All three run in Ocriva with no separate integrations.
Problem 6: No Feedback Loop
The Pain
Traditional document processing has no memory. Extract a document, get a result, move on. No record of what was extracted from what document. No way to identify which document types have higher error rates. No mechanism for improving accuracy over time.
Without measurement, there is no improvement. Teams notice quality problems anecdotally ("the invoices from this supplier always come out wrong") but have no systematic way to identify, quantify, or address them.
The DAT Solution
Ocriva's analytics and history features create a feedback loop around document processing quality.
Processing History stores every extraction result alongside the source document, the AI model used, the template applied, and the processing status. This creates an auditable record of every document that entered the pipeline.
Analytics surface patterns:
- Which document types have the highest failure rates?
- Which AI models produce the best results for which templates?
- How has processing volume changed over the past 90 days?
- Which projects are consuming the most credits?
Templates are the mechanism for improvement. When you identify a systematic extraction error — the AI is consistently missing a field, or misformatting a date — you update the template instructions once, and every future document benefits from the improvement.
Data Files (RAG) allow you to attach reference documents to templates, giving the AI additional context for extraction. If your invoices follow specific internal numbering conventions, a reference document explaining those conventions improves extraction accuracy across the board.
Example: A procurement team notices through analytics that their supplier contract template has a 15% error rate on the "payment terms" field. They review recent extractions, identify the pattern, update the template prompt with clearer field instructions, and the error rate drops to 2% — measured and confirmed through the same analytics dashboard.
Summary
| Problem | Root Cause | DAT Solution |
|---|---|---|
| Manual data entry | No automated extraction | AI Vision Models extract in seconds |
| Format chaos | Rule-based positional matching | AI understands context and meaning |
| Disconnected systems | Extract-only, no delivery | Webhooks, API, real-time push |
| No scalability | Linear headcount dependency | Parallel batch processing, credit scaling |
| Single AI lock-in | One-provider architecture | 6 providers, switchable per template |
| No feedback loop | No measurement, no history | Analytics, history, iterative templates |
Each problem in this list is a friction point in the document pipeline. DAT addresses them as a system — not with six separate tools, but with one platform designed around the full lifecycle of a document.
