Feed Mill Management Software: Why the Batch Record Has to Prove What Ran Before It

Why a feed mill is a pharmaceutical plant that also handles bulk grain

It is two in the morning. The mill is running a medicated broiler ration with a coccidiostat in it. The next order on the board is a layer ration. Between those two batches a flush is required, because residue of the drug carried into feed for a species that is not approved to receive it is not a quality problem, it is a regulatory and animal safety event. The operator can see a truck waiting in the yard. The flush costs him twenty minutes and a batch of feed he now has to dispose of or rework into an approved product.

Most of the time the flush runs. The question that matters is not whether your people are conscientious, it is whether you can prove what happened at two in the morning six months from now when someone asks. Under the current good manufacturing practice rules for medicated feeds in 21 CFR Part 225 the record is the control. If it is not written down in a way that ties the sequence, the flush, and the actual weigh-ups together, the fact that everyone did the right thing is not much use to you.

What makes this hard is that the mill is three businesses at once: a chemical batching operation running automated hardware to tight tolerances, a commodity buying operation where formulas move every time ingredient prices do, and a logistics operation delivering bulk product into specific bins at specific farms. In most mills those three run on a batching control system, a formulation package and a set of spreadsheets.

Problem 1: the formula exists in three places and only one of them is right

Least cost formulation reruns when soybean meal moves. The nutritionist approves a new formula on Tuesday. That formula now has to reach the batching system so the mill makes it, reach the label so what is printed matches what is in the bag, and reach the batch record so the record reflects the correct targets. Those are three systems and in most mills at least one of the transfers is manual.

The failure mode is specific: the mill batches the previous version for two days because the download was rejected and nobody watched for the acknowledgement. Everything downstream, including the medicated inclusion rate, is then wrong until a routine assay comes back.

What a custom build does: the software owns the formula master and the control system executes it, and the handover between them is verified rather than assumed. A formula version is released, downloaded, and read back from the controller, and the batch is blocked until the read-back matches. Every batch record stores the formula version it ran against, so the question of which formula was in force on the eleventh of March has a one line answer. Labels generate from the same version, which removes the most common labelling discrepancy we see.

Problem 2: sequencing and flushing is a rule set, not an operator's habit

The rules are knowable. This drug may not be followed directly by feed for that species. This inclusion requires a flush of a specific quantity. This flush material may be reworked into a specific set of products and not into others. Monensin in a horse ration is the textbook example of why this matters, and every mill running multiple species carries its own version of that list.

Batching control systems execute what they are told to execute. Order sequence comes from a planner applying the rules from knowledge, which works until the planner is on leave or a rush order jumps the queue at eleven at night.

What a custom build does: hold the sequencing rules as data and enforce them at scheduling and again at batch release. A prohibited sequence cannot be scheduled without inserting the required flush, and the flush becomes a real work item with a lot number, a quantity, and a disposition record saying where it went. Overrides are possible, because operations always needs an escape hatch, and each override captures who, why, and a supervisor authorisation. That single design decision, allowing the override but recording it, is the difference between a system people use and a system people bypass.

Problem 3: the batch record has to come from the equipment, not from a person

A medicated feed batch record needs the actual quantity of each ingredient weighed, not the target. Scales drift. Bins bridge. An ingredient that reads as delivered but hung up in the bin is a real event, and the difference between target and actual is the evidence that it either did or did not happen.

The controller knows all of this. The question is whether it is captured, retained and made searchable, or whether it prints to a report that gets filed. What a custom build does: subscribe to batch completion data from the control system and store actuals per ingredient per batch with tolerance evaluation, operator, time, and the formula version. Out of tolerance batches raise a deviation with a disposition workflow rather than a note. Retention is designed for the horizon your inspections require, and the record is queryable by lot, drug, customer and date, which is what makes a trace take minutes.

This is also the honest place for machine learning in a mill, and it is unglamorous. Systematic drift in the difference between target and actual on one ingredient, over dozens of batches, is a load cell or a gate problem showing itself weeks before it produces a rejected batch. That pattern is invisible to a person reading one batch report and obvious to a model watching the series.

Problem 4: what the incumbents do well, and where the mill outgrows them

Credit where it is due. Adifo BESTMIX is a serious least cost formulation tool, and if your problem is multi-blend nutritional optimisation you should use something like it rather than rebuild that mathematics. Format Solutions covers formulation together with mill management and is a mature product with real depth in the business processes of a commercial mill. Repete owns the automation layer and is genuinely good at batching control, which is precisely the part you should not attempt to replace.

Where mills outgrow the set is the joins between them, and the parts specific to your operation. Bin inventory across your particular bin layout with your particular ingredients and moisture handling. Bulk delivery with compartment to bin assignment for your farms. The integrator relationship, where the mill serves company owned production and the feed order originates from a placement schedule rather than from a customer purchase order. And multi-mill operations where the same formula runs at three sites with different bin configurations and different ingredient suppliers.

Our position is that you should keep the automation vendor and keep a proper formulation tool, and build the mill management layer that ties order, formula version, batch execution, inventory, record and delivery into one chain. Attempting to replace batching control is a category error and we would talk a client out of it.

Problem 5: shrink is discovered at year end, when it is only bad news

Ingredient comes in on a truck scale. It goes into a bin. Batches consume it in theory. The difference between what you bought and what you can account for is shrink, and in most mills it is calculated at inventory count and then argued about. By that point you cannot tell whether it was a scale calibration issue, a receiving error, a formula variance, or product going out the door on a delivery that was never billed correctly.

What a custom build does: reconcile continuously. Receipts, batch consumption at actual weights, transfers, and physical counts all post against the same bin ledger, so variance surfaces per ingredient per week while the cause is still findable. Moisture handling is part of this and is fiddly, because a wet corn receipt and a dry one are not the same quantity of nutrition.

Problem 6: the last hundred metres, from truck compartment to farm bin

A bulk truck leaves with four compartments carrying three products. At the farm the driver has to put the right product in the right bin. A medicated ration into the wrong bin is the incident everyone in this industry can describe. Paper delivery tickets and a driver's familiarity with the route are the current control.

What a custom build does: assign compartments to bins before the truck leaves, give the driver a mobile confirmation at the bin including a scan or a code on the bin itself, and record the delivery against the bin ledger so the farm's feed inventory is real rather than estimated. Build it offline first, because farm yards are exactly where connectivity fails.

What this costs and how long it takes

A first release with the formula master and verified download, sequencing and flush enforcement, automatic batch record capture with tolerance handling, and bin inventory runs $70,000 to $150,000 in 12 to 18 weeks. Adding formulation integration, veterinary feed directive tracking with expiry and authorised species, bulk delivery with compartment assignment and a driver app, shrink reconciliation, multi-mill support and customer or integrator portals runs $180,000 to $450,000 over 8 to 14 months.

Cost drivers specific to feed mills: the control system integration, because each automation vendor and each generation of their hardware exposes data differently and a mill with two eras of equipment is two integrations. The number of mills, since bin configurations differ and shared formulas across different bin layouts is real modelling work. Scale and load-out hardware. Offline mobile for drivers. And whether your medicated products require licensed facility handling, which raises the documentation bar. What keeps cost down: one mill, the medicated products only, and the formula to batch record chain proven before anything else is added.

Build versus buy, honestly

Buy if you run a single mill making a handful of straight, unmedicated rations for local customers. Your batching system plus a formulation package plus disciplined records is enough and a custom build would be an expensive way to make the same feed. Buy Format Solutions if your operation looks broadly like the commercial mill its processes were designed around and you are willing to work its way.

Build when two or more of these are true. You make medicated feeds for more than one species, so sequencing is a real risk rather than a theoretical one. You run more than one mill and want one formula master. You serve an integrator model where orders come from placement schedules rather than purchase orders. Your shrink is calculated once a year and argued about. Or your delivery process relies on drivers knowing which bin is which.

How to choose a developer for feed mill software

Ask them how a formula gets to the controller and how they know it arrived. If the answer does not include a read-back and a block on batching until it matches, they have not thought about the failure that costs the most.

Ask what happens if communications drop mid-batch. You want to hear about buffering, reconciliation on reconnect, and how a partially recorded batch is resolved, not a shrug.

Ask whether they intend to replace your batching control. If they say yes, that is the wrong answer and it should end the conversation. The right shape is a management layer above the automation, not a rewrite of it.

Ask how the medicated feed record is retained and searched, and for how long. Then ask them to show you the trace query: give it a drug lot, get every batch, every customer and every farm bin it touched.

Ask who owns the code, the repository and the hosting accounts, and get it in the contract before kickoff. At Digital Heroes the client owns it from the first commit. Your batch records are regulatory evidence with a long life, and neither they nor the system that produces them should sit in a vendor's account.