Is d-dispensing recipe management software?

No – deliberately. It is recipe weighing software: it executes the recipes and BOMs your ERP manages. Recipes are created, versioned and approved in the ERP.

Is this recipe software for food or kitchens?

No. It is for industrial batch manufacturing – pharmaceuticals, cosmetics, detergents and chemicals – where raw materials are weighed against a bill of materials.

What if our ERP doesn't carry tolerances on BOMs?

Tolerance limits are configured on the site server; targets come from the BOM.

What happens if a recipe changes during a running order?

The order carries the version it was created with. Change control happens in the ERP; d-dispensing executes the order's BOM.

Can the order of positions be prescribed?

The BOM shows all positions with their status; the operator chooses, the software checks the material.

Does it work with our ERP?

myfactory (with xstorage) and weclapp are implemented; the integration layer is designed for more.

DE Try the live terminal Schedule a demo

Recipe weighing software

Recipe weighing software: where recipe management ends – and recipe execution at the scale begins

In manufacturing, "recipe software" means one of two things: formulation and recipe management software that creates, versions and approves recipes – or recipe weighing software that turns an approved recipe into a batch at the scale. Looking for both in one tool is the most common planning mistake. This page separates the two jobs, describes the requirements of each, and shows where d-dispensing stands.

Part 1 · Recipe management and recipe execution

Two jobs, two systems

	Recipe management	Recipe execution (dispensing)
What	Create, version, approve and change recipes and BOMs	Turn an approved BOM into a batch at the bench, position by position
Where	ERP, PLM, possibly LIMS/QMS	Dispensing system at the scale
Who	Development, QA, production planning	Operators, shift leads
Core requirement	Change control, version status, approval	Right material, right quantity, right batch, evidence
Typical failure	Recipe maintained in two places ("two truths")	Mix-up, tolerance breach, missing evidence

Rule of thumb: master data ownership belongs in exactly one system – the ERP. Weighing software that manages its own recipes inevitably creates drift between what is approved and what is weighed.

What formulation and recipe management software must deliver (tender summary)

Versioning with validity periods; an approval workflow (two-person); change control with reason and history (EU GMP Chapter 4, Annex 11); linkage from batch to recipe version; material master maintenance including hazard data (GHS) and container logic. Cosmetics: ISO 22716 requires documented manufacturing instructions and traceability; detergents add the Detergents Regulation and CLP labelling of raw materials. These are jobs for the ERP or PLM – not for the scale.

What recipe execution at the scale must deliver

01Take the approved version of the BOM from the ERP – no retyping, no copying.
02Show each position with target, quantity dispensed so far and remaining – per batch for multi-batch orders.
03Check the container before weighing.
04Enforce tolerances, including when dosing in partial quantities (cumulative).
05Produce the evidence: operator, time, scale, container, actual/target, deviations, charging.
06Book consumption back to the ERP so that stock and batch record agree.

Recipes in pharma, cosmetics and detergents – what differs

Industry	Typical recipe	What execution must watch
Pharma	API blend: API, cellulose, lactose, magnesium stearate	Tight tolerance on the API, GMP batch record, audit trail
Cosmetics	Emulsion: oils, emulsifiers, preservatives, fragrance, colourant	Many tiny quantities, mix-up risk with similar raw materials, ISO 22716
Detergents	Surfactants, builders, enzymes, fragrance, acid/alkali	Hazardous substances at the bench, large batches in parts, multi-batch orders

The regulatory framework for each industry is set out under weighing solutions by industry.

Part 2 · Where d-dispensing stands

Where d-dispensing stands

d-dispensing is recipe execution, deliberately not recipe management. It takes the production order with its BOM from the ERP (myfactory or weclapp today), guides every position through dispensing and books consumption back. Recipes are never created or changed in d-dispensing – so there is only one truth. In the terms of the weighing software market, it is a dispensing system.

Against the six execution requirements:

Approved version: the BOM arrives with the production order from the ERP; no local copy.
Position, target, remaining, batch: BOM view with progress per position and per batch for multi-batch orders.
Container check: container scan against the position before weighing; refusal logged.
Tolerances: cumulative count; at most 104 % of remaining per weighing, closure between 98 and 102 %, warnings at 50 % and 95 % – checked server-side.
Evidence: hash-chained audit trail with operator, timestamp, container, actual/target and refusals; label with record ID; proof of charging in the same record.
Booking back: stock movement in ERP and WMS in one transaction.

GHS at the bench: pictograms and signal word from the material master next to the live weight. Scales: Mettler Toledo, Sartorius, RHEWA and more; further manufacturers are easy to add.

Status

Running daily at several manufacturers since 2015, several million production orders processed. Every release goes through hundreds of automated tests before it ships.

FAQ

Frequently asked questions

→ All questions in the FAQ

Next step

Where to read next

Planning: Try the live terminal – run a four-position sample recipe.
QA: Dispensing under GMP – requirements and checklist.
Owners / purchasing: A demo on your own recipes.

Schedule a demo Try the live terminal →