In a small manufacturing company, daily work with suppliers usually looks like this: a purchasing clerk sends a PO as PDF, someone calls to confirm, then another call about the delivery date, then an email "please add 200 more units", then a text "supplier is two days late, urgent". Every day, all over again, for 30–50 suppliers. It doesn't scale in any simple way.
A supplier portal is usually the first custom application that actually saves a few hours a week in purchasing and quietly tidies up the rest of the process — without a huge rollout and without replacing the ERP.
This piece is soberly about it: what such a portal does, when it pays off, when it's a waste, what the ERP needs to have, and how long the whole thing really takes.
What it is and what it really does
A supplier portal is a small web application that each recurring supplier logs into to see their slice of the purchasing process. Nothing more. It doesn't replace the ERP. It doesn't revolutionise purchasing. It straightens one narrow but painful section.
The typical scope that works well in an SME:
- List of open POs — the supplier sees only their own POs, with quantities, prices, expected date.
- Confirm or counter-propose — one click: "date accepted", "moved to X", "no stock, alternative proposed".
- Advance shipping notice (ASN) — supplier enters ship date, waybill number, optionally a photo of the pallet.
- Delivery documents — GRN, CMR, quality certificate, spec sheet — all in one place, tied to the PO.
- Settlements history — supplier sees invoices and payment status without writing to accounts.
Everything else — prices, negotiations, frame agreements, addenda — still happens outside the portal. That's a feature, not a gap. The portal must be simple for the supplier to adopt, because otherwise the smaller ones won't use it and the process stays doubled up.
A real example
One of our clients, a 32-person meat processor in south-eastern Poland, worked with about 40 recurring suppliers (meat, packaging, spices, sanitary chemistry). Two people in purchasing were spending, together, about 9 hours a week on phone and email confirmations of deliveries. On top of that came regular disputes: the supplier claimed no one had asked for a date change, we claimed the opposite. Everything lived in three different people's mail folders.
We built a portal integrated with their Comarch Optima (POs flowed from the ERP into the portal, confirmations returned to Optima as a delivery-date update). Our side of the rollout took 6 weeks, plus 2 more for onboarding suppliers and first tweaks.
After three months:
- Time spent on delivery-confirmation calls and emails dropped from ~9 to ~2 hours a week (about 7 hours recovered).
- The number of "who changed what" disputes fell to essentially zero — everything is timestamped in the portal.
- 34 of 40 suppliers use the portal routinely. The 6 smallest still phone in, and that's fine — no point forcing a supplier you place 3 orders a year with.
The project paid back in under a year through purchasing hours alone. The real gain was bigger — fewer disputes mean fewer emergency purchases at more expensive suppliers when the production plan falls apart.
When it's worth it, when to skip
A supplier portal is not for everyone. It's worth committing to if you tick at least two of three boxes:
- You have at least 15–20 recurring suppliers, working with you on a weekly (or denser) rhythm. Below that, a phone call is simply faster than logging into anything.
- Purchasing really eats at least half an FTE a week just on communicating with suppliers. Below that, the ROI looks weak.
- You have recurring disputes about dates, quantities, or documents — the kind that end with someone digging through email to prove who was right.
Skip it if your purchasing is mostly one-off (project by project, new suppliers every month), if your suppliers already run their own portals that force you to log in on their side (then your portal is your problem, not theirs), or if you're under 10 people and the owner does purchasing after hours. In those situations, a solid shared mailbox with Outlook templates beats it.
What the ERP needs to have
The supplier portal doesn't run in a vacuum. For it to make sense, your ERP must:
- Hold clean supplier data — one counterparty, one tax ID, one portal account. If in Comarch Optima you have "Meat Kowalski", "Kowalski Meat Ltd" and "P.P.H.U. Kowalski" as three separate records sharing one tax ID, the portal will expose that in the first week.
- Issue POs with a clear number, quantity and price — the portal reads them, it doesn't create them. If the PO mostly lives in a purchaser's Excel, tidy the process in the ERP first.
- Allow the delivery date to be written back — via API or at least a sane import mechanism. If your ERP can't do that (it happens with older Microsoft Dynamics AX or Subiekt installs), you need a middleware layer, and that's the first real cost of the project.
These are boring prerequisites, but skipping them ends in a portal that technically works while operationally nobody trusts it, because the data in the ERP and the portal keep drifting apart.
What next
If you recognise this pattern in your purchasing — 9 hours a week on chasing and regular date disputes — there are two things worth doing before you talk to any software vendor.
First, for one week, count honestly: how many calls, how many emails, how many "what about this delivery" threads, how many hours. Without that number, nobody can sensibly judge whether the portal will pay back.
Second, look at the state of the supplier list in your ERP. Duplicates, missing tax IDs, several records for the same counterparty — if you see that, that's your project zero. A portal rolled out on crooked data just moves the mess to another screen.
If you want to talk about how such a portal looks concretely under your company's conditions, book a no-obligation call. Half an hour is enough to judge whether it's worth considering at all.
A supplier portal won't replace your purchasing officer. But it will stop burning a full working day of their week on "are we confirming the date" calls.