Sajel Fatoorah

Turn Arabic invoices—including handwritten ones—into reviewable, verified, and exportable accounting data.

Comment

Inspiration

Many accountants and small businesses in Arabic-speaking markets still receive paper invoices, photographed receipts, and handwritten documents from suppliers. Converting these documents into accounting data is slow, repetitive, and vulnerable to human error.

Most invoice-processing tools are optimized for clean printed documents. Arabic handwriting, mixed Arabic-English layouts, unfamiliar columns, and incomplete invoices need a more careful workflow.

We built Sajel Fatoorah to turn an invoice image into an editable accounting draft while remaining honest about uncertainty. When the system cannot safely understand a value, it preserves the source information instead of silently assigning it to the wrong accounting field.

What it does

Sajel Fatoorah converts images of Arabic invoices—including handwritten invoices—into reviewable accounting drafts.

Users can:

  • upload an invoice image or capture one with a mobile camera;
  • extract invoice number, date, vendor, currency, line items, tax, and totals;
  • compare the extracted data with the original image;
  • edit values before approval;
  • run deterministic accounting verification;
  • preserve unfamiliar source fields outside the calculations;
  • export the reviewed result as JSON or Excel-compatible CSV.

Missing values remain empty instead of being converted into zero. Partial results are clearly identified, and the system reports insufficient data when a reliable accounting check cannot be completed.

How we built it

Sajel Fatoorah is a bilingual Next.js and TypeScript application.

GPT-5.6 analyzes invoice images through the OpenAI Responses API and strict Structured Outputs. The server applies conservative image preparation, including orientation correction, safe resizing, quality checks, and regional crops for dense or long documents.

The review layer keeps the original image visible and maintains a separate editable draft. After human review, a deterministic verification engine recalculates line totals and invoice reconciliation without making another model call.

Exports include canonical JSON and UTF-8 CSV with Arabic support, spreadsheet-formula-injection protection, and preservation of invoice identifiers with leading zeros.

Codex was our primary engineering collaborator during Build Week. It implemented the product milestone by milestone, maintained the test suite, investigated production failures, hardened privacy and error handling, and prepared the live deployment and submission documentation.

Challenges we ran into

Arabic handwriting and image quality

Handwriting style, faint ink, image angle, and small printed text can significantly affect extraction quality.

Semantic misassignment

Reading a number correctly is not enough if it is assigned to the wrong accounting field. We added semantic safeguards that preserve unfamiliar columns under their original labels instead of forcing them into quantity, tax, or total fields.

False confidence

Model confidence is not treated as human confirmation. Users can review and edit every extracted value before approval.

Review fatigue

Early versions required too many confirmations. Browser testing showed that users could approve values without reading them carefully, so we redesigned the experience around results and meaningful exceptions.

Dense-document reliability

Some long and dense invoices could exceed a single request deadline. We added an explicit staged-analysis path and honest partial-result handling.

Accomplishments that we're proud of

  • Built and deployed a working bilingual product during Build Week.
  • Integrated GPT-5.6 as the visual invoice-extraction engine.
  • Added image upload and direct mobile-camera capture.
  • Created normal and staged document-analysis workflows.
  • Built an editable human-review workspace.
  • Added deterministic accounting verification without additional model calls.
  • Preserved ambiguous source fields instead of forcing incorrect accounting meanings.
  • Added safe JSON and Excel-compatible CSV exports.
  • Built 326 passing automated tests across 36 files.
  • Deployed the live application at https://sajelfatoorah.com.

What we learned

Technical correctness is not the same as product usefulness.

Automated tests could confirm that the application followed its specifications, but real browser testing revealed when those specifications created confusing or excessive review work.

We also learned that invoice processing requires two different forms of accuracy:

  1. reading the visible content correctly;
  2. assigning that content to the correct accounting meaning.

A safe system must be able to say “I do not know.” Preserving an unfamiliar value outside the calculations is better than confidently placing it in the wrong field.

What's next for Sajel Fatoorah

After Build Week, we plan to:

  • build a permissioned dataset of real Arabic invoices;
  • create a repeatable evaluation harness;
  • improve handwritten-table extraction;
  • learn safely from user corrections;
  • add invoice history and persistent workspaces;
  • integrate with accounting software;
  • expand support for long and multi-page documents.

The current build is an honest working prototype, not a claim of perfect OCR. Extraction quality still depends on image quality, handwriting, and document layout.

Built With

Share this project:

Updates