Ag Retail Crop Input Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does prepay get scoped as a customer deposit so often?

Prepay is the first thing a general developer gets wrong, and it is wrong in a way that costs a rebuild. Someone who has built retail or wholesale systems sees money arriving before goods leave and reaches for a customer deposit or an account credit. That model has one number on it. Prepay in crop inputs does not have one number on it.

A grower prepays in November for tax and pricing reasons, and the money is tied to specific bookings: so many tonnes of a fertiliser blend, so many gallons of a chemistry, at prices locked at the time. Drawdown happens as delivery occurs, against those products at those prices, and the rules for what can be substituted differ between retailers and sometimes between growers. A single balance cannot answer the question a grower asks at the counter, which is not how much money do I have left but do I have enough of the product I booked to cover the acres going on this week.

The consequence is not subtle. Your controller sees it in week two, the accounting treatment does not match what your auditor expects, and the fix touches every screen that displays a balance. Model prepay dollars and product bookings as separate but linked objects, show drawdown per product rather than as a total, and expose that view to the counter, the agronomist on a phone and the grower in a portal. That last part is where the payback sits, because today only the office can answer and every answer costs a phone call during your busiest month.

What goes wrong when you migrate bookings and prepay mid season?

Almost every ag retail project runs into the calendar. The build finishes in late winter, everyone wants it live for spring, and the migration lands on top of a book of open prepay and bookings that growers are actively drawing against. That is the worst possible moment to move data, and it is the moment most projects choose.

The specific failure is that prepay and bookings are not a snapshot. They are a position with history, and the history matters because a drawdown that happened before cutover has to be visible after it. Import balances alone and you get a system showing a grower with fifteen tonnes remaining and no way to show what he already took. The first time somebody disputes it, you are back in the old system to answer, and staff quietly keep using both.

Three rules keep this out of trouble. Migrate at the natural seam in your season rather than the convenient one in your project plan, which for most retailers means after the spring rush and before the fall booking window opens. Bring across the booking with its original terms and its drawdown history, not just the remaining quantity, so any balance can be explained back to the grower. And reconcile every grower position to the old system on a stated date with your controller signing off, per location, before anyone invoices out of the new one. Location by location is slower and it is the only version that survives contact with a season.

Why do the integrations that matter here break after launch?

Two integrations decide whether an ag retail build stays useful, and both fail quietly rather than loudly. The first is your accounting system, usually Agvance or AGRIS. Reading positions out of it is a different risk from writing transactions into it, and quotes routinely blur the two. A read integration that stops returning current data looks identical to a slow day at the counter. A write integration that misposts during April is a very bad week for your controller. Keep the boundary explicit: the accounting system stays the source of truth for the ledger, the operations layer reads from it, and anything written back is queued, reviewable and reversible rather than fired straight into the books.

The second is the blend plant. Plant control systems vary widely, some are older than the rest of your stack, and the connection is frequently a file drop or a serial feed rather than an interface anyone documents. What breaks is not the link itself but the assumption behind it. Actual blended weights differ from ordered weights, that is how blending works, and a system treating the ordered quantity as truth will silently reintroduce the margin leak you built it to close. When the plant feed fails, the fallback must be a scale ticket captured deliberately, not the order quantity flowing through by default.

What happens when pesticide records and applicator licences are not covered?

This is the gap that turns an operational inconvenience into a regulatory one. In the United States, certified applicators must keep records of restricted use pesticide applications, with a federal minimum retention period of two years and many states requiring more. Confirm your own state's requirements with the state lead agency rather than with a software vendor, because the detail varies and the vendor is not the one who gets inspected.

When the record is not produced by the system, it is produced by the operator, later, from memory and a clipboard. Fields get transposed, rates get rounded to what was intended rather than what went on, and weather observations are filled in at the end of the day for four jobs at once. None of that is fraud. It is what happens when the record is a chore separated from the work. The exposure is that the document you would hand an inspector was written after the fact by someone reconstructing a long day.

The second half of this gap is applicator licensing. Licences expire, and an expired licence discovered after the application has been made is a problem with no good fix. A dispatch board that does not know licence status will eventually assign the wrong person, usually during the week when you are assigning anybody who can drive. Hold licence and certification status with expiry dates against each applicator, block or warn at assignment rather than reporting afterwards, and generate the application record from the same capture that produces the billing quantity, so it exists because the work happened rather than because someone remembered to write it.

Should you build custom or configure what you already own?

We will say this against our own commercial interest. Do not commission a replacement for Agvance or AGRIS. Those systems encode decades of ag retail specific accounting, including prepay, bookings, blending, split billing and patronage, and rebuilding that is a multi year programme with no operational upside in your first season. If your accounting system genuinely is the constraint, evaluate Levridge or a like for like migration first, and make anyone proposing a rebuild walk you through the prepay accounting model in detail before you believe them.

Build the layer around your accounting system when two or more of these are true. Custom application is dispatched from a whiteboard and tickets are keyed from paper after the fact. Growers and agronomists cannot see prepay and booking positions without phoning the office. The chain from blend plant to invoice has manual transcriptions in it. You are a co op serving one grower across agronomy, grain, feed and energy with no consolidated exposure view. Or your margin is provisional all season because rebate accrual lives in a spreadsheet on the CFO's laptop.

How do hidden costs get into an ag retail software quote?

Location variation is the largest and it almost never appears in a proposal. Quotes are scoped against how the business works, and ag retail businesses do not work one way. Three locations frequently means three sets of conventions for booking terms, delivery documentation and who is allowed to authorise what. Discovering that in build is a change order per location. Ask for the scope to be written per location rather than per company.

Manufacturer programmes are the third. Every programme you want modelled for rebate accrual carries its own terms, tiers and settlement behaviour, and each is real work. A quote saying rebate management covers the mechanism, not your twenty programmes. Fourth, entity resolution for multi division exposure, which is a data governance exercise with your controller deciding the canonical structure for growers operating as several entities. Fifth, the season itself, because support during April is not the same product as support in January, and a contract that does not say so will be tested in the worst week of your year.

What separates a build that works from one that fails here?

The builds that work start with custom application dispatch and the in cab ticket. It is the operational bottleneck, it produces the billing data, and it is the part no product you already own is doing. The builds that fail start with a grower portal, because it demos well, and arrive at spring with a nice portal displaying numbers that still depend on paper tickets.

The second difference is that successful projects have an operations person from the agronomy side in the room every week, not the IT manager and not the controller alone. The rules that matter here, on tender coordination, on what an operator does when a field is too wet, on how a partial load is handled, live with dispatch and applicators. Teams that gather those in week two ship something people use. Teams that gather them in user acceptance testing rebuild.

Finally, settle code and data ownership in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm at will. At Digital Heroes the code is yours from the first commit. For a business whose peak lasts four weeks, being able to bring in a second team quickly is a risk control rather than a contract detail.