Every supplier has their own price list format, their own update cycle and their own way of letting you know — email with attachment, FTP link, sometimes a phone call. Someone in your company has to collect it all, open it, spot what changed and type the new purchase prices into the ERP. It's one of those tasks nobody measures until you start looking for where the margin is leaking.
In wholesalers and small manufacturers this topic comes up again and again. A company has 20–60 suppliers, each sending a price list monthly or quarterly, some in Excel, some in PDF, some inline in an email body. Someone in purchasing or accounting does it by hand: copy, paste, fix formatting, find the matching SKU in the ERP, type the new price. Along the way there are typos, missed rows, and cases where the new price kicked in two weeks after the supplier's increase — because the file arrived but no one had "gotten to it" yet.
At one of our clients — a 22-person electrical wholesaler with 40 active suppliers — the head of purchasing estimated that manual price list updates took 2.5 working days per month. After deploying a simple Excel + PDF parsing pipeline with validation before importing into Comarch Optima: 4 hours per month for review and approval. Margin recovered by catching price increases earlier — several thousand PLN monthly, mostly because they started raising their own sale prices in the same week that purchase costs rose.
Why it costs so much when it looks trivial
Manual price list processing has three costs, only the first of which is obvious.
Work time. A head of purchasing with 40 suppliers and an average of 200 items per price list processes several thousand rows each month. One price list takes anywhere from 30 minutes (small, in Excel, clean) to 4 hours (300 rows, scanned PDF, format changed since last time). Total: 15–25 hours a month at a typical client.
Delayed price bumps. If a supplier raised the price on 1 March and you entered the new one into the ERP on 20 March, then for 20 days you were selling with the old margin calculated from the old purchase cost. At 50,000 PLN of monthly purchases and a 3% bump, that's 500 PLN "eaten" on one supplier in one month. Multiply across all suppliers and across a year.
Errors that go quiet. A typo in a purchase price (12.50 instead of 125.00 PLN) won't shout at you immediately. It'll shout six months later, when accounting runs a margin analysis and sees that item X has been running at negative profitability since May. Unwinding that is days of work plus a conversation with a customer you've been selling to below cost for half a year.
Four formats in which price lists usually arrive
Before you automate anything, write down what you actually have on the input side. Our clients usually see a mix of four scenarios:
- Excel with a stable format. Same supplier, same file, same columns every month. The easiest — parse it once and it works for years. Roughly 30–50% of price lists at a typical wholesaler.
- Excel that's "almost the same". Columns in a different order, extra header rows, sometimes the sheet has a different name. Requires a more flexible parser and alerts when "something doesn't fit". Another 30–40%.
- Text PDF. The supplier generates a PDF from their system and emails it. It can be parsed (
pdfplumberin Python,iTextin .NET) provided it's a real PDF, not a scan. 10–20% of price lists. - Scanned PDF / image. The worst case — requires OCR (Tesseract, Azure AI Vision, AWS Textract), and the result still needs manual validation. Usually 5–15% of price lists; worth negotiating with the supplier to send Excel instead.
Less commonly you'll see CSV, a supplier API (one in 40 clients), or downloading from a supplier's B2B portal — if you have any of these, treat them as gold and integrate natively.
Three layers of a good import process
The goal isn't to write "one script that imports the price list". The goal is to build a process that won't surprise you six months later when a supplier changes the format. Three layers worth separating from day one:
Layer 1 — source. A dedicated mailbox (e.g. pricelists@yourcompany.com) that all price lists land in. Suppliers get one address to send to. One SharePoint or FTP folder for larger files. Avoid the situation where the price list lives in a "RE: RE: RE: new prices from March" email thread.
Layer 2 — parsing and validation. A script (Python or .NET, doesn't matter) recognises the sender, picks the right parser and pulls out a list of items: supplier code → name → new net price → currency → effective date. Validation is the key part: does every item map to an SKU in the ERP, does the price change fall within a sane range (e.g. +/- 30%), does the currency match what it historically was.
Layer 3 — approval and import. Parsing results land in a view where a human sees, in a table: "25 items unchanged, 12 with a 2–5% increase, 3 with an increase above 20%, 2 new codes that can't be mapped". The head of purchasing reviews the anomalies, clicks "approve", and only then does the data flow into the ERP via API or CSV import.
That third layer is critical. An automation with no human at the end will sooner or later push nonsense through. A human with no automation in front of them will drown in spreadsheets. Together — it becomes a 4-hour-a-month job instead of a 25-hour one.
Mapping supplier SKUs to your SKUs — the silent killer
The biggest pain on this kind of project usually isn't parsing — it's mapping. The supplier has their code (e.g. EL-KP-2400), you have yours (e.g. KAB-CU-2.5), and nobody keeps this systematically anywhere. Sales people "know they're the same". In practice the mapping lives in two people's heads — if one gets sick, the integration stops.
The solution is boring but effective: a mapping table in a database (or in a SharePoint Excel to start with), with columns supplier | supplier code | ERP SKU | unit | conversion multiplier | date last verified. Populated once, when a new item shows up, and maintained. If the parser hits a code without a mapping, the item goes to an "inbox of new codes", not silently into oblivion.
Good habit: once a quarter, run a report of "mappings unused for 12 months" and "mappings with unit mismatches". The supplier catalogue lives, codes age, multipliers change (the supplier stopped selling 100 m spools, now they're 50 m).
Build or buy
There are off-the-shelf products (Comarch OCR for invoices has partial support for price lists, there are dedicated products like Vendorlink, there are Symfonia modules). Our typical recommendation:
- Fewer than 10 suppliers and only Excel files — a ready-made tool is overhead. A simple Python script running weekly will do.
- 10–50 suppliers with mixed formats — the best cost/benefit ratio comes from your own lightweight pipeline (Python + mapping table + a simple approval UI). 2–4 developer weeks, then maintenance in the range of a few hours a month.
- 50+ suppliers including PDFs and OCR — worth comparing an in-house build against a commercial product (Vendorlink, Prisync, dedicated ERP modules). Break-even is usually on the commercial side.
We rarely see the "build vs buy" answer as clear-cut as vendors claim. Annual cost usually lands in the same category — the details decide (integration with your specific ERP, support for your currencies, mapping flexibility).
A 6-week rollout plan
At a 20–40-person client a typical project runs like this:
- Week 1: supplier audit. Inventory of all price lists, formats, frequencies, sizes. Pick 3–5 "starter" suppliers (highest volume, most stable format).
- Week 2: dedicated mailbox and mapping table. Set up
pricelists@, create the mapping table and populate it for the pilot suppliers. - Weeks 3–4: parsers and approval view. Scripts for the pilot formats, a simple UI (could be Streamlit or a Power Apps form) for approving changes, integration with the ERP API.
- Week 5: parallel run. The new process runs alongside the manual one; results are compared. All the edge cases surface — a different currency on one price list, an extra column-based discount that wasn't in the spec.
- Week 6: expansion. Onboarding further suppliers, writing more parsers. This phase never really ends at 100% — there's always a supplier whose price list arrives once every six months and "we'll deal with them then".
Three mistakes worth avoiding
- Auto-approving increases above 10%. Always leave a human to check. A 40% jump is usually a PDF parsing error, not a real cost increase.
- No price history. Store versions of price lists and effective dates in a database. Six months from now someone will ask "how much was this in March" and you'd better have an answer.
- No alert when a supplier didn't send a list. If supplier A sends monthly and you've got nothing for two months — something's up. Maybe they changed the email address, maybe they went out of business. A simple calendar alert or a monitoring tool entry is enough.
What next
Supplier price list imports are one of those areas where automation shows results in the first month. You don't need a 100k-PLN platform for this — you need a few developer weeks, discipline in maintaining the mappings, and a process where a human approves anomalies.
If you'd like to see what this could look like for your specific supplier mix and ERP, half an hour of conversation is usually enough to break the project into phases and estimate the cost.
A supplier price list sitting in an inbox for two weeks costs you more than the automation that would import it.