How to Extract Tables From PDFs Into Consistent JSON

A table that looks orderly to a person may not behave like a structured table when processed. A PDF primarily describes how content appears on a page. It may store text as individual positioned elements rather than as rows, columns, and cells.

That distinction creates practical problems. A description can wrap onto a second visual line. A quantity may appear far from its header. A table can continue on another page with repeated column headings. Scanned documents introduce image quality and recognition issues, while digitally generated PDFs can still contain unusual reading orders.

Layouts also vary between document sources. One invoice may use the heading “Item,” another “Product description,” and another no explicit description heading at all. Some documents place discounts in a separate column. Others put them on an additional line below the relevant item.

Consistent output therefore requires a stable interpretation layer. Instead of preserving every layout difference, the workflow should map equivalent information into one agreed structure.

Before defining fields, identify what the receiving process needs to do. A finance workflow may need document numbers, dates, currencies, line items, and totals. An inventory workflow may care more about stock codes, units, and quantities. A compliance workflow may need exact source text in addition to normalized values.

This decision prevents an overly literal schema. If one PDF has separate columns for “Pack count” and “Units per pack,” copying those headings into the universal schema may create problems when other PDFs provide only a total quantity. A better target could include total quantity, unit of measure, and optional packaging details.

Also decide which values are required for downstream processing. Required does not have to mean that every source document contains the value. It means that the workflow should flag the record when the value is absent rather than silently producing incomplete data.

A practical schema usually separates document-level fields from repeating table rows. Document-level fields might include the document number, issue date, supplier reference, and currency. The table becomes an array such as line_items, with the same field names used for every row.

Choose field names that express business meaning. Names such as item_code, description, quantity, unit_price, and line_total remain useful even when the PDF headings change. Avoid field names tied to coordinates, page positions, or one supplier’s terminology.

Specify data types as part of the design. If quantity is a number, decide whether decimals are permitted. If dates are normalized, choose one representation such as YYYY-MM-DD. Decide whether monetary values will be JSON numbers or strings. The important point is to apply the choice consistently and account for how the destination system handles decimal precision.

Define null behavior too. A missing discount should not alternate between an empty string, zero, “N/A,” and a missing property without a deliberate reason. Use null when the value is unknown or not supplied. Use zero only when the document explicitly indicates zero or a reliable business rule supports that interpretation.

Once the schema is defined, list the variations the workflow must handle. This is a mapping exercise: several source labels and layouts may represent the same target field.

For example, “SKU,” “Product code,” and “Item no.” may all map to item_code. “Qty,” “Ordered,” and “Units” may map to quantity, but only if they have the same business meaning. If one source distinguishes ordered quantity from shipped quantity, combining them would lose important information.

Column position should not be the only cue. A description field might be the second column in one document and the fourth in another. Headings, value patterns, neighboring labels, and the overall document context are more durable signals than fixed positions.

Row boundaries require equally clear rules. A wrapped description should stay with its item. A subtotal row should not become a product. A note such as “Back ordered” may belong to the preceding item, the entire table, or neither. Define these cases before they appear in production.

Normalization makes JSON predictable. Dates such as “14 Feb 2026,” “02/14/2026,” and “2026-02-14” can all become “2026-02-14” when their meaning is unambiguous. Quantities should be returned as numbers if the schema expects numbers, rather than sometimes appearing as text.

Amounts need careful handling. Currency symbols, thousands separators, decimal separators, parentheses for negatives, and trailing minus signs can change interpretation. The document-level currency should be captured when available, but the workflow should not infer a currency from a symbol if the symbol is ambiguous in the relevant context.

It can be useful to retain both normalized and source values for sensitive transformations. For example, a normalized unit_price field can contain 18.5 while unit_price_source contains “$18.50.” This gives reviewers useful context without forcing downstream systems to parse formatting.

Do not manufacture precision. If a PDF says “12,” the output should not suggest that the source explicitly stated “12.000.” Likewise, do not calculate a missing line total unless calculated values are part of the defined workflow and clearly distinguished from printed values.

Review rules turn uncertain extraction into a controlled operations workflow. The team should agree on conditions that require a person to inspect the document and fields that can proceed automatically when present and well formed.

A required document number that is missing should normally be reviewed. So should a quantity containing unexpected text, an unrecognized date format, or a row with a total but no description or item code. When a printed subtotal does not agree with the sum of extracted line totals, the discrepancy should be visible rather than silently corrected.

Not every blank needs review. Optional comments, discounts, or secondary references can remain null when absent. Excessive review rules can slow the process and make important exceptions harder to notice, so each rule should correspond to a real operational risk.

ParseBuddy users can define extraction schemas and review fields that need attention. Completed structured results can be returned as JSON and sent through outbound webhooks. The receiving system should still validate required fields and types before creating or updating records.

Extraction and validation are related but distinct. Extraction identifies the content; validation checks whether the output conforms to the contract expected by another system.

Start with structural validation. Confirm that the response is valid JSON, required properties are present, line_items is an array, and each item uses the agreed field names and types. Then apply business checks. Quantities may need to be greater than zero, dates may need to fall within an acceptable period, and currencies may need to come from an approved list.

Arithmetic checks can identify potential issues, but they should account for tax, discounts, rounding, freight, and document-specific rules. A difference between line totals and a document total is a reason to investigate, not proof that extraction failed.

Keep validation messages specific. “Invalid document” is difficult to act on. “line_items[1].quantity must be numeric” tells an operations reviewer what requires attention.

A single clean PDF is not a sufficient test. Assemble synthetic or appropriately governed test documents that represent the layouts the team expects, including difficult but plausible variations.

Test multi-page tables, repeated headers, wrapped text, empty cells, negative values, discounts, several date formats, scans, and documents with more than one table. Include failure cases, such as a missing document number or a malformed quantity, to verify that review rules activate as intended.

Compare outputs by meaning, not by the order in which text appears in the PDF. The same business record should produce the same JSON fields even when columns move or headings change.

When the schema changes, treat it as a contract change. Adding an optional field is usually easier for consumers to handle than renaming a field or changing its type. Coordinate breaking changes with every destination that uses the JSON.

In an example ParseBuddy workflow, a team begins by defining the extraction schema for document fields and table rows. It then processes sample documents, reviews fields needing attention, and checks the resulting JSON against downstream requirements.

Documents can be uploaded, or supported email attachments can enter an inbound email workflow within the limits shown in the application. Supported workflows include PDFs, images, spreadsheets, and inbound email attachments within those limits.

After review is complete, the structured JSON can be used directly or sent through an outbound webhook. The destination should verify the payload, handle duplicate deliveries according to its own design, and log validation failures without discarding the original context.

The operational objective is a clear path from variable document layouts to a stable data contract: receive the file, extract against the schema, review exceptions, validate the completed result, and deliver it to the next system.

The most common mistake is designing the output around the first document encountered. That creates brittle fields and encourages position-based assumptions. Another mistake is treating every horizontal line as a separate item, which can split wrapped descriptions and produce false rows.

Teams also get into trouble when they mix extraction with unmarked calculation. If the source omits a total, a calculated value should not masquerade as something printed on the document. Finally, sending unchecked output directly into a system of record can turn a minor ambiguity into an operational error.

A durable workflow makes assumptions explicit. It defines the schema, preserves uncertainty, routes meaningful exceptions for review, and validates the final JSON before use.