What buyers of PDF and table work actually ask for, measured on 495 paid listings

Most tool pages are designed from the tool outward: here is a feature, here is who might want it. The more useful direction is the opposite, so we went and measured the requests themselves.

The corpus is a set of freelance job listings collected by this project. Filtering to listings that are a genuine need, show willingness to pay, and describe something productizable leaves 495 posts that concern PDFs, scans or tables. Every figure below is a keyword-hit rate over those 495 with a named word list, so it can be rerun and checked rather than taken on trust.

The numbers

• 56% state an accuracy or verbatim requirement — "exactly as it appears", "100% accuracy", "must match the source".
• 54% ask for the structure or formatting to be kept — layout, line breaks, headings, styles, row order.
• 30% ask for unreadable parts to be flagged rather than guessed.
• 17% explicitly frame the job as an alternative to manual re-typing.

Read those four lines together and the shape of the demand is clear. It is not "extract my table". It is "reproduce this document exactly, keep its structure, and tell me where you could not".

The requirement that appears in almost every post

The most common single sentence in this corpus is some variant of "accuracy matters more than speed". That ordering is unusual for software and worth taking literally — a fast wrong output is worse than a slow right one, because the buyer then has to find the error before they can use any of it.

…manually enter all text from each PDF page into a Word or Google Doc, ensuring 100% accuracy… flag any illegible words or unclear sections so I can review them quickly.

Note what that post asks for in the same breath: perfect fidelity, and a list of the places where perfect fidelity was not achieved. Those two requests are only contradictory if you assume the tool must be silent about its own uncertainty. Together they describe exactly the behaviour a trustworthy extractor should have.

Why "flag the illegible parts" is the important one

Three in ten buyers write this out explicitly. It is the requirement that separates a tool that is useful from a tool that is dangerous, because a confident wrong value in a spreadsheet is much harder to deal with than a visible gap.

…a brief note flagging any illegible or unclear portions so I can verify them quickly. Acceptance criteria: every text element is present and matches the source verbatim; no stray characters, blank rows, or format drift.

The buyer has already worked out that they will be checking something. What they want is to be told which rows to check, instead of re-reading the whole batch. That is a smaller, cheaper, more honest promise than "100% accurate" — and it is the one a machine can keep.

Structure means structure, not prettiness

When these posts say "keep the format", they mean the machine-readable structure: which cell belongs to which column, merged cells staying merged, row order preserved, one record per row. The word "formatting" also covers fonts and bold, but the acceptance criteria in the same posts are almost always about structure and completeness.

…a fully populated spreadsheet in either Excel or a Google Sheet… one completed row per report… uniform date, currency and number formatting… I will check the final sheet against random samples.

A plausible-looking sheet with a merged cell flattened into the wrong column fails that spot check. A sheet with one row holding an unconfirmed value does not, if the unconfirmed value is marked.

What this changed in what we built

Two decisions on this site came directly from reading these posts rather than from a feature list.

First, per-cell verification against the source text, with unconfirmed cells reported individually and the whole delivery marked as carrying warnings. The corpus asked for it in 30% of cases; the case that convinced us was a model that silently turned 循环贷款 into 循环贷款等.

Second, one sheet per detected table with the row order preserved, rather than a single flattened output. 54% of these posts care about structure surviving, and flattening is the specific failure they describe when they complain about tools.

What the corpus does not tell you

It is a sample of freelance listings, which skews toward buyers who have already decided to pay a person. It says nothing about volume, price sensitivity, or whether these buyers would accept software. The keyword method also over-counts: a post that says "no OCR tools" is counted as mentioning OCR, and a post that says "there are no tables" is counted as mentioning tables. Treat the percentages as a sketch of what is asked for, not as a market size.

What it does establish reliably is the ordering of the requirements. Accuracy and structure come first, flagging uncertainty comes third, and every feature that is not one of those three is absent from most posts entirely.