From a change in the data to a decision someone can stand behind.
A distribution business generates a continuous stream of small events: an order, a receipt, a cost change, a late delivery, a credit hold. Individually they are trivial. Together they decide whether you make money. Wholara exists to keep that stream from ending up as someone's spreadsheet at the end of the week.
Wholara is an operating layer
It sits above the systems that hold records and below the people who make decisions. It reads what is happening, works out what it means, prepares the response, and — within limits you set — carries it out.
It is not a robot that runs your company
Wholara does not set your commercial policy, negotiate with suppliers, or decide what service level your customers deserve. Those are your decisions, and they are the inputs to the system rather than outputs of it.
Six stages, repeated continuously.
Not a nightly batch process. The loop runs as events arrive, which in a busy distribution business means all day.
Orders, receipts, stock movements, cost changes, deliveries and payments are recorded as they happen.
Availability, cover, exposure and margin are recalculated from those events rather than rebuilt on a schedule.
Rules and models look for the conditions you care about: cover falling under target, a promise slipping, a price crossing a floor.
Options are generated and scored against cost, service, margin and urgency to produce a recommendation.
Below your threshold it commits. Above it, a human decides with the reasoning already on screen.
The action, the inputs, the approver and the outcome are written to the audit trail in the same transaction.
What just happened
Elapsed time from event to approved action: three minutes. The same sequence in a spreadsheet-and-email process typically completes the following morning.
What "state" means here
Wholara keeps a live operational picture, not a table of transactions. For every item, customer and supplier it maintains the attributes a decision actually depends on:
- On hand, committed, inbound, available, in transit between locations
- Demand rate over multiple windows, not one average
- Supplier lead time and reliability, derived from your receipts
- Cost basis: latest, average, replacement and standard
- Effective price per customer, and the margin at that price
- Credit limit, exposure and overdue position
How a recommendation is actually calculated.
No magic, and no hidden model you have to take on trust. This is the mechanism, using a reorder decision as the example.
-
Establish demand
Consumption is measured over several windows rather than one average, so a promotion, a seasonal peak or a new contract does not get smoothed into invisibility. Where a customer's ordering is genuinely regular, their pattern is used; where it is erratic, the category behaviour carries more weight.
-
Establish supply reality
Lead time comes from your own receipt history for that supplier and category, not from the number typed into the item record. Variation matters as much as the average: a supplier who is usually quick but occasionally very slow needs different cover from one who is consistently average.
-
Work out the gap
Projected cover is compared against your service target for that category, accounting for committed orders, inbound receipts and stock sitting elsewhere in the network that could be moved instead of bought.
-
Generate the options
A purchase is not the only answer. The engine tests buying, transferring from another location, substituting an equivalent item, splitting a delivery, or accepting a short-term service risk — and prices each option including freight and the effect on margin.
-
Apply your commercial constraints
MOQ, pack size, deal breaks, payment terms, supplier agreements, storage limits and cash position are applied as constraints, not afterthoughts. This is what stops a mathematically correct suggestion from being commercially unusable.
-
Score and present
Options are ranked by a combination of service risk, cash impact, margin effect and urgency. The recommendation arrives with the inputs attached, so a buyer can trace exactly why the number is what it is — and disagree with the reasoning rather than the output.
Worked example · SKU-1842
Recommendation: order 240 units from Orion Materials at $52.00 landed, arriving 5 June. This holds cover above the 98% service target through the lead time including its observed variation, and rounds to the pack size of 6. Cost impact $12,480; no customer orders are put at risk in the interim.
What would change the answer: a 20% rise in demand would push the quantity to 300 and cross the 250-unit deal break, which the engine would flag as a decision rather than assume. A supplier lead time falling back to 10 days would remove the recommendation entirely for another fortnight.
What Wholara needs from your systems.
Less than most people expect, and nothing that requires replacing a system you already run.
The operational minimum
These six record types are enough to run replenishment, pricing and order validation. Everything else adds depth:
Items
Codes, descriptions, units, categories, supplier references, pack and MOQ
Inventory
On hand by location, committed quantities, inbound receipts
Customers
Accounts, delivery points, price agreements, credit position
Suppliers
Vendor records, terms, agreed costs, MOQ and lead times
Orders
Sales order lines with prices, and purchase order lines with costs
Movement history
Enough transaction history to derive demand patterns and real lead times
How the data gets in
Three routes, chosen per system. Most customers use more than one.
Managed connectors
For systems we integrate with regularly, a connector handles mapping, incremental sync and error handling. Configured during onboarding with your IT team or partner.
Scheduled file exchange
For systems that prefer to publish files, Wholara ingests CSV or XML extracts on a schedule, with validation, rejection reports and a re-run option when a file is malformed.
API and webhooks
REST endpoints and event webhooks for real-time flows. Every record carries a source key and revision so retries are idempotent and duplicates are impossible.
Historical data matters more than perfect data. Twelve months of order and receipt history is what makes demand patterns and lead times real rather than assumed. If the history is messy, we clean what is usable and say plainly what is not.
The control model.
Automation without governance is just a faster way to make a mistake. This is how authority is allocated.
Suggest
The agent observes, calculates and presents. Nothing is changed. Suitable for workflows where you want to see what the system would have done before trusting it with anything.
Prepare
The agent drafts the full transaction — the purchase order, the transfer, the price correction — for a person to review, adjust and release. One click to approve, and the change is recorded against their name.
Commit within limits
The agent acts on its own inside thresholds you define by value, category, supplier or customer. Anything outside those limits reverts to preparation and waits.
Thresholds are operational, not technical
A typical starting configuration: the agent may commit to purchase orders under $5,000 for stocked A and B class items from approved suppliers at agreed costs. Anything above that, any new item, any non-approved supplier and any cost change goes to a named buyer. Order holds and transfers between locations can be granted wider authority because they are reversible within the day.
- Authority is granted per workflow, not globally.
- Thresholds can differ by category, location and role.
- Any action can be reverted by a human, and the reversal is recorded.
- Every automated action names the workflow and rules version that produced it.
Audit entry example
The rules you set, in plain language.
Configuration is a series of decisions rather than a development project. These are the decisions, grouped the way they come up in a workshop.
Service and replenishment
- Service-level target by category, branch and customer tier
- Reorder policy per item class, including items that should never be auto-ordered
- Demand windows and how promotional or project demand is treated
- Whether transfers are considered before purchases, and the freight threshold
- Seasonal profiles and shut-down periods
Commercial
- Order of precedence between contract, matrix, list and manual price
- Margin floor by category, account or both, and who may override it
- Freight, surcharge and small-order rules
- Rounding, minimum order values and price validity periods
- Rebate accrual treatment for suppliers and customers
Fulfillment
- Allocation priority when stock cannot cover every order
- Substitution eligibility by category, customer and margin impact
- Partial and split delivery policy, and when to ask the customer first
- Delivery cut-offs by location, route and carrier
- Which notifications send automatically and which need review
Governance
- Approval thresholds by workflow, value and role
- Which automations are active, paused or in observe-only mode
- Retention periods for operational records and audit entries
- Access rules for pricing, cost and customer data by role
- Escalation paths when an approval is not actioned
Changing a rule later
Rules are versioned. When you change a service target or a margin floor, the change takes effect from the date you choose, and the previous version remains attached to every decision made under it. That means a decision from March can still be explained in June.
What implementation actually involves.
Indicative sequencing for a first workflow in a single-country distributor with an existing ERP. Real timelines depend on data quality and integration surface.
| Phase | Main activity | Your team's involvement | Output |
|---|---|---|---|
| Discovery | Process mapping, baseline capture, workflow selection | Operations lead, purchasing lead, IT contact | Agreed scope and success measures |
| Data | Extract, map, load and reconcile master and history data | IT or ERP partner, plus a data owner per domain | Reconciled item, customer and supplier records |
| Configuration | Rules, thresholds, pricing precedence, notifications | Buyers, commercial lead, warehouse supervisor | Configured workflows in sandbox |
| Integration | Connect order intake, ERP write-back, accounting and carriers | IT or partner; testing with operations | Verified data flows and error handling |
| Parallel run | Run the workflow alongside the current process and compare | The people who will use it daily | Documented differences and adjustments |
| Training | Role-based sessions on live configuration and your own data | All users of the workflow | Trained team and written procedures |
| Go-live | Cut over, monitor closely, hold a fallback for the first weeks | Operations lead as owner | Workflow in production |
| Review | Compare against baseline and decide the next workflow | Management sponsor | Measured outcome and next-phase plan |
Phases overlap in practice. The sequence is a dependency order rather than a calendar.
Partly. Demand patterns and lead-time variation use statistical methods, because that is genuinely better than a fixed reorder point. But the commercial decisions — service targets, margin floors, approval limits, substitution policy — are rules you set and can inspect. Nothing about your business policy is inferred by a model.
Every recommendation can be traced back to its inputs and the rules version in force at the time.
Wholara keeps working on the state it has and queues outbound changes. Sync runs are logged with record counts, conflicts and failures, and failed records can be replayed. Nothing is written twice: each outbound record carries a source key and revision, so a retry after a timeout does not create a duplicate order or a double-posted invoice.
Where a connection is genuinely lost, the affected workflows pause rather than acting on stale data, and the pause is visible.
Yes, and it is a common way to begin. In observe-only mode the agent produces recommendations and a comparison against what your team actually did. After a few weeks you have a documented record of where it agreed and where it did not, which is a far better basis for trust than a demo.
Order validation and pricing checks are useful immediately, because they only need current records. Replenishment and forecasting improve as history accumulates: usable from the first weeks, noticeably better after a full seasonal cycle. Nothing here is a black box that needs months of training before it says anything.
Yes. Service targets, stocking policy, delivery cut-offs and approval limits can be set globally, by location, or by category within a location. Where a branch has an exception, it is explicitly configured rather than applied by habit — and it appears in the audit trail as an exception.
You do. Operational rules — targets, thresholds, floors, substitution policy — are designed to be edited by your operations and commercial leads without a change request. Configuration changes are versioned and attributed, so self-service does not mean unaccountable.
See the loop close on one of your own exceptions.
Bring a stockout, a short pick or a pricing dispute from last month. We will trace it through the platform.
wholara.net