Pulling the Same Field Out of a Stack of Documents

By the onecue.ai team · August 11, 2026 · ~8 min read

There is a specific, unglamorous task that eats hours: you have forty invoices from the same supplier, or a folder of receipts on the same form, or a batch of shipping labels, and you need one value out of each — the total, the date, the tracking number — assembled into a list.

The obvious tools are both bad at it. General OCR gives you every word on every page and leaves you to find the one you wanted forty times. Document AI services want you to define a schema, or train on samples, before they will give you anything. Both ignore the property that makes this task easy: the documents share a layout. The field you want is in the same place on every page, because they came off the same template.

This article is about building around that property, and about where it stops holding.

Position is the cheapest signal available

OCR does not just return text. It returns text with coordinates — every line comes back with a polygon marking where it sat on the page. Most tools discard this immediately, flattening the result into a wall of text, which throws away the one piece of information that makes batch extraction tractable.

If you keep the coordinates, "the total on this invoice" becomes a geometric question rather than a semantic one. You do not need a model that understands invoices. You need to know that on this template the total sits in the lower right, and then find the text nearest to that spot on every other page.

That is the whole idea behind our Field Extractor: you draw a rectangle once, on one document, around the value you want. Every other document is OCR'd, and the text falling inside the corresponding region is pulled out and put in a table alongside its position, ready to download as JSON.

Why relative coordinates, not absolute ones

Documents in a batch are rarely the same pixel size. Some were scanned, some photographed, some exported from a PDF at a different DPI. A rectangle recorded in pixels is meaningless on a page with different dimensions.

So regions are stored relative to the page — as fractions of width and height rather than pixel offsets. A field at (0.72, 0.88) of the way across and down the page is at the same logical spot whether the file is 1240 pixels wide or 3024. This is the same reason our correction analytics store coordinates relatively: it keeps the data meaningful across every source resolution, and it makes a region drawn on a phone photo comparable to one drawn on a scan.

Where pure position stops working

Being honest about the limits, because this is where "just use coordinates" becomes naïve:

Content shifts the layout. An invoice with three line items and one with thirty do not put the total in the same place. Anything below a variable-length table moves.
Photographs are not scans. A page shot by hand is rotated a few degrees, trapezoid from perspective, and cropped differently. Relative coordinates handle scale, not skew.
Templates change. A supplier redesigns their invoice and every stored region is silently wrong — and wrong in the worst way, returning a confidently extracted value from the field next door.

The practical mitigation is not to make the geometry cleverer but to keep the human in the loop where it is cheap: the extracted values come back as a table you can scan in seconds, next to the position each came from. Forty values in a column, one of them obviously the wrong kind of thing, is a mistake you catch instantly. Forty values dumped into a spreadsheet by an automated pipeline is a mistake you find next quarter.

PDFs are a different input, not a different feature

Most document batches contain PDFs, and the temptation is to treat them as a separate pipeline — extract the embedded text layer, fall back to OCR when there isn't one.

We render PDF pages to images and run the same OCR path as everything else. That sounds wasteful and is deliberate. Embedded text layers are unreliable in exactly the batches where this task arises: scanned documents wrapped in a PDF container have no text layer at all, and generated PDFs frequently have one whose reading order bears no relation to the visual layout — two-column documents are notorious. Since the whole approach depends on where things are, a text layer with the wrong geometry is worse than no text layer.

Rendering to pixels also means one code path handles a scanned page, a phone photo, and an exported PDF identically. The PDF renderer loads only when a PDF is actually dropped, so users who never touch one never download that code.

Batching is a UX problem before it is a performance problem

Running ten documents is not ten times running one. The differences are all in what happens when things go wrong:

One failure must not sink the batch. Each document is its own job. If the seventh is corrupt or times out, the other nine still produce results, and the seventh is marked failed rather than blocking everything behind it.
Jobs need a deadline. A document that never settles would otherwise hang the batch forever. Ours give up after five minutes and report as failed, so the results that did arrive can be used.
Results must stay attached to their source. Ten values in a list are useless if you cannot tell which document each came from. Every row carries its filename and the region it was read from.
Re-running must not resurrect stale work. If you clear the batch and start another while jobs are still in flight, the old callbacks have to be inert. We tag every batch with a run id and drop any callback whose id no longer matches — otherwise a slow job from the previous run appears in the middle of the new one's results.

None of this is visible when it works, which is the point. All of it is visible the first time a batch of forty half-finishes.

When to use which tool

Same layout, one or two values per document, many documents → mark the region once. Field Extractor.
Every word matters, layout varies → full OCR with positions. Image To Text returns each line with its polygon, which you can post-process however you like.
Documents in a language you cannot read → translate first, keeping the layout, so the structure you would navigate by is still there. Image Translator.
Layouts differ wildly and the semantics matter → this approach is the wrong one. A model that reads the document is what you want, at correspondingly higher cost.

Practical advice for a clean batch

Mark the region a little larger than the value. A tight box is fragile against small shifts; a slightly generous one costs you nothing because the extra whitespace has no text in it.
Pick your template page carefully. Use a typical document, not the shortest or longest one — the region you draw inherits its layout.
Keep resolution up. Extraction quality is bounded by OCR quality, and OCR quality is bounded by pixels per character. See how OCR actually works for what that trade looks like.
Scan the output column before using it. The table exists to be checked; that is the part that keeps a template change from becoming forty wrong numbers.