Supplier data onboarding with LLMs: price lists, PDFs and certificates

Supplier data onboarding is the work of getting product data from external suppliers, price lists, specs, images and certificates, into your PIM in a correct and mapped form, and keeping it current when prices and assortments change. Unlike your own ERP-to-PIM sync, the format is negotiated, not controlled: hundreds of suppliers, no API, and Excel, CSV, BMEcat and PDF in every dialect.

Large language models finally make the PDF tier of this work automatable. This article covers when not to use them, how to route each file, how to extract price lists with evidence, which validations must run before any mapping, how to handle updates and republishes, how to score suppliers, and what faster onboarding is worth.

What does supplier onboarding actually involve?

It is one pipeline for three input classes, multiplied by three cadences and by every supplier you work with. The input classes are structured feeds such as BMEcat, CSV and Excel; semi-structured documents such as PDF price lists and datasheets; and unstructured material such as scanned certificates. The cadences are the initial load, the monthly price update and the republish when an assortment changes.

The metric that matters is time from “supplier sends file” to “SKU is listable and correct”. GS1 puts numbers on the manual path: retailers need 10 to 15 interactions with suppliers to launch each SKU and spend 5 to 10 hours training a brand partner on their data requirements, while brand owners manage around 700 attributes per SKU (GS1; GS1’s published figures, without a stated survey year). Every interaction you remove from that loop brings the listing date forward.

Why parse structured feeds without a model?

Because a deterministic import of a contractual format is faster, cheaper, repeatable and auditable, and a model adds only risk there. Where a parser exists, do not spend tokens.

In DACH B2B the contractual format is often BMEcat, whose current version is 2005.2, published by the German purchasing association BME with specification, DTDs and XSDs (BME). It defines separate transactions for a new catalog, product updates and price updates, which maps directly onto the three cadences. Version drift is real, though: the marketplace Unite still specifies BMEcat 1.2 for its suppliers and lists common errors (Unite), so the reader has to normalize element names across versions. ETIM is moving to a JSON format of its own, ETIM xChange, currently version 1.1, with a mapping to ETIM BMEcat and a validation tool (ETIM).

PIM platforms cover this tier without code. Pimcore’s Data Importer reads CSV, JSON, XML, XLSX and SQL results from six source types, including SFTP and a push endpoint, resolves create versus update, skips unchanged records with a delta check and runs on a schedule with detailed logs (Pimcore). Akeneo ships a dedicated Supplier Data Manager for collecting supplier product information (Akeneo). If your own master data already flows from the ERP, the Pimcore ERP delta sync pattern is the internal counterpart of this intake.

How do you choose the route for each supplier file?

Ask three questions in order and take the first route that answers yes. The cheapest reliable route wins, and a file that no route can read goes back to the supplier rather than into a model.

The LLM row is arithmetic on Anthropic’s published prices, not a benchmark: 10,000 rows at about 1,000 input tokens each is 10 million input tokens, or $0.50, plus about 1.5 million output tokens, or $0.38. Retries, image tokens for scans and long pages raise it, and newer Claude models use a tokenizer that produces about 30% more tokens for the same text. Even so, model fees are rarely the cost that matters; engineering, review minutes and chasing suppliers are. Bulk runs like this belong on a batch API, as described in batch APIs for offline LLM workloads. OCR prices are from Amazon Textract.

How do you extract PDF price lists with an LLM?

Get the text layer or OCR first, then extract into a schema per supplier template with a row anchor, the page number and a confidence per field, and reconcile the result against what you expect. You cannot reliably extract what the parser cannot see, so the layout step comes before the model; the options are compared in PDF parsing for RAG and Unstructured.

{
  "supplier": "S-0412",
  "template": "acme-pricelist-v3",
  "page": 4,
  "rowAnchor": "Art.-Nr. 70.112.04",
  "supplierPartNo": "70.112.04",
  "gtin": "4012345678901",
  "description": "Kabelverschraubung M20x1,5 IP68",
  "price": { "value": 1.84, "currency": "EUR", "per": 100, "unit": "PCE" },
  "packaging": { "level": "case", "quantity": 50 },
  "confidence": { "price": "high", "per": "medium", "packaging": "high" }
}

Two reconciliations catch most extraction errors. First, row counts: if the price list says 312 positions on page one and the extraction returns 309, something was dropped or merged. Second, variant axes: if a product comes in four sizes and three materials, there should be twelve rows, and a missing combination is either a real gap or an extraction miss that a person has to decide. Vision models help with scanned lists and spec tables full of tolerances; they hurt on clean spreadsheets, where a sheet reader is exact and a model can only add noise.

Which validations must run before mapping?

GTIN check digits, units, currency, price basis and packaging level, all deterministic, all before any mapping or review. These are the checks where a model can only make things worse, because the right answer is computable.

// GTIN-8/12/13/14 check digit: weights 3 and 1 alternate, starting with 3 next to the check digit
export function isValidGtin(raw: string): boolean {
  const gtin = raw.replace(/\s/g, '')
  if (!/^(\d{8}|\d{12}|\d{13}|\d{14})$/.test(gtin)) return false
  const digits = [...gtin].map(Number)
  const check = digits.pop()!
  const sum = digits.reverse().reduce((acc, d, i) => acc + d * (i % 2 === 0 ? 3 : 1), 0)
  return (10 - (sum % 10)) % 10 === check
}

• GTIN: the check digit is calculated from all other digits, and GS1’s calculator covers GTIN-8, -12, -13 and -14 (GS1). A failing check means the value is wrong; send it back, never ask a model to repair it.
• Price basis: per piece versus per 100, per meter versus per square meter. A price that is off by a factor of 100 passes every format check and fails only a plausibility check against the previous price list.
• Packaging levels: single unit, case and pallet carry different GTINs and dimensions; mixing them breaks logistics. GS1 US notes that a quarter-inch error in case height can mean 20 times fewer cases per pallet and six times more trucks than necessary (GS1 US).
• Units and taxonomy: ETIM requires a unit on every numeric and range feature and gives each unit a language-independent identifier (ETIM), a natural target for normalizing supplier units. Classification and dedup of records already inside the PIM are covered in PIM data quality with LLMs.

Store the canonical value next to the original string, the mapping version and the source document with page and row, so any value in the shop can be traced to the line in the supplier’s file it came from.

How do you handle price updates and republishes?

Detect what changed and apply only that, with rules for what a supplier file may overwrite. Use a file hash to skip identical deliveries, a row hash per natural key, usually the supplier part number, to find changed rows, and BMEcat update transactions where the supplier sends them instead of full-replace files.

• Never overwrite negotiated prices. A supplier’s list price is an input to your purchase price, not to the customer-specific prices in your pricing engine.
• Detect schema drift. A changed column order or a new column should stop the import for that supplier and alert a person, not shift every value one column to the right.
• No news is not an update. A supplier that stops sending files has not confirmed that prices are unchanged. Track the age of each supplier’s latest price list and flag it when it passes the agreed cadence.

What should a supplier scorecard measure?

It should measure the quality of what each supplier sends and set how much of that supplier’s data flows without a person. GS1 US’s National Data Quality Program defines data quality through three components, data governance with assigned owners and audits of new items, education and training, and a physical audit that compares the actual product with the shared data (GS1 US). A digital scorecard translates that into numbers per supplier:

• completeness of required attributes and media coverage
• GTIN validity rate and price-basis anomalies
• time from file received to SKU listable
• confidence distribution of extracted fields and the human correction rate
• age of the latest price list against the agreed cadence

The scorecard drives three decisions: which suppliers get automatic publishing, which go through review, and what purchasing asks for in the next negotiation, such as a template, BMEcat delivery or a data-quality clause.

What is faster supplier onboarding worth?

It is worth an earlier listing date per SKU, a broader assortment per team, fewer wrong-unit orders and better facts in supplier negotiations. No published study measures the return of LLM-based supplier onboarding specifically, so present the mechanics and measure your own baseline.

• Speed to revenue: each of GS1’s 10 to 15 supplier interactions per SKU is a delay before the item can sell.
• Assortment breadth: a Zoovu-commissioned survey of more than 400 B2B executives found 83% describe their product data as incomplete, inconsistent, inaccurate, unstructured or outdated (Business Wire, Feb 2024; vendor-commissioned). The team that onboards suppliers sets the ceiling on how many products you can sell online.
• Returns and logistics: wrong specs and packaging data become returns and wasted freight; GS1 US reports that 80% of retailers are not confident in their product data.

For a head of e-commerce, PIM manager or head of procurement, the honest framing is an onboarding pipeline with a measured done-criterion: the share of rows published without a human touch and the correction rate per supplier. After more than ten years of Spryker and Pimcore work, I see supplier onboarding as the job that never ends; LLM extraction makes the PDF tier automatic, while the Excel tier was always a mapping problem.

Checklist, and when not to use an LLM

Do not use an LLM where a deterministic parser exists, where a supplier portal with a fixed form would collect the data cleaner, or where rejecting the file and asking for a template is the right answer. Every supplier also needs a human fallback: an email address, an attachment and a manual queue that always works.

1. Classify suppliers by format archetype and route each to the cheapest reliable parser.
2. Quarantine every incoming file and record its hash before processing.
3. Validate GTIN, units, currency, price basis and packaging deterministically before mapping.
4. Extract PDFs into a schema per template with row anchors, page numbers and confidence.
5. Reconcile row counts and variant combinations against expectations.
6. Block overwrites of negotiated prices and stop imports on schema drift.
7. Keep a golden set per format archetype and re-run it on every model or prompt change.
8. Publish a scorecard per supplier and tie the automation level to it.

A fixed-scope pilot with 10 to 20 suppliers across two or three format archetypes is enough to measure the touch-free share and the correction rate before connecting more. If you want help scoping one, see my B2B e-commerce work.

Sources

1. GS1: Everyone needs better product data (Global Data Model)
2. BME: BMEcat downloads (version 2005.2)
3. ETIM International: exchange format (ETIM xChange)
4. ETIM International: model information
5. GS1: check digit calculator
6. Pimcore: Data Importer
7. Akeneo: Supplier Data Manager
8. Amazon Textract pricing
9. Anthropic: Claude pricing
10. GS1 US: data quality
11. GS1 US: National Data Quality Program
12. Unite: catalogue format BMEcat 1.2