343 pages and 99.42%: what building SLT OCR taught us about Arabic documents
When we started SLT OCR we thought the problem was “reading Arabic letters”. After a year of invoices, purchase orders, ID cards and KYC packs, it turned out reading was the easy part. This is an honest post-mortem of wh…
When we started SLT OCR we thought the problem was “reading Arabic letters”. After a year of invoices, purchase orders, ID cards and KYC packs, it turned out reading was the easy part. This is an honest post-mortem of what worked and what failed, with numbers.
The number we are proud of — and what is behind it
On a production sample of 40 documents (343 pages): 99.42% page accuracy and 97.5% whole-document accuracy. The gap between the two is the whole story: one error on one page drops the entire document out of the “correct” column. So the goal was never higher reading accuracy, but knowing when we are wrong.
Lesson one: a verification model per field, not one model for everything
A tax number obeys a mathematical checksum. A date must be a real date. A grand total must equal the sum of the lines. When every field got its own validator, the system became able to say “I am not sure” — the most valuable sentence in document processing.
A value that cannot be verified is not delivered as fact; it goes to a human review screen. That is not a feature, that is product ethics.
Lesson two: Arabic is a layout problem, not a glyph problem
- Mixed columns: Arabic description, English code, and a price in Eastern or Western digits on the same line.
- Stamps and signatures over text — far more common on Gulf paperwork than you would think.
- “Scanned” PDFs shot on a phone, skewed, with the owner’s hand shadow.
The fix was not a stronger OCR model but a layout-normalisation stage before reading, and per-document-type lexicons (a Saudi invoice ≠ an Egyptian invoice).
Lesson three: privacy is an architectural decision
Documents are never written to disk; processing happens in memory, and sources live in a 15-minute window before disappearing. The on-premises edition is a Docker container with zero network access at runtime — models and lexicons baked into the image. Banks and government bodies did not ask about accuracy first; they asked about this.
Lesson four: the export is the product
Nobody wants “pretty JSON”. They want an Excel workbook with stable keys that drops straight into their accounting system, and one HTTP API for automation. When we connected the output to the Tawqe3k e-signature platform, the path became complete: scanned document → verified data → signed contract, with no manual re-entry.
What we would do differently
- Start with a real test set from the client before writing any code.
- Measure whole-document accuracy, not character accuracy.
- Build the human review screen in week one, not the last week.
Document AI is not an accuracy race; it is a trust race. And trust is built by a system that knows its limits and says them out loud.
