A trading company planned its purchasing in spreadsheets built by hand from three separate accounting databases. We built the system that replaced them: demand forecasting, requirement calculation, supplier orders with a four-stage approval chain, budgets, a payment calendar and an external supplier portal — with one rule running through all of it, that every calculated number on screen can be opened to show the formula it came from.
Purchasing decisions for thousands of SKUs were made in spreadsheets, assembled by hand from several accounting systems that did not agree with each other: a catalogue and sales database in one place, item parameters such as production time, minimum order quantity and delivery days in an accounting system on another engine, and supplier order statuses in a third. Every planning cycle started with the same reconciliation work before anyone could think about what to actually order. Worse, the resulting numbers were unauditable — a buyer produced a quantity, and a head of purchasing approving it had no way to see whether it accounted for goods already in transit, for seasonality, for the replenishment interval or for a one-off wholesale order that had distorted last year's sales. Approvals therefore ran on trust rather than on evidence, and the same argument was reconstructed from memory every month. Any replacement had to do two things at once: consolidate the data, and make the arithmetic legible to people who did not write it.
An importer pulls products, categories, brands, suppliers, sales, deliveries, stock history, prices and item parameters out of three separate accounting systems into a single planning database, incrementally and on a schedule. Reads are one-way, so planning never writes back into the systems of record and cannot corrupt them.
Each SKU is profiled monthly for variability, trend slope, seasonal index and history depth, and the forecast method is selected automatically: moving average for short or stable histories, trend-adjusted for genuine slopes, seasonal decomposition where at least a year of history supports it. Every forecast carries a confidence level and a written justification, and a backtest replays the model against history to show how accurate it would have been.
Stock is projected forward through each in-transit arrival in turn, then compared against planned demand over the replenishment interval for that item's rating, then rounded to what can actually be ordered — minimum order quantity and carton multiples, with a wider overshoot tolerance allowed for top-rated items and a recommendation to postpone when the rounding would be wasteful. Every intermediate value is shown, not just the final quantity.
A growth coefficient compares the last twelve months against the previous twelve, after smoothing out one-off wholesale orders that would otherwise distort a whole SKU's history. Coefficients resolve from the narrowest available level — item, model, category, brand — and a manually set coefficient always beats the calculated one. Cases that need a human decision, such as no baseline history or implausible growth, are flagged for review rather than applied silently.
Items are classified by sales value and by demand variability into a class matrix, each class carries its own service-level policy, and from those the system derives safety stock, target stock, the gap in units and the investment required to close it. A what-if mode recalculates the whole picture against temporary overrides without saving anything.
Buyers collect items into a basket, which becomes a draft order with a public number allocated atomically so parallel drafts never collide. The order then moves through a four-stage approval chain — buyer, head of purchasing, brand manager, brand head — where empty stages are skipped, each stage can edit quantities line by line, and an immutable snapshot taken on entry lets the final order be diffed against what was originally proposed.
Supplier payment terms expand into an actual schedule of payments — instalments tied to order, shipment or delivery dates with their own offsets — which feeds a payment calendar where individual payments can be moved or overridden. Purchase and sales budgets track utilisation and overruns, cash-movement lags are configurable, and exchange-rate scenarios stress-test the plan against currency movement.
Suppliers get access without any corporate account, through a single-use magic link of which only a hash is stored, and see nothing but their own orders. Each order carries a two-way chat with attachments and a downloadable order form generated from an editable template in the supplier's language. Access is denied with a not-found rather than a forbidden, so the portal never reveals that an order exists.
Every calculated figure in the interface carries an information marker that opens the formula and the inputs it was computed from. This is a project rule rather than a feature of one screen, and it is what makes an approval chain meaningful: a reviewer can check the arithmetic instead of trusting the person who produced it.
The planning cycle now starts from one consolidated database instead of a manual reconciliation between three, and the quantity a buyer proposes arrives at each of the four approval stages with its formula attached. Forecasting, requirement calculation, inventory policy, budgets and the payment calendar sit on the same data, so a change in one is visible in the others rather than in someone's separate spreadsheet. Suppliers were brought inside the same system through a portal and per-order chat, which moved order correspondence out of personal mailboxes. It is the largest system we run, in daily production use and under continuous development.
Tell us what the process looks like today and we will tell you what can be automated — and what should not be.
LET'S TALK
