Flour Mill Management Software: Bin Blending, Grist Economics, and Tracing a Bulk Load Back in an Hour

The call that defines this business

A large bakery customer phones at ten in the morning. Their dough is not behaving, absorption is off, the line is running badly, and they want to know what changed in the flour. You have a bulk load that went out three days ago, a silo it was drawn from, a mill that has been running continuously since, and a bin blend that changed twice in that period as wheat was drawn down and topped up. You have maybe four hours before this becomes a commercial problem rather than a technical one.

Whether you can answer that call is entirely determined by decisions you made about data years earlier. Bulk is the hard case. A bagged product carries a code on the bag. A truck of flour carries a delivery note and a hope. The blend it came from was not a batch in any tidy sense, it was a continuous flow drawn from bins that were themselves being filled while they were being drawn.

Most mills operate on a stack of an automation and process control system on the mill floor, a grain accounting or elevator package on the receiving side, laboratory results in a spreadsheet or a small lab system, customer specifications in email and PDF, and an accounting package that sees the money at the end. The technical operation is well instrumented. The commercial operation, which is where the margin actually lives, is not.

Problem one: a bin is not a lot, and pretending it is will cost you

Wheat arrives by truck and rail, is graded on protein, test weight, moisture, and falling number, and is binned by quality band rather than by delivery. That means a bin holds a continuously changing mixture of many deliveries and many growers. Draw from it and you get a weighted average of whatever is currently in there, with the most recently added material influencing the top of the bin more than the bottom depending on flow behaviour.

Most mills approximate this by recording bin contents as a running quality average updated when a delivery is added. That is a reasonable model and it is good enough for most decisions, but only if the arithmetic is done continuously rather than by someone updating a spreadsheet when they remember. A build maintains a live bin position: quantity, weighted quality, and the contributing deliveries with their proportions, updated on every intake and every draw from the mill scale. That gives you a defensible statement of what was in the grist at any point in time, which is the foundation of the whole traceability answer.

The corollary is that your intake testing has to feed the model automatically. Where you have near infrared analysis on receiving, the results should land in the bin record without anyone typing them. Where testing is manual, the entry point needs to be at the scale, not in the lab office an hour later.

Problem two: the grist is an economic decision made on instinct

Choosing the blend that meets a customer specification is a constrained optimisation with a cost function. You have bins with known protein, quality characteristics, and inventory cost. You have a specification with limits. You have delivery commitments. There is usually a cheapest blend that satisfies the constraints, and it is rarely the blend the miller would have chosen by habit, because the miller optimises for confidence and the market optimises for margin.

Nearly every mill does this by experience, which is genuinely valuable and also expensive. Wheat prices move, bin inventories change daily, and the blend that was optimal in September is not optimal in November. A build makes the blend recommendation explicit: given current bin positions, current wheat costs, and this specification, here is the least cost grist that satisfies every constraint, here is the one the miller usually runs, and here is the difference per tonne. Then the miller decides, informed, and can override with a recorded reason.

This is a genuinely solvable optimisation problem with standard techniques, not an artificial intelligence project. The hard part is not the maths, it is having accurate live bin data to feed it, which is why problem one comes first. Mills that try to buy the optimiser before fixing the bin model end up with an elegant tool producing confident nonsense.

Problem three: customer specifications live in email

Every meaningful customer has a specification: protein range, ash, moisture, falling number, colour, absorption, and whatever rheology parameters they care about, plus enrichment and any additive requirements. Those specifications live as PDFs attached to emails, printed and pinned in the lab, and updated occasionally in a way that does not reliably reach everyone.

The result is predictable. Production runs against the version the miller has, quality tests against the version the lab has, and the certificate of analysis you send is checked against neither. Then a customer rejects a load for being outside a limit that was revised four months ago.

A build makes the specification a controlled record with versions and effective dates, links it to the customer and product, drives the target parameters for the grist, and generates the certificate of analysis from actual test results checked against the correct version. When a specification changes, everyone sees the same one. This is a small feature that removes an entire category of expensive argument.

Problem four: mill balance and extraction are your real profit signal

Extraction is the ratio that decides whether the mill makes money. Wheat in, flour out by grade, plus bran, shorts, and germ, with moisture added in conditioning and lost in the process. Every mill computes this, and most compute it monthly against a total, which averages away everything useful.

Balancing by run, by grist, and by shift is far more informative because it exposes the variation. A grist that extracts a point lower than expected is telling you something about the wheat, the conditioning, or the roll settings, and knowing it within a shift is actionable. Knowing it at month end is history. This needs mill scale data, which usually means pulling from the automation system rather than from paper, and it needs an agreed treatment of moisture so the balance is honest rather than flattering.

What Buhler Mercury MES actually leaves out

Buhler Mercury MES is a capable manufacturing execution system for milling and it is built by people who know mills. Where it is strong is the plant floor: production data, equipment, process visibility, and the operational layer sitting above automation. If your problem is production execution and you run Buhler equipment, it is doing what it was designed to do.

What it does not cover is the commercial layer that surrounds the mill. Grain intake with grower or supplier settlement, bin level quality accounting fed by intake testing, least cost grist optimisation against customer specifications with wheat cost as an input, customer specification version control and certificate generation, bulk loadout traceability tied to a customer delivery, and margin analysis by customer and by grade. Mills running Mercury commonly keep it and build the commercial layer around it, integrating for production and scale data rather than replacing what already works. That is usually the correct and cheapest architecture, and any developer who proposes ripping out a working MES should be questioned hard.

What a build must include

The spine: intake with quality results, bin positions with weighted quality and contributing deliveries, grist definitions with actual draw quantities from mill scales, production runs by grade, silo positions for finished flour, and loadout events tied to customer orders. That chain is what answers the ten in the morning phone call, in minutes, with evidence.

Around it: customer specification management with versions, certificate of analysis generation from real results, least cost blend recommendation, extraction and mill balance reporting by run, preventive controls records under your food safety plan including sifter and magnet checks, enrichment and additive dosing records, rework handling, and bulk plus bagged inventory with allergen and gluten free segregation where you run those lines.

Integration priorities are the automation system for production and scale data, intake analysers, the lab, and accounting. Where grain purchasing involves contracts and hedging, that is its own module and it should be scoped separately rather than smuggled into release one.

Cost, timeline, and what moves the number

A first release covering intake with quality, live bin positions, grist definition with actual draws, and bulk loadout traceability end to end runs $75,000 to $150,000 over 12 to 16 weeks. A full platform adding specification management and certificates, least cost blending, extraction reporting, preventive controls, and customer margin analysis runs $180,000 to $450,000 phased across 6 to 12 months.

What increases the cost: multiple mills with wheat transfers between them, rail as well as truck intake and loadout because rail brings its own logistics model, integration with an older automation system that has no clean data path, and grain contract and hedge accounting. What reduces it: one mill, truck only, and a first release scoped strictly at traceability before touching optimisation.

When not to build

Do not build if you run a small mill on one or two straight grades into bagged product with a stable wheat supply. Your traceability chain is short, your blending decisions are few, and a spreadsheet alongside your automation system genuinely covers it. Do not build if your customer base is a handful of accounts on the same specification, because the specification management and optimisation features have nothing to work on.

Build when you are milling to fifteen or more customer specifications, when your bins are segregated by quality and blended deliberately, when a bulk complaint currently takes a day to investigate, or when the difference between the habitual grist and the least cost grist is worth more per year than the software. On a mill of any size, that last calculation is usually not close.

How to choose a developer for mill software

Ask them to explain how they will model a bin. If they treat it as a container holding a lot, they have not understood the problem and your traceability will be fiction. The answer you want describes a running weighted position with contributing deliveries and proportions, updated on both intake and draw.

Ask what data they can get out of your automation system, naming it, and whether they have read from it before. Then ask what they would do if the answer is nothing clean, because there is always a mill where the answer is nothing clean.

Ask whether they intend to replace or integrate with your existing MES. Integrate should be the default answer, and a developer who reaches for replacement is either inexperienced or selling hours. Finally, settle code ownership in writing before kickoff: repository, cloud accounts, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in a mill where the software backs your customer certificates, you cannot afford to be locked out of your own records.