Searchable archives and structured field capture

OCR & Data Extraction Services in Pakistan

Make a scanned archive full-text searchable and pull specific fields out of it into structured data — with confidence scoring on every result and manual verification wherever recognition is not reliable enough to trust.

Part of our data digitization services in Pakistan — OCR is applied after scanning, and almost always alongside indexing.

What makes OCR risky

OCR does not fail loudly — it fails confidently

When optical character recognition gets a character wrong, nothing breaks and no error appears. The output looks like clean text. A deed number reads 5 instead of 6, a policy number drops a digit, a date shifts by a decade, and the result sits in your database looking exactly as trustworthy as every correct record around it.

That is the real risk in an OCR project, and it is why running recognition across an archive and shipping the output is professional negligence rather than a service. Every modern OCR engine returns a confidence value with each result. The question that separates a usable project from a damaging one is whether anybody looked at those values, set a threshold, and put the low-confidence results in front of a human being.

We do. Results below the agreed confidence threshold are routed to manual verification against the document image, and anything that still cannot be read with certainty is reported in an exception register rather than delivered as if it were fact.

Two different projects

Full-text search and field extraction are not the same thing

These get quoted as one service and they are not. Knowing which one you actually need changes the scope, the cost and the accuracy standard that matters.

Full-text search (searchable PDF)

An invisible text layer is added behind each scanned image so your staff can search for a word and find the documents containing it. The image you see is unchanged and remains the record of truth. Occasional recognition errors are tolerable here, because a missed hit is an inconvenience rather than a wrong answer — the human still reads the page.

  • Best for correspondence, reports, notifications and judgments
  • Delivered as searchable PDF or PDF/A
  • Quick to apply across a large archive

Structured field extraction

Specific fields are pulled out of each document into a database or spreadsheet — policy number, deed number, date, amount, name, CNIC. This is what feeds a system, and here an error is not an inconvenience. A wrong value becomes the basis of a decision, which is why extraction carries a confidence threshold and manual verification rather than a bulk run.

  • Best for forms, registers, invoices and policy schedules with consistent layout
  • Delivered as CSV, Excel, XML, JSON or a database load
  • Verified against the image before delivery

Most archives need both

The usual answer on a real project is a searchable text layer across everything, plus structured extraction of the handful of fields your staff actually query on. That combination gives you retrieval by field for the queries that matter and a safety net of full-text search for everything else.

Send us fifty pages before you commit

We will run recognition on a real sample of your documents and show you the actual confidence distribution — what reads cleanly, what needs a human, and what will never read at all.

Request a Sample Test

Scope of work

What our OCR and data extraction service includes

Image pre-processing

Deskew, despeckle, contrast normalisation, border removal and binarisation tuned per document type. Recognition accuracy is set largely at this stage, before the engine ever runs.

Searchable text layer

Delivery as searchable PDF or PDF/A with the recognised text sitting invisibly behind the original image, so the archive looks identical and becomes fully searchable.

Zonal and template extraction

For documents with a consistent layout, defined zones are read and mapped to named fields, which gives far higher reliability than extracting from free-form text.

Table and columnar capture

Register pages and tabular documents read row by row with column structure preserved, so a value does not silently migrate into the wrong field.

Confidence scoring and thresholds

A per-field confidence value is retained on every result. The threshold for automatic acceptance is agreed with you in the scope rather than left to a default setting.

Manual verification pass

Every result below threshold is checked against the document image by an operator. This is the stage most vendors leave out, and it is the stage that makes the output safe to use.

Validation against your rules

Format, range, date logic, CNIC structure and consistency against your master data, so an impossible value is rejected even when recognition was confident about it.

Exception register

Every field that could not be captured with certainty is listed with its document reference, so your staff can close the gaps deliberately instead of discovering them later.

Delivery into your systems

Structured output loaded into your database, application or EDMS, in the format and schema your system requires.

How a project runs

Our OCR and extraction process

Recognition is one step in the middle. The stages around it are what determine whether the output can be trusted.

1

Sample assessment

We run recognition on a representative sample of your documents and report what we find — which document types read cleanly, which produce low confidence, and which will not read usefully at all. This is the single most useful hour in an OCR project and it happens before you commit.

2

Scope and threshold agreement

We define which fields are to be extracted, the confidence threshold for automatic acceptance, which fields require verification regardless of confidence, and the validation rules the output must satisfy. All of it in writing before production.

3

Image quality check and re-capture

Where existing scans are too poor for reliable recognition, we say so. A low-resolution bitonal scan of a faded register cannot be rescued by software, and re-scanning at proper resolution is usually cheaper than correcting the errors afterwards.

4

Pre-processing and template setup

Images are cleaned and, for structured documents, extraction zones are defined and tested against the sample. Template-based extraction on a consistent layout is dramatically more reliable than free-text parsing.

5

Recognition and confidence capture

Production recognition runs with per-field confidence retained throughout. Nothing is discarded at this stage, including the engine's own uncertainty about its results.

6

Verification and correction

Low-confidence results are presented to operators against the document image for correction. Critical fields can be set to full verification regardless of confidence, which is standard practice on deed, policy and case numbers.

7

Validation, audit and delivery

Validation rules applied, an independent sample audited against source images, accuracy reported at field level, and output delivered with the exception register alongside it.

Specifications

What we can recognise and what we deliver

Procurement teams ask for these in writing, and the honest answers are more useful than optimistic ones.

RequirementWhat we deliver
Printed English textReliable at adequate scan resolution and condition. The normal case for modern reports, notifications, judgments and computer-generated forms
Printed Urdu textWorkable on clean Naskh typesetting with verification. Nastaliq and older print quality are substantially less reliable, and we quote verification effort accordingly
Handwritten textNot delivered through recognition. Handwritten records are captured by keyed data entry with double-entry verification instead
Document typesForms, registers, invoices, policy schedules, correspondence, judgments, tabular ledgers and mixed-layout files
Input formatsTIFF, JPEG, PDF image sets, or newly scanned images produced as part of the same project
Output formatsSearchable PDF, PDF/A, plain text, CSV, Excel, XML, JSON, or direct load into your database or application
Confidence handlingPer-field confidence retained, acceptance threshold agreed in the scope, sub-threshold results routed to manual verification
Accuracy reportingField-level accuracy measured by independent audit against source images and reported per batch, not a single headline percentage
Exception handlingEvery unresolvable field listed with document reference and reason, delivered with the data set
Data ownershipAll recognised text, extracted data and derived files are your property, with no copy retained after handover beyond what you authorise

Urdu and legacy documents

The honest position on Urdu OCR

This is where most OCR proposals in Pakistan quietly overpromise, and where a project most often fails after the money has been spent.

What is realistic

  • Clean, modern, computer-set Naskh Urdu at good resolution, with a verification pass
  • Urdu full-text search where an imperfect index is still better than none
  • Mixed English and Urdu documents where the English fields carry the queries
  • Extraction of numeric fields such as dates, amounts and reference numbers from Urdu forms

What we will not claim

  • Reliable recognition of handwritten Urdu in revenue and court registers
  • Accurate reading of Nastaliq typesetting in older printed records
  • Usable output from faded carbon copies and overwritten entries
  • A trustworthy database produced from any of the above by software alone

What we recommend instead

On a typical Pakistani institutional archive, the cost-effective design is a hybrid. Recognition handles the printed bulk and gives you full-text search across the whole collection. The small number of fields your staff genuinely query on are captured by keyed entry with double verification, and those become your index. You end up paying for human accuracy only where human accuracy is actually required.

Record types

Archives where extraction earns its cost

Extraction pays for itself where a field is queried repeatedly by many people. It rarely pays where a file is opened once a decade.

Court and legal records

Judgments and orders are typed, well structured and queried by text constantly, which makes them among the best candidates for a full-text searchable archive.

Delivered project

Data digitization project — Peshawar High Court

COURT RECORDS DIGITIZATION →

Insurance records

Policy schedules and proposal forms follow a fixed layout, so zonal extraction of policy number, premium, sum assured and dates is reliable and high value.

Delivered project

Data digitization project — State Life Insurance Corporation

INSURANCE RECORDS DIGITIZATION →

Land and revenue records

Printed deeds and endorsements respond to recognition, while handwritten mutation entries and older registers are keyed instead. A hybrid approach is the only safe design here.

Delivered project

Archiving and indexing of missing deeds — Punjab Land Records Authority

LAND RECORDS DIGITIZATION →

Medical records

Printed laboratory and diagnostic reports extract well into structured results, while clinical notes remain handwritten and are handled by keyed entry.

MEDICAL RECORDS DIGITIZATION →

HR and personnel files

Appointment letters, promotion orders and service entries are typed and uniform, which makes employee number, designation and date extraction straightforward.

HR RECORDS DIGITIZATION →

Housing society records

Allotment letters and transfer documents carry a consistent set of fields — plot number, member name, CNIC, date — that extract cleanly once templates are set.

HOUSING SOCIETY RECORDS →

Why Hizbullah Khan & Sons

What a responsible OCR provider does differently

We test before we quote

A sample run on your actual documents, with the confidence distribution reported to you. No OCR scope should ever be priced from a description of the records.

Confidence thresholds are agreed, not defaulted

You decide what level of certainty is acceptable per field, and that decision is written into the scope and reported against.

Human verification is in the price

The manual pass on low-confidence results is part of the service, not an upsell discovered after the output turns out to be unusable.

We tell you what will not work

If your archive is handwritten Urdu, we will say recognition is the wrong tool and quote keyed entry instead. That conversation saves projects.

Public-sector delivery record

Completed digitization projects for a provincial land authority, a high court and a state insurer, where output accuracy had real consequence.

The whole chain under one scope

Scanning, recognition, indexing and system deployment from one accountable partner.

Common questions

OCR and data extraction FAQs

How accurate is OCR on our documents?

Nobody can answer that from a description, and any provider who gives you a percentage before seeing your records is quoting a brochure. Accuracy depends on print quality, scan resolution, script, typeface, paper condition and layout consistency, and it varies between document types inside the same archive. We run a sample test on your real documents and report the actual confidence distribution, which tells you what will read cleanly, what needs a human pass, and what should be keyed instead.

Can OCR read Urdu?

Partially, and the detail matters. Clean modern Naskh typesetting at good resolution is workable with a verification pass. Nastaliq typesetting, older print and faded documents are substantially less reliable. Handwritten Urdu, which is what most revenue and court registers actually contain, is not reliably recognisable by any engine we would stake a project on. For those records we recommend keyed data entry with double-entry verification, and we would rather lose the OCR line item than deliver an index you cannot trust.

Can you read handwritten records?

Not through recognition, and we will not pretend otherwise. Handwriting recognition on institutional Pakistani records — mixed script, inconsistent hands, overwriting, annotations, decades of different conventions — does not reach a standard where the output is safe to act on. Handwritten records go to keyed entry with double verification on critical fields, which costs more per field and produces data you can actually use.

What is a searchable PDF and do we need one?

A searchable PDF holds the original scanned image exactly as it is, with a text layer sitting invisibly behind it. Your staff see the authentic document and can also search its contents. It is the most cost-effective single improvement to a scanned archive, because it turns a folder of pictures into something that answers a question. It does not replace an index — searching for a word finds documents containing that word, whereas an index finds the specific record by deed number, case number or CNIC.

Can you extract only certain fields instead of all the text?

Yes, and on structured documents that is the better approach. Where a document type has a consistent layout — a policy schedule, an allotment letter, a claim form, a register page — we define zones and map each to a named field. Zonal extraction against a known template is far more reliable than parsing free-form recognised text, and it delivers exactly the columns your database needs rather than a wall of words.

Our documents are already scanned. Can you just run OCR on them?

Often yes, and we will check first. Existing scans are frequently low-resolution bitonal images produced for storage rather than recognition, and software cannot recover detail the scan never captured. We assess a sample and tell you honestly whether recognition on your existing images will give usable output, or whether re-scanning is the cheaper route once error correction is counted.

What does OCR and data extraction cost in Pakistan?

Full-text OCR across an archive is priced per page and is relatively economical, because it is mostly machine time. Structured field extraction is priced by the number of fields and the verification effort each requires, which is driven by document condition and script. The verification pass is the real cost variable — a clean printed archive needs very little, while a mixed legacy collection can need a human look at a large share of fields. The sample test is what turns this into a fixed number.

How do you handle values the software gets wrong?

Every result carries a confidence value. Results below the agreed threshold are routed to an operator who checks them against the document image and corrects them. Fields you designate critical can be set to full verification regardless of confidence, which is standard on deed numbers, policy numbers, case numbers and monetary amounts. Validation rules then reject impossible values even where confidence was high, and anything still unresolved is listed in the exception register rather than delivered as fact.

Can the extracted data go straight into our system?

Yes. Output is delivered in the format and schema your system accepts — CSV, Excel, XML, JSON, a SQL load, or direct population of your application or EDMS. Field mapping is agreed with your IT team during scoping so the delivered structure matches the target, rather than arriving as a generic export someone then has to transform.

Is our data confidential during processing?

An organisation-level non-disclosure agreement is signed before any document is processed, and every operator on the verification pass signs an individual confidentiality undertaking. Processing takes place in an access-controlled area with no removable media or personal devices permitted. For sensitive archives we can carry out the work on-site on your own systems. The recognised text, extracted data and derived files are your property, and no copy is retained after handover beyond what you authorise in writing.

Find out what your documents will actually read like

Send us a sample. We will run recognition on your real records, report the confidence distribution, and tell you which fields are safe to extract and which should be keyed instead — before you spend anything.

+92 331 5119119  ·  051-6123093  ·  info@hizbullahkhanandsons.com
Monday to Saturday, 9:00 AM – 6:00 PM