Livestock Genetics Inventory Software Problems: The 5 That Close Export Markets, and How to Avoid Them

Why does the inventory model get built around the sire instead of the lot?

Because that is how the business talks. Orders come in for a sire, price lists are published by sire, and the spreadsheet everyone has used for years is keyed by sire code with a total unit count. So the first data model mirrors the conversation, and it is wrong in a way that only becomes expensive later.

The real inventory object is a lot: a specific bull or boar, a specific collection date, a specific processing batch, with a health and eligibility profile attached. Two lots of the same sire are not interchangeable if they were collected under different testing conditions, and a system that pools them into one number can never answer whether the three hundred units you just promised a South American customer are actually shippable.

Location has the same problem. A warehouse code is not enough. Technicians work from a canister map, so the model needs tank, canister and goblet position, and every physical movement has to be a recorded event rather than an adjustment to a count. A canister moved between tanks last winter with no record is how a report says eleven hundred units and a pick finds five hundred.

The correction is cheap at the start and painful later. Make the lot and the position first class, treat counts as derived, and require any developer to model a straw on a whiteboard before you sign anything. If they draw a product with a quantity, they are rebuilding your spreadsheet with better fonts.

What goes wrong when eligibility is treated as a data field?

It gets attached to the bull, and it belongs to the lot and the destination together.

Whether a specific lot may ship to a specific country depends on the collection centre's approval for that country, the testing protocol applied around the collection window, quarantine and residency history, sometimes genetic status for particular conditions, and the certificate the destination will accept. In the United States, bovine semen for export is generally handled through centres operating under the Certified Semen Services framework, with importing countries layering their own requirements on top. Those requirements change, and they change in both directions at different times.

Two failure modes follow. The first is the warning, which gets clicked through. The second is a rules table with no effective dates, so a change made this year silently rewrites the story of why a shipment two years ago was correct at the time. When a question arrives about that shipment, your own system contradicts you.

Build it as a hard allocation block computed per lot per destination, with a named override requiring a reason and an approver retained permanently on the record. Store country requirements as versioned data with effective dates so historical decisions remain explicable. And accept that each destination is analysis work before it is code, because someone has to read the requirement, decide which facts about a lot it depends on and encode it.

Why does consignment stock stay wrong after the system goes live?

Because the software was designed for the office and the stock is in a truck.

Field technicians and distributors hold a meaningful share of your inventory, sell from it and report back. If the only way to record a use is a web page that needs a signal, a technician standing at a farm gate with no coverage will write it on a pad, and the pad becomes the record. Your reconciliation then remains monthly, quarterly or triggered by somebody noticing a discrepancy, exactly as it was before you spent the money.

Offline capability is therefore not a feature to add in phase two. It is a design decision made at the start, with local capture, sensible conflict resolution and an interface that never stalls waiting for a network. Get it wrong and the field simply does not adopt, which means the most valuable part of the build produces nothing.

The second gap is variance handling. Systems that silently correct a count destroy the only signal you have. Require a reason on every variance, from a controlled list covering broken straws, unrecorded transfers, count errors and tank incidents, and let a year of those codes tell you which parts of the network need attention. Settlement should then read from the same usage events, so technician commission, distributor tiers and consignment revenue recognition stop being a month end typing exercise.

What happens when traceability and shipping documentation are scoped thinly?

You find out when a customer raises a quality question months later, and the honest answer is that you cannot bound the exposure.

The chain you need runs backwards from any straw to the collection date and centre, the processing batch, the extender lot, the freezing run and the storage history, and forwards to every tank it reached and every recorded use. Build that as fields on an inventory row and it collapses, because one collection fans out into thousands of straws across hundreds of tanks over several years. Only an append only event chain keeps forward and backward queries honest at that spread, and retrofitting it means reconstructing history you no longer hold.

Documentation is the other thin spot. Orders leave in nitrogen dry shippers with a limited hold time, international shipments carry health certificates and permits, and a discrepancy between the certificate and the physical contents at a border is the classic reason a consignment is refused. If the packing list is typed rather than generated from the actual allocated lots, that discrepancy is a matter of time.

Generate the packing list from the allocation, feed the certificate data from the same source, hold the export document pack against the shipment permanently, and track dry shippers as returnable assets with charge rules, because they are worth real money and they disappear constantly.

Should you build custom or stay on spreadsheets a while longer?

Staying is a legitimate answer and we will say so plainly. One tank room, domestic sales only, one person doing all the picking: a disciplined technician and a well kept spreadsheet will serve you for years, and a custom build is money that would do more elsewhere in the business.

What does not work is the middle path most operations try first. A general enterprise resource planning (ERP) or warehouse system handles lots and locations competently and has no concept of eligibility per destination or of stock sitting in a technician's truck, so the eligibility matrix goes back into a spreadsheet, which is where the actual risk lives. A herd management package understands animals and not warehouse operations, and produces the same split. You end up paying for software and keeping the dangerous part manual.

Build when field tanks outnumber house tanks, when you export to several countries with divergent rules, when consignment reconciliation has produced a write off you did not expect, or when your compliance manager is the single point of failure for every export decision the company makes. That last one is not a software problem on paper and it is the most expensive item on the list.

How do hidden costs get into a genetics inventory quote?

Five places. The first is the baseline count, and it is the biggest. Establishing what you physically hold means opening tanks, counting canisters and reconciling against the spreadsheet, and it runs alongside the software project rather than after it. Field tanks make it worse because you are asking other people to do it. This is a real programme with real labour and it is regularly left out of the plan entirely.

The second is destination count. Each export market is a requirement set someone must read, interpret and encode, and the tenth country is not cheaper than the third.

The third is embryos. Treat them as a second model rather than a variant, because donor and sire, grade and stage, recipient records and their own destination rules roughly double the domain modelling in a first release.

The fourth is offline mobile. It is not optional if technicians work rural routes and it is genuine engineering, not a responsive layout.

The fifth is multiple collection centres, each with its own approvals, its own processing conventions and its own local practices, which is closer to several implementations than one.

What separates a genetics build that works from one that gets bypassed?

Three things. The first is that the block holds under pressure. Any control that can be dismissed with a click during a busy shipping week is not a control. A hard refusal with a named override, a reason and an approver, retained permanently on the record, is the only design that survives the week before a large consignment goes out, and it is also the record that answers questions years later.

The second is that the field adopts it. Technicians are the source of your most valuable data and the least captive audience you have. If recording a use takes longer than writing it on a pad, or if the app stalls at a farm gate with no signal, they will keep the pad and your consignment position will stay fictional. Test with your least enthusiastic technician on their worst route before you accept delivery.

The third is that you own what accumulates. Lot genealogy and usage history compound in value every year and sit underneath your export approvals, so the repository, the database and the cloud accounts need to be yours from the first commit, agreed in writing before kickoff. A developer hedging on that is asking you to keep your export evidence inside their account, and the day you need it most is the day that arrangement will cost you.