OCR for Receipts, Invoices, and Forms: Extraction SDK Guide
The Apryse Server SDK OCR Module converts scanned receipts, invoices, and forms into searchable PDFs and structured JSON or XML, entirely inside your own infrastructure. No per-page fees, no cloud dependency. When you need labeled fields instead of raw text, run OCR first to convert the document into machine-readable text, then pass that output to Smart Data Extraction to get labeled fields. Two separate calls, one pipeline.
How can OCR support a document processing pipeline?
OCR turns a scanned receipt, invoice, or form into machine-readable text. It does not know that one line is the invoice number or that one cell holds the total.
The Apryse Server SDK OCR Module reads the printed text on a scanned or photographed business document and produces a searchable PDF with a selectable text layer, plus JSON or XML output carrying the recognized text and its position on the page. The Default engine (V12) covers more than 80 languages and runs inside your own server, VPC, or air-gapped environment. No document leaves your infrastructure to get OCR'd.
Once a document is machine-readable, Smart Data Extraction reads that output and identifies invoice numbers, line items, totals, and other labeled fields as structured JSON. This page covers the OCR stage. For the extraction stage, visit Smart Data Extraction.
Architecture: OCR to Smart Data Extraction
A scanned receipt, invoice, or form enters as an image or an image-based PDF. The OCR Module converts it into a searchable PDF plus JSON or XML with text and position data. From there, Smart Data Extraction reads that output and returns labeled fields: invoice number, line items, totals, vendor name, document type.
OCR and Smart Data Extraction are separate add-on modules with separate licenses. OCR converts an image into machine-readable text. Smart Data Extraction turns that text into structured, labeled data.
Deploying OCR on its own server or in a self-hosted environment? See the self-hosted OCR deployment guide.
Constraints and boundaries
- OCR produces searchable text and position data, not structured fields. Pulling an invoice number or a line-item table out of that text requires Smart Data Extraction, a separate add-on package.
- Accuracy depends on scan quality. The OCR Module is optimized for color or greyscale input at approximately 300 DPI.
- Handwritten fields, common on insurance claim forms and intake paperwork, require the Handwriting ICR Module, a separate add-on. OCR does not read handwriting.
- The OCR Module runs on the Apryse Server SDK only. It is not available on the Web SDK or the Mobile SDK.
- Text orientation detection is not currently supported for Cyrillic, Devanagari, or Arabic script groups, or for Korean. ARM and 32-bit platforms are not supported for add-on modules.
Apryse OCR Module vs OCR alternatives
Tesseract gets you a working prototype for free, but real-world documents (skewed scans, mixed layouts, low-quality images) push accuracy problems and ongoing maintenance back onto your team, with no support contract to call when it breaks. Cloud OCR APIs like AWS Textract, Azure Document Intelligence, and Google Document AI trade that maintenance burden for a different cost: per-page pricing that scales with volume, and a requirement to send documents outside your environment, which rules them out for regulated or sensitive content. Apryse's OCR Module runs a deterministic, deep learning-based engine self-hosted inside your own infrastructure, supporting 80 or more languages, with predictable licensing instead of per-page metering, and no document ever leaves your environment.
Common use cases
Financial services
OCR converts scanned statements, KYC packets, and mortgage documents into searchable text before Smart Data Extraction pulls out account numbers and balances.
Insurance
Claims packets (FNOL), policy documents, and adjuster field photos become searchable text ahead of structured field extraction.
Healthcare
Lab reports, certificates of analysis, and intake forms convert to machine-readable text ahead of structured data pipelines.
Government and Public Sector
FOIA records and permit or tax form scans become searchable text for records systems and redaction workflows.
Logistics
Bills of lading, customs paperwork, and shipping invoices from thousands of sources become searchable before line-item extraction.
Apryse Server SDK: developer details
Here's the what, why and how of the Apryse OCR Module, including runtime environment, language support, deployment options, and what it takes to get it installed and initialized in your stack.
- Where it runs: Server SDK only. Not available on Web SDK or Mobile SDK.
- Languages and frameworks: Java, Python, C#/.NET, Node.js, C++, PHP, Ruby, Go
- Platforms: Windows, Linux, macOS (x64 only)
- Deployment options: On-premise, private cloud/VPC, air-gapped. Documents process locally and are never sent to Apryse.
- Install method: pip (apryse-ocr, Windows/Linux only), Maven (OCRModuleWindows / OCRModuleLinux, groupId com.pdftron, Windows/Linux only), or archive extraction (Windows, Linux, macOS)
- Required gate / prerequisite: PDFNet.Initialize() with a valid license key before any OCR Module call. Separate add-on license required (trial keys have unlimited access).
- Licensing tier: Add-on module. Separate download and license from the base Server SDK.
- Documentation: docs.apryse.com/core/guides/ocr
Java, Python, .NET, C#, C++, and Node.js
The Apryse Server SDK ships native language bindings, not wrappers, for Java, Python, C#, C++, Node.js, PHP, Ruby, and Go. The Smart Data Extraction SDK, install on top of whichever binding you already use for the base Server SDK.
