Paperwork into data, with a person checking
Supplier invoices, delivery notes, certificates and forms read from PDFs, scans and phone photographs into fields, with anything uncertain sent to a person before it is used.
- Inputs
- PDF, scanned image, phone photograph, email attachment
- Languages
- Arabic, English and documents that mix both
- First document type live
- Two to four weeks from receiving sample documents
- Accuracy
- Measured on your own documents and written into the test record
Data extraction reads fields out of PDFs, scans and phone photographs: supplier invoices, delivery notes, calibration certificates, forms. Every field carries a confidence level. Anything below the threshold you set goes to a verification queue, where a person confirms it before it reaches another system. Verified data leaves as an import file your team posts.
- 01 Enquiry
- 02 Systems audit
- 03 Specification
- 04 Build
- 05 Pilot
- 06 Deploy
- 07 Handover
- 08 Support
Paperwork into data, with a person checking sits at step 4 of the build cycle. You receive a working increment you can use.
Twenty real documents before any figure
We start by asking for about twenty real documents of each type, and we ask for the bad ones.
Stamped over, folded, photographed at an angle on a van seat. Extraction accuracy depends almost entirely on the paper you receive, so we measure it on a held-back sample of your own documents and write the result into the test record.
There is no accuracy figure on this page, because any figure here would describe someone else's paper.
Where extraction goes wrong in this market
| Problem | Why it happens | What we build for it |
|---|---|---|
| A stamp over the total | Company stamps land on the printed figures. | The total is re-added from the lines and compared. |
| Handwritten quantities | Received quantities are written on at the dock. | Handwritten fields always go to the queue. |
| Hijri and Gregorian dates on one page | Both calendars are in daily use. | Dates normalised to one calendar, with the original kept. |
| One supplier, three spellings | Arabic names transliterate differently. | Suppliers matched on VAT or CR number, not on the name. |
| A misread digit in a VAT number | One smudged character. | Saudi VAT numbers are 15 digits beginning and ending in 3. Anything else is flagged. |
| Totals on the last page only | Multi-page invoices. | Pages grouped per document before reading. |
What stays with you
The field specification
Every field read from each document type, with its format and the confidence threshold you set.
The extraction rules and validation checks
In plain text: the format checks, the re-added totals and the supplier matching.
The verification queue
Set up for your team, with the document image beside every value it shows.
The test record
Accuracy measured on a held-back sample of your own documents.
The import file specification
The layout the receiving system accepts, agreed before the first export.
The runbook
Including what to do when a new supplier layout arrives.
One document through the system
- 01
Arrive
A dedicated inbox or upload point receives the PDF, scan or photograph, in place of documents scattered across chats.
- 02
Read
Pages of one document are grouped, then each field is read with its own confidence level.
- 03
Validate
VAT numbers and dates are checked against their formats, line totals are re-added against the printed total, and the supplier is matched on VAT or CR number.
- 04
Queue
Handwritten fields, low-confidence fields and failed checks go to the verification queue. Fields you mark as financial are always verified, or matched to a purchase order within your tolerance.
- 05
Verify
The verifier sees the image with the field highlighted and the value read beside it, and confirms or corrects it in one action. Every correction is logged, and the log shows which suppliers and fields cause the work, so rules can be tightened.
- 06
Export
Verified fields go to a register, a spreadsheet or an import file in your accounting system's format. Approving the invoice and releasing payment stay with whoever approves payments today.
Driver photographs, retyped in accounts
A food distributor in Dammam receives supplier delivery notes and invoices as phone photographs sent by drivers and supervisors, and an accounts clerk retypes them.
A dedicated inbox replaces the scattered chats. For each document the system reads the supplier, the VAT number, the invoice number, the date, each line and the VAT total. The VAT number is checked against its format and against the supplier master, and line totals are re-added and compared with the printed total.
Handwritten received quantities and every low-confidence field go to the queue, where the clerk confirms them against the image. Verified documents leave as an import file the distributor's accounting system already accepts, and the clerk approves payments as before.
The distributor holds the field specification, the validation rules, the queue, the correction log and a test record showing the measured accuracy on its own documents.
Before you send the first batch
How accurate is it?
We measure it on your documents and write the result into the test record. It varies by supplier, by field and by how the paper was photographed, which is why the number comes from your sample.
Can it read handwriting?
Some, though not reliably enough to trust. Handwritten fields go to the queue by default.
Where are the documents stored?
In the location set at specification, kept for as long as your own retention rule says.
Can it post straight into our accounting system?
It produces the import file your system accepts. Posting and payment approval stay with your team.
What happens when a supplier changes its layout?
Fields from the new layout read with lower confidence, so they land in the queue until the rules cover it. The runbook describes the change.
What drives the cost?
The number of document types, how varied your suppliers' layouts are, the share of handwriting, and the receiving system's import format.
Next to extraction
AI agents
Matching an extracted invoice against its order and delivery note, with every mismatch flagged for the approver.
Read moreDigitalSystems integration
Getting verified data into the system that needs it, on a key both systems agree on.
Read moreDigitalAssistants over your own documents
Once scanned procedures have been read, staff can ask questions of them.
Read moreFMITF FM Evidence OS
The FM evidence workflow, where closing a job takes evidence.
Read morePart of one system
Every division keeps records to the same standard, so the second one you need works the way the first one did.
Send us twenty real documents
Pick the document type that eats the most typing time and send the worst examples you have. We read them, measure the result on your paper and show you what would reach the queue.