If your business runs on dropship fulfilment, you already know the problem. You have dozens of suppliers and each one has their own way of communicating stock information, if they communicate it at all. One sends a weekly Excel file by email. Another updates a spreadsheet on a shared drive. A third has an API, in theory. Several just don't send anything until you chase them.
Your team ends up spending a meaningful chunk of their week trying to pull all of that together into something the website can actually use. Products show as available when they've been out of stock at the supplier for a fortnight. Others are hidden when stock has long since been replenished. The site isn't lying on purpose; it just has no reliable way to know the truth.
This is a solvable problem. It just needs to be built properly.
The engagement
We were brought in to replace a manual, fragmented supplier data process with something scalable and automated. The business was operating across more than fifty suppliers, the vast majority on a dropship model, with no standardised way to receive or process stock information from any of them.
Data arrived through ad hoc emails, attached spreadsheets, and occasional one-off processes, each in a different format, with different column headers and different update frequencies. When data didn't arrive there was no alert. When it did arrive, processing it was largely manual. There was no audit trail, no visibility of feed health, and no scalable way to bring new suppliers on board.
The operational impact was real. Oversells on products the supplier no longer held, missed sales on products that had come back into stock, and a manual processing burden that ate into staff time every week with no obvious way to reduce it.
We designed and delivered a platform to fix that end to end.
What we built
Meeting suppliers where they are
The first problem to solve was ingestion. Suppliers vary enormously in technical capability and any solution that requires them all to adopt a standard format is going to fail. Some can call an API. Others can only send an email. Asking them all to do the same thing isn't realistic.
We built a Stock Portal, a purpose-built web application that accepts stock data through five channels: CSV upload via a browser portal, email attachment, SFTP, hosted URL polling, and REST API. All five feed into the same automated processing pipeline. From the platform's perspective it doesn't matter how the file arrived. From the supplier's perspective, they don't have to change anything about how they work.
The portal is built to handle the variability that comes with a large, diverse supplier base. Flexible CSV parsing accommodates the full range of column headers, delimiters, and file encodings that come in from real suppliers without requiring any of them to reformat their output. Per-supplier validation rules cover row-count thresholds, duplicate detection, and expected delivery windows, so the platform knows what to expect from each supplier and can detect when something looks wrong.
Visibility across every feed
One of the consistent failure modes in manual processes is that problems stay invisible until they cause a customer issue. A feed that stopped updating three days ago looks identical to one that updated an hour ago, right up until a product goes out of stock and the site doesn't reflect it.
The portal addresses that directly. Tiered staleness detection monitors every supplier feed continuously and escalates through configurable alert levels as feeds age past their expected update window. The admin dashboard gives the operations team a single view of the health of every supplier feed: when it was last received, last processed, its current status, and any validation errors. When something goes wrong, the team finds out before it becomes a problem on site.
Suppliers have their own portal view where they can upload files, check their item visibility, and track the status of their most recent submissions. That transparency tends to improve engagement from the supplier side too. When they can see that their data is being received and applied, they're more likely to keep it up to date.
Every file received, every validation run, every sync to the ERP is written to a full audit trail. If there's ever a question about what data was received and when, or why a product showed a particular stock level on a particular day, the answer is in the platform.
NetSuite integration with fallback logic that actually works
Stock data coming into the portal is only valuable if it drives the right behaviour downstream. We built a structured integration layer within NetSuite that governs how incoming stock data influences the rest of the business.
This goes well beyond updating a stock level. The field model covers stock quantities, feed health status, fulfilment type, restock forecast dates, and back-order eligibility, giving NetSuite a complete picture of each product's stock position rather than just a number.
The most important part of this layer is the fallback logic. Supplier feeds fail. Connections drop, files don't arrive, something changes on the supplier's side. When that happens the business needs to make a call: preserve the last known stock level and accept some oversell risk, or zero the stock and prevent oversells until the feed recovers. Neither answer is right for every situation; it depends on the supplier relationship, the product, and the commercial context. The platform supports a configurable per-supplier fallback mode so that decision is made deliberately and enforced automatically, rather than being made by accident through inaction.
Back-order eligibility is driven by restock dates and live feed health. If a feed goes stale, back-orders are suppressed automatically. Stock transition detection picks up when products return to availability, which opens the door to downstream actions when something moves back into stock. Print-to-order and made-to-order product types are handled separately so manufactured items stay completely isolated from the stock-feed logic governing dropship products.
Clean data for the website
The final layer is what makes everything visible to customers. We built a comprehensive set of NetSuite fields and Saved Searches that give the eCommerce platform everything it needs to display accurate stock messaging: whether a product is available now, whether it can be back-ordered, when it's expected back in stock, and what purchasing rules should apply.
Rather than encoding logic directly in the website, this approach centralises stock governance in NetSuite where the data lives and exposes clean, reliable signals to the front end. The website team can build product page behaviour from that data without needing to understand the supplier feed mechanics behind it. When the rules change, they change in one place.
The outcome
The business now has a stock management pipeline that runs without manual intervention under normal conditions. Stock data flows from supplier submission through validation, into NetSuite, and out to the website. Feed health is monitored continuously. Fallback behaviour is defined in advance. The audit trail is complete throughout.
Onboarding a new supplier no longer requires a development cycle. Each new supplier is configured against the existing ingestion channels and the platform handles the rest. What previously took bespoke work is now an operational task that takes minutes.
The manual processing that consumed staff time every week has been replaced with exception-based operations. The team's attention goes to feeds that have flagged a problem, not to a routine of chasing and processing that was never a good use of their time.
Technology
- Stock Portal: Python / Flask, PostgreSQL, server-rendered with HTMX, hosted on AWS (Gunicorn, Nginx, systemd)
- ERP integration: NetSuite REST API (OAuth 1.0 TBA), SuiteScript 2.1 Map/Reduce
- Email processing: Postmark inbound webhooks
- SFTP: Chrooted per-supplier SFTP with isolated directory access
- Authentication: Azure AD SSO for admin users; bcrypt + TOTP 2FA for supplier portal accounts
If your business depends on supplier stock data and you're still handling it manually, the cost is almost certainly higher than you think, in staff time, in customer experience, and in the risk that comes from having no visibility into whether your data is current or can be trusted.
We'd be glad to talk through what a platform like this would look like for your operation. Get in touch.