The problem
Purchase orders arrived as PDFs with inconsistent layouts, naming, line-item structures, and scan quality. Manual re-entry into Epicor Prophet 21 was repetitive and exposed the workflow to transcription errors.
The system needed to handle variation without sending every document directly to an AI model or allowing uncertain output into the ERP import path.
Engineering constraints
- Customer documents contain confidential commercial information and must remain inside the approved workflow.
- Digital PDFs, scanned documents, and mixed-quality exports require different extraction strategies.
- ERP imports need predictable fields, types, and validation rather than plausible-looking text.
- Parser improvements cannot silently break formats that already work.
The architecture
Ordex starts with deterministic local extraction. OCR is used only when the document does not contain reliable selectable text, and a custom-trained model is reserved for layouts that remain ambiguous after those steps.
The extracted data passes through normalization and business-rule validation before the service creates the Prophet 21 import output. Failed checks are surfaced for review instead of being hidden behind a confidence score.
Quality controls
- Gold-set fixtures represent known customer layouts and edge cases.
- Twenty-two regression-test modules gate parser and normalization changes.
- Validation separates missing values, malformed values, and unsupported document structures.
- The fallback sequence keeps model usage targeted and makes failures easier to diagnose.
Result
The workflow moved from repeated manual re-keying to a consistent, reviewable import pipeline. The strongest result is not a single extraction demo; it is the ability to improve one parser path while protecting the formats already in production.
Technology
- Python
- FastAPI
- OCR
- Document parsing
- Custom-trained model
- Epicor Prophet 21 ERP
- Regression testing
Last updated