Every rupee, refereed.
Buy it — or move it
One demand document can release to a supplier PO or to a transfer from another warehouse, fully or line-selectively, with pending quantities tracked.
Quality gates the stock
Receive → inspect → release; items flagged for inspection wait in their own bucket, and lots are born at receipt for full traceability.
The paper trail closes itself
Vendor bills with GL and inventory posting, purchase returns with their own ledger type, debit notes with settlement adjustments, and landed cost captured and posted.
Three ways the system reorders before you notice.
Min-level, replenish-from-demand, and a forecasting engine that nets stock on hand, in-transit, open POs, requisitions and sale orders — with scheduled template auto-orders.
Three documents. One truth.
Ordering that proposes itself.
Three replenishment engines — Minimum Stock Level, Replenish, and min/max Forecasting — plus template orders generate purchase suggestions on a schedule, or on demand. Runs can be scoped by ABC class and by fast, slow or non-moving status, so the exercise matches how you actually buy.
Suggestions net the full pipeline: stock on hand, in-transit shipments, pending purchase orders, open requisitions and unfulfilled sales orders. And every suggested line carries its own arithmetic — projected quantity, availability, each pipeline component, lead time and average consumption are written onto the line, so a buyer checks the number instead of trusting it.
The rules-based engines project from item attributes — average consumption, lead time and ABC/FSN class — so every suggested line stays inspectable arithmetic. Statistical and machine-learning demand forecasting run alongside them for items whose demand is worth modelling.
The capabilities, stated plainly.
Every row ships today and traces to a capability described on this page.
| Capability | xMatix Procurement |
|---|---|
| Requisitions met by purchase or transfer | Native |
| Purchase orders with policy approvals | Native |
| Purchase schemes on the order | Native |
| Goods receipt with quality inspection | Native |
| Three-way match before payment | Native |
| Budget commitment at order time | Native |
| Vendor bills with TDS tagging | Native |
| Debit notes and returns | Native |
| Landed cost onto received stock | Native |
| Three replenishment engines | Native |
| PO-quantity anomaly nudges | Integrated — Sense |
| Rules-based auto-replenishment | Native |
| Scheduled suggestion runs | Native |
| Consumption-based forecasting | Native |
| Pipeline netting (in-transit, open POs, requisitions, open SOs) | Native |
| Class-scoped runs (ABC / FSN) | Configurable |
| Per-line explainability | Native |
| Three-way match | Native |
Everything in Procurement.
The questions evaluators ask.
Is stock shared across sales, service and warehouse, or copied?
Shared — there is one stock ledger on one data model. The order that allocates stock, the service job that picks a part and the warehouse count that adjusts a bin all move the same record, so there is no sync job to run and no morning where two systems disagree about what is on the shelf. The ledger itself is immutable: corrections are new entries, never edits, so every figure carries its own history.
Does it support multiple warehouses and locations?
Yes — stock tracks across every location, down to zone, aisle, rack and bin, so each item has an exact, findable address. Vehicles count too: vans are stock locations in their own right, and what is on the truck shows on the books all day. Goods in transit between branches stay visible as well — nothing goes dark mid-transfer.
How are transfers and adjustments controlled?
Deliberately. Transfers move as two recorded steps — goods leave one branch and arrive at another — so the road in between is on the books and stock cannot be lost in the middle. Adjustments are typed: damage, shortage or excess, each carrying its reason and its approval. Because the ledger is immutable and no location may go negative, the audit trail explains itself.
Does procurement run a three-way match?
Yes — the bill, the purchase order and the goods receipt must agree before payment goes out, so the classic overbilling simply cannot clear. Receiving itself is checked: goods arrive against the order with quality inspection built in, and rejects turn around at the gate rather than after payment. The received-not-billed gap clears systematically instead of being chased at month-end. Explore xMatix Procurement.
Does warehouse support pick, pack and dispatch?
Yes — picking is a stock state, so the moment goods are picked the system knows, and there is no phantom availability between floor and dock. Partial picks, partial deliveries and partial invoices are the normal case. Delivery orders and documents generate from the fulfilment itself, and shipments carry their contents, carrier and status to the door. Explore xMatix Warehouse Management.
Are serial and batch numbers tracked?
Yes — batch, serial and expiry lots are native. Every unit knows where it came from and when it expires, which turns a recall from a crisis into a query. Barcode scanning covers receipt, pick and count, so the tracking survives contact with a busy floor: fewer keystrokes, fewer wrong SKUs, and a trace you can actually rely on.
How does xMatix decide what to reorder?
Through three replenishment engines — Minimum Stock Level, Replenish, and min/max Forecasting — plus template orders for repeat buys. A scheduled job generates dated suggestion runs, and a run can also be triggered manually, scoped if you choose by ABC class or by fast, slow or non-moving status. Every engine writes its inputs onto each suggested line — projected quantity, availability, lead time, average consumption — so the buyer can see exactly why a quantity was proposed before turning it into a purchase order.
Does it account for stock already on order?
Yes — suggestions net the full pipeline: stock on hand, in-transit shipments, pending purchase orders, open requisitions and unfulfilled sales orders. An item that looks short on the shelf but is already covered by an inbound shipment will not be re-proposed. The same netting powers the purchase-order quantity nudge, which flags a PO line the pipeline already covers — or one that still leaves the item short.
Can it tell us what not to order?
Yes. The purchase-order quantity nudge checks a PO line against the reorder point after netting on-hand stock, in-transit shipments, pending purchase orders, requisitions and open sales orders — and flags a line the pipeline already covers, with the evidence attached. The finding is computed deterministically; Sense explains it and carries the one-click action under the buyer’s own permissions, written to the audit trail.
Does it forecast demand?
Yes, in two forms, and they answer different needs. Statistical forecasting and machine-learning forecasting model demand from historical sales, inventory movement patterns, seasonal variation and other influencing parameters — for items where demand is worth predicting rather than assuming. Alongside them, the rules-based Forecasting engine projects from average consumption, lead time, min/max bounds and the current pipeline, and every number it proposes is inspectable: the inputs sit on the suggested line itself, so a buyer can verify the arithmetic.
