Ag Retail Crop Input Software: Why Prepay and Custom Application Never Reconcile in April

Why the busiest four weeks of the year are also the least controlled

Second week of April. Three locations, two blend plants, nine application rigs and a tender fleet. A grower calls the counter at 06:50 and asks whether he has enough prepay left to cover the 480 acres going on this week. The counter person opens the accounting system, finds a prepay balance that is a single dollar figure, and cannot tell him what it is committed against, because his prepay was bought in November against specific products at specific prices and half of those bookings have been drawn against but not invoiced. The dispatcher, meanwhile, is standing at a whiteboard with magnets, moving rigs between fields based on what the agronomists texted him last night and which fields drained after Sunday's rain. Nothing on the whiteboard exists in any system. At the end of the week, somebody types the application tickets in from paper.

This is normal for ag retail, and it is not a failure of the accounting software. Agvance and AGRIS are genuinely deep products that have absorbed decades of this industry's specific accounting: bookings, prepay, blend formulas, split invoicing, patronage. Levridge is a newer entrant built on Microsoft Dynamics 365 with a serious co op focus. What none of them was built to be is the operations system for a moving fleet during the four weeks that determine your year, and no product on the market wants to be the grower facing layer that keeps a farmer out of your inbox at 06:50.

The financial exposure is what makes this worth solving rather than tolerating. Prepay is customer money you are holding, seasonal credit is real credit risk against a grower whose income arrives after harvest, and margin on a delivered blend is not knowable until manufacturer rebate programmes settle months later. A retailer that cannot see committed prepay, live credit exposure and applied acres in the same week is managing a working capital swing worth millions from memory.

Problem 1: prepay is a liability with product specific strings attached

A grower prepays in November for tax and price reasons. That money is not a deposit against a running account. It is usually tied to specific bookings: so many tonnes of a fertiliser blend, so many gallons of a chemistry, at prices locked at the time. Drawdown has rules, and the rules differ per retailer and sometimes per grower.

The accounting systems handle the ledger side of this properly. Where retailers get into trouble is visibility during the season: the counter, the agronomist in the field and the grower himself all need to know what is left and what it is committed against, and today only the office can answer. What a build must include is a prepay and booking position view exposed to the people who need it, in a grower portal and on a phone, with drawdown shown per product rather than as one number. That does not require replacing the ledger. It requires reading it reliably and presenting the truth in the places decisions actually get made.

Problem 2: custom application is a field service business hiding inside a retailer

Your application fleet is dispatched from a whiteboard, a phone and a radio. Work orders are field specific, weather dependent, product specific and subject to a restricted use pesticide regime that requires records. Rigs need tender support at the right place at the right time, which is a logistics problem of its own. Applicators hold licences that must be current. Acres applied is a number that decides billing, and it is reported on paper by the operator after the fact.

This is the single largest gap in ag retail software and it is where a custom build pays for itself fastest. What it must include: work orders carrying the field boundary, product and rate, generated from the agronomist's recommendation rather than retyped. A dispatch board that knows rig capability, product loaded, tender position and applicator licence status. Mobile capture in the cab that works offline, records start and finish, captures actual acres from the machine where the controller exposes it, and produces the application record required for restricted use products. In the United States, certified applicators must keep restricted use pesticide application records with a federal minimum retention of two years and many states requiring more, so confirm your state's rules with the state lead agency rather than a vendor. Acres applied then flows to billing without a keying step, which is the difference between invoicing in the same week and invoicing in June.

Problem 3: the blend plant handoff loses the truth every time

An order becomes a blend ticket, the plant blends to formula, actual weights differ from ordered weights because that is how blending works, the load goes out on a tender, and some of it comes back. Billing is supposed to reflect what was actually delivered and applied, not what was ordered. In most retailers that chain has at least two manual transcriptions in it, and each one is an opportunity for a margin leak nobody detects because the amounts are individually small.

The build closes the loop by capturing actual blended weights from the plant control system where one exists, or from a scale ticket where it does not, and carrying that quantity through to the delivery record and the invoice. Returns are recorded as events rather than as adjustments typed later. The reason this matters is not tidiness: fertiliser margin is thin, and a percent lost between the blender and the invoice across a season is real money that never appears as a line item anywhere.

Problem 4: grower credit exposure spans divisions and nobody sees the total

A co op grower may buy agronomy inputs on seasonal credit, deliver grain to your elevator, buy feed, and take fuel from your energy division. His true exposure to you nets across all of that, and in most organisations each division sees only its own slice. Credit decisions in April are made against an agronomy balance while the same grower has a grain position that changes the picture entirely.

A build that consolidates exposure by grower entity, including related entities where a farm operates as three LLCs, is the kind of thing a CFO asks for once and then relies on permanently. The hard part is entity resolution rather than arithmetic: the same operation appears with different names across divisions and somebody has to decide the canonical structure. That is a data governance exercise with your controller, not a coding task, and it belongs at the front of the project.

Problem 5: you do not know your margin until the rebates settle

Manufacturer programmes, volume tiers, early order incentives and market development funds mean that the gross margin on a chemistry sale in April is provisional until a rebate settles months later. Retailers therefore manage the season on a margin number they know is wrong, and the true picture arrives too late to change any decision.

What a build adds is an accrued rebate model: programme terms captured as rules, expected rebate accrued against each sale as it happens, and a live view of margin including accrual with variance shown when programmes settle differently than expected. It also tells your purchasing team, mid season, which volume tiers are within reach and what incremental purchases would earn, which is a decision worth real money and is currently made from a manufacturer's spreadsheet. Where machine assistance is genuinely useful here is narrow: matching settlement statements from manufacturers, which arrive in many formats, back to the accrued programmes so exceptions surface rather than being absorbed.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape for ag retail. An operations layer over your existing accounting system, meaning custom application work orders and dispatch, in cab mobile capture with offline support, blend plant and delivery reconciliation, a grower portal showing prepay and booking positions, and consolidated credit exposure, runs $70,000 to $160,000 and ships in 12 to 18 weeks. Adding rebate accrual and margin analytics, agronomist recommendation intake and multi division consolidation takes it to $180,000 to $400,000 over 9 to 15 months. A full platform replacing bookings, prepay accounting, inventory and billing runs $300,000 to $800,000 over 12 to 24 months.

What drives the price up specifically here: the number of locations and whether each one operates differently, which they usually do. Blend plant automation integration, since plant control systems vary and some are old. Accounting integration depth, because reading positions from Agvance or AGRIS reliably is a different job from writing transactions back into them. Multi division consolidation with entity resolution. And the number of manufacturer programmes you want modelled, since each has its own terms.

What keeps it down: start with custom application dispatch and the mobile ticket. It is the operational bottleneck, it produces the billing data, and it is the part that no product you already own is doing.

Build versus buy, and when buying is the right call

We will say this against our own interest. Do not commission a replacement for Agvance or AGRIS as a first project. 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 a high failure rate and no operational upside in year one. If your accounting system is genuinely the constraint, look at Levridge or a like for like migration before you look at a custom build, and make anyone proposing a rebuild show you the prepay accounting model in detail before you believe them.

Build the layer when two or more of these are true. Custom application is dispatched on a whiteboard and application tickets are keyed from paper after the fact. Growers and agronomists cannot see prepay and booking positions without phoning the office. Your blend plant to invoice chain has manual transcriptions in it. You are a co op serving one grower across several divisions with no consolidated exposure view. Or your margin is provisional all season because rebate accrual lives in a spreadsheet on the CFO's laptop. Each of those has a clear operational payback and none of them requires touching the general ledger.

How to choose a developer for ag retail software

Ask them to explain prepay drawdown back to you before you explain it twice. A developer who thinks prepay is a customer deposit will build something that is wrong in a way your controller will spot in week two, and the correction will be expensive. The right answer distinguishes prepay dollars, bookings against products at locked prices, drawdown as delivery occurs, and the accounting treatment your auditor expects.

Ask what they have built that dispatches a fleet with offline mobile capture. Custom application is field service work with agronomy specifics on top, and a developer who has only built office systems will underestimate the cab.

Ask how they will read from and write to your accounting system, specifically. Reading positions and writing transactions are different risk levels, and a partner who is casual about writing into your ledger during April is a partner who has not been through a season.

Ask who owns the code and the data, and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the code is yours from the first commit. For a business whose peak lasts four weeks, the ability to hire a second team quickly if something goes wrong is a risk control rather than a contract detail.