Automated Table Extraction from Scanned Oil & Gas Documents

What problem did this platform solve?

It replaced semi-manual handling of tables locked inside scans and PDFs with an automated pipeline that outputs structured data.

An oil and gas operator runs on documentation: PDFs, technical drawings, and scanned paper records, the kind of unstructured engineering data that is hard to search and reuse. The facts that matter often sit in tables, and a scan gives you a picture of a table, not data. Before this project, getting those values out was a semi-manual job.

The client needed a platform that could take these document types and return structured tabular data. Azati was brought in on the strength of its computer vision and document intelligence work, and the engagement ran for 12 months as a Dedicated Team.

Technologies used

Python

PyTorch

PyTorch Lightning

NumPy

Albumentations

OpenCV

What made this project harder than it looked?

The obvious route, plugging in a pretrained model, did not work on this client's documents, and every alternative needed its own experiments.

Challenge 01

Ready-made models were not good enough

The team started by reviewing existing solutions, and the answer was clear quickly:

• Many off-the-shelf models showed weak extraction quality on the client's documents.
• The team reviewed existing solutions before choosing its own approach.
• The weak results pushed the team toward its own research and training from scratch.

#1

Challenge 02

Labeling was an open question

Training from scratch needs labeled data, and how you label decides what the model can learn:

• The team tried many variants of document labeling before settling on what worked.
• Labeling and training variants were compared across many experiments.
• Data collection and labeling were part of the R&D cycle, alongside task setup and model training.

#2

Challenge 03

Three document types, one pipeline

The platform had to handle a range of inputs, not a single clean format:

• PDFs, technical drawings, and scanned documents all had to feed the same extraction flow, a typical document digitization workflow problem.
• The table detector was built to work on scanned images.
• Drawing title blocks look like tables but are built from irregular blocks, which a column-based approach cannot handle.

#3

How did Azati get from failed models to production?

By treating it as research: test what exists, choose an approach, label data, train from scratch, and only then build the product around the models.

Reviewing existing solutions first

The team looked at what was already available before building anything. That review is what showed the ready-made options would not reach the quality the client needed.

Choosing table detection plus OCR

Azati split the task into two steps: find the table, then run OCR data extraction on it.

Treating table structure as segmentation

Existing solutions were largely built around column detectors, which would have limited the platform. Azati framed table structure detection as a segmentation task, an unusual choice that handles layouts which are not regular grids.

Labeling data and trying many variants

The team set up the task, collected the data, and labeled it, trying many labeling approaches along the way.

Training detection and OCR models from scratch

With a labeling scheme that worked, the team trained both models in-house. The toolchain included Python, PyTorch Lightning, and Albumentations.

Building post-processing and deploying to production

Raw OCR output is not yet data. The team wrote the post-processing that structures it, wrapped the pipeline in an integration API, and deployed it to production.

Are your tables still trapped in scans and PDFs?

Send us a few representative documents. We will tell you whether table detection plus OCR fits them, and what the first round of data labeling would need to look like.

Automate my document data extraction

What did Azati build?

Five modules that work as one pipeline: a table detector, an OCR module, table structure detection, a post-processing layer, and an integration API.

01

Table detector for scanned images

The detector locates tables on scanned pages. It was trained from scratch on data the team collected and labeled for this client.

Key capabilities:

• Table detection on scanned images
• Model trained from scratch on labeled client data
• Built with PyTorch, Albumentations, and OpenCV

02

OCR module

The OCR module extracts text from detected tables. Like the detector, it was trained in-house rather than taken off the shelf.

Key capabilities:

• Text extraction from detected table regions
• OCR model trained from scratch
• Trained with PyTorch and PyTorch Lightning

03

Table structure detection

Existing solutions were largely built around column detectors, which would have limited the platform. Azati approached table structure as a segmentation task instead, an unusual choice for this kind of solution. It made it possible to extract data even from scanned AutoCAD drawings, where the title block in the bottom right corner has a tabular structure but is really a tetris of blocks.

Key capabilities:

• Trained with PyTorch, PyTorch Lightning and OpenCV from scratch
• Table structure detection framed as a segmentation task
• Not limited by the column-detector approach
• Title block extraction from scanned AutoCAD drawings

04

Post-processing

This layer converts recognized text and detected structure into structured tabular data.

Key capabilities:

• Structuring of raw OCR output into tables
• NumPy in the toolchain

05

Integration API

An API for integration exposes the pipeline's results to other systems.

Key capabilities:

• API for integration
• Production deployment

Screenshots

What did automation change in practice?

It removed the manual step from table extraction and gave the client a fully automated tabular-data pipeline.

The engagement did not report numeric benchmarks, so the honest summary is about process: what used to need a person now runs end to end.

The manual step is gone

Table data no longer depends on semi-manual processing. Documents enter the pipeline and structured data comes out.

One pipeline covers several document types

PDFs, technical drawings, and scanned documents are covered by one platform, including the title blocks of scanned AutoCAD drawings.

Models trained from scratch, not taken off the shelf

The detector and OCR were trained in-house on data the team collected and labeled, after ready-made models showed weak extraction quality.

An integration API is part of the platform

The platform exposes its results through an API for integration with other systems.

The relationship continued

The client kept working with Azati after this engagement.

What did the team learn from this project?

Three lessons: read the research before you buy the plugin, treat labeling as a modeling decision, and choose the approach after comparing, not before.

Reading papers beat waiting for a library

When ready-made models fell short, the team read scientific papers and ran its own research. That habit is the expertise that stays inside Azati after the project.

Labeling is a modeling decision, not a preparation step

The team tried many ways of labeling documents. Labeling was treated as part of the research, not as a task finished before it.

Choose the approach after comparing, not before

The team compared existing solutions and approaches before settling on table detection plus OCR. The approach was the outcome of that comparison.

Team composition

Azati ran the project as a Dedicated Team led by team leads.

• Team leads who led the team through the full R&D cycle: task setup, data collection and labeling, comparison of approaches, training of the table detection and OCR models from scratch, post-processing, and production deployment.

How was the engagement delivered?

Dedicated Team over 12 months

A Dedicated Team suits research-heavy work, where the route to production is found through experiments.

Full R&D cycle in one team

The same Azati team handled task setup, data labeling, model training, post-processing, and deployment.

Delivered without third-party vendors

Azati delivered the project with its own engineers from start to finish.

Who this approach is relevant for

It fits organizations whose key data sits in tables inside scans, PDFs, or technical drawings, and where off-the-shelf OCR does not reach usable quality.

• Oil and gas, energy, and engineering companies with large archives of scanned documentation
• Teams whose current process for extracting table data is manual or semi-manual
• Utilities and energy teams in the Middle East planning AI for engineering documentation
• Engineering organizations that need document AI for regulated engineering workflows
• Companies that tried generic OCR or pretrained models and saw weak extraction quality
• Organizations ready to invest in custom model training on their own labeled data
• Teams that need extracted data delivered through an API into existing systems
• Programs that benefit from a document digitization strategy before any tooling is chosen

Have documents your current OCR cannot read into tables?

Bring a sample of your hardest scans. We will review them with you and outline what a detection plus OCR pipeline would take on your data.

Talk to our document AI team