From Supplier PDFs to Product Data: Where AI Needs a Second Check

By Greg Nowak. Last updated 2026-09-07.

A price extracted from a supplier PDF can look perfectly reasonable and still be wrong for your catalogue. It might belong to another SKU, refer to a pack rather than a single item, or lack a currency. Before importing it, someone needs to settle those questions.

AI can help interpret awkward layouts and inconsistent wording. A dependable workflow also needs checks between extraction, identifier matching, normalization and import. Those checks give the catalogue team evidence that a record is ready, and a clear way to deal with it when it isn't.

Account for the whole supplier file

PDFs and spreadsheets take different routes through OpenAI’s file-input processing. For vision-capable models, PDF input supplies both extracted text and page images. Spreadsheet augmentation parses up to the first 1,000 rows per sheet, then adds summaries and header metadata. That limit belongs to this particular input path, as described in OpenAI’s file-input guide.

For a catalogue team, this matters before any field-level checks begin. A spreadsheet response does not establish that the whole workbook was processed. Have the Python ingestion step read every relevant sheet and row deterministically, and use AI where the document’s layout or wording needs interpretation.

Keep an intake record with the original filename, sheet or page references, and processing status. Agree which spreadsheet rows count as products and record exclusions such as headings and totals. With PDFs, track page coverage and product completeness separately. Reading every page does not prove that every product on those pages was captured.

Define what an extracted record must contain

Ask for a consistent set of fields: supplier identifier, description, raw price, currency, measurement and source location. Keep the supplier’s original wording alongside the proposed interpretation. Missing information should remain visible, with unsupported values left empty.

Structured Outputs helps enforce that response schema. It does not establish that the values are correct: OpenAI’s documentation explicitly warns that structured output can still contain mistakes. Business rules need to check the result separately.

Require each critical value to be traceable to the source, and verify page references supplied by the model. If a price has no clear currency or selling unit, retain the evidence and flag the record. A filled-in field is not enough to approve an import.

What to check before a supplier record moves towards import

Stage	Ready to proceed when	Hold for review when
File intake	Relevant sheets, rows and pages are accounted for, with product completeness checked separately	Coverage is incomplete or excluded records have no explanation
Extraction	Critical values can be verified against the source	A value is missing, ambiguous or unsupported
Identifier matching	The match follows the agreed supplier-to-SKU relationship	An identifier is blank, unmatched or unexpectedly repeated
Normalization	Rules define the units, currency, price basis and attributes	A conversion depends on an unconfirmed assumption
Staging import	The expected records, fields and product relationships appear correctly in the destination	Rows are skipped or the imported products differ from the approved data

Match the SKU before changing its data

Agree how supplier identifiers map to catalogue SKUs. If identifiers are specific to a supplier, include that supplier in the matching key. Store identifiers as text, and settle any cleanup rules before applying them. Leading zeros and punctuation may be meaningful.

Python’s pandas library provides controls for this step. A left merge can retain incoming records, and indicator=True shows which keys matched. The validate parameter checks the expected relationship: one_to_one requires unique keys on both sides; many_to_one requires uniqueness on the right. The pandas.merge documentation also warns that null keys can match each other.

Reject blank identifiers before matching, then investigate any result that breaks the agreed relationship. Silently dropping duplicates hides a decision the business needs to make: do those repeated identifiers represent valid separate records or conflicting entries?

Put unmatched records in a separate review queue. A similar product name can help someone investigate, but it should not authorize a change to an existing SKU.

Agree what the values mean

Write normalization rules with whoever owns the catalogue data. Specify the destination unit for each measurement, the accepted attribute vocabulary and the meaning of numeric separators in each supplier format. Keep raw and normalized values side by side so reviewers can see what changed.

A column labelled “weight”, for example, needs a definition before anyone converts it. Product weight, shipping weight and pack weight describe different things. Confirm both the meaning and the source unit before doing the arithmetic. If either is missing, hold the record until it is clarified.

Prices need the same care. Separate the amount, currency and price basis. Establish whether the price covers one item or a pack, and confirm the applicable tax treatment. Removing a currency symbol changes the formatting. Converting the amount to another currency requires an approved rule that can be reproduced in code.

Give reviewers enough to make a decision

The workflow should produce approved records and an exception report. For each exception, show the source location, original value, proposed value, failed rule and decision needed. Give those decisions an owner, whether the question concerns a pack quantity or a new supplier-to-SKU mapping.

Before export, account for every incoming product record as approved, held or deliberately excluded. If one source record creates several destination rows, preserve that relationship so the counts can be explained. Matching totals are useful, but they cannot establish that the right records made it through. Keep the record-level trail as well.

Some approved corrections can become reusable rules. Others are judgments about a single record and should stay attached to it. Making that distinction gives the next run a useful starting point without applying a one-off correction to unrelated products.

Test a small import in staging

WooCommerce recommends normalizing supplier files and testing a small sample before importing the full catalogue. Its product CSV importer guide also covers unique SKUs for variations, consistent parent references and attributes, removal of unsupported formatting, and saving the file as UTF-8 CSV.

Build the destination export from approved records only. Choose a staging sample that covers the transformations you intend to use, including an existing-product update and variations where relevant. Check skipped and failed rows, then inspect the products themselves against the approved data. Resolve discrepancies before increasing the batch size.

A focused GrN project could put these steps into a Python/OpenAI pipeline: complete spreadsheet ingestion, AI extraction for irregular documents, identifier checks, agreed normalization rules, batch reconciliation, an exception report and a staging CSV.

Greg could help define what a record must pass before import and build the workflow around your supplier files and destination catalogue. Bring a representative supplier file and a catalogue export to scope the first import, the checks it needs and the decisions your team will need to make.

Related on GrN.dk

Need help with this kind of work?

Discuss your supplier-data workflow Get in touch with Greg.

Sources

Last modified

2026-09-07