Dominic Jainy stands at the intersection of traditional agriculture and high-stakes digital transformation, bringing a seasoned perspective to how grain elevators and cooperatives manage their books in 2026. With a professional history rooted in the complexities of artificial intelligence and blockchain, Jainy has spent the last several years helping agricultural enterprises navigate the shift from legacy spreadsheets to the robust Microsoft Dynamics 365 ecosystem. His expertise is particularly relevant today as the “messy” reality of the field—moisture levels, fluctuating basis, and complex grower settlements—collides with the rigid requirements of modern ERP systems. In this conversation, we explore the structural gaps that often leave generic accounting software struggling at the scale house and the specialized logic required to bridge those divides.
The discussion centers on the fundamental mismatch between standard inventory modules and the fluid nature of grain valuation, where water weight and market standards dictate the bottom line. We delve into the limitations of native Business Central configurations, such as the inability of purchase agreements to handle the nuances of Hedged-to-Arrive (HTA) contracts or deferred-payment pricing. Jainy also breaks down the essential role of ISV extensions like AgriERP and Levridge in creating a seamless flow from the scale ticket to the general ledger, ensuring that the moisture math doesn’t just sit in a siloed spreadsheet but drives every financial decision.
Standard inventory modules are typically designed to value items at a fixed cost per unit, yet grain valuation is notoriously fluid. How does this fundamental conflict manifest in the day-to-day operations of a modern grain elevator, and why is it so disruptive to standard accounting?
In a typical distribution environment, you receive a pallet of parts, and that item has a specific SKU and a fixed cost that stays relatively stable until it’s sold. Grain doesn’t behave that way because it is a living, breathing commodity where the value is inseparable from its physical condition. When a truck rolls onto the scale in 2026, the inventory isn’t just “corn”; it is a specific volume of dry matter currently held at a certain moisture percentage, which must be adjusted to market standards like 15% for corn or 13% for soybeans. If the corn arrives at 18% moisture, the system has to instantly calculate the “shrink”—the loss of water weight—and apply a drying fee to the grower’s account. Standard inventory modules in Business Central have no native object for moisture or shrink, meaning the “bushels” on your balance sheet won’t match the physical reality in your bin unless you are manually adjusting every single transaction. This creates a massive headache for the controller because the inventory is valued against a market that moves every minute, rather than a static purchase price on a PO.
When a truck hits the scale, the driver isn’t just delivering weight; they are delivering a complex set of data points that dictate the entire financial settlement. Why can’t the standard “purchase receipt” in Business Central function as a scale ticket?
The scale ticket is the ultimate source of truth in grain accounting, but a standard purchase receipt is far too simplistic to capture the necessary detail. A true scale ticket must record the gross, tare, and net weights, but it also needs to house test weight, foreign material, and moisture levels—data points that are captured on the probe and scale before a price is even discussed. In a native ERP environment, forcing this data into a purchase receipt loses the physical discipline required at the scale house, where a driver needs to sign a document that reflects the raw physical attributes of the load. Furthermore, that load might be destined for a forward contract, a basis-only deal, or an HTA contract, and the system needs to know which bucket to put it in before the receipt is even posted. Without a dedicated scale ticket object, you end up with a disconnect between the yard and the front office, leading to reconciliation nightmares when it’s time to settle with the grower.
Many operations in 2026 still find themselves leaning on complex Excel workbooks with names like “Settlements_Final_v4” to bridge these software gaps. What are the most significant risks of this “Excel-as-an-ERP” strategy as an organization begins to scale?
The danger of the “Excel pattern” isn’t just the risk of a broken formula; it’s the lack of a verifiable audit trail that can withstand a serious financial review. When an operation gets large enough, that workbook becomes a massive liability because the moisture math and the basis calculations are often trapped in a single person’s head or a single “formula column” that only the controller understands. If that person takes a vacation during a heavy harvest or leaves the company, the entire month-end close can come to a grinding halt because the logic isn’t embedded in the system. We’ve seen cases where a single error in a spreadsheet resulted in thousands of dollars in overpayments or underpayments to growers, which damages the reputation of the elevator. By the time an operation reaches the $5M to $100M revenue band, the complexity of tracking deferred payments across tax years in a spreadsheet becomes a game of Russian roulette with your compliance and tax reporting.
There is a distinct logic shift between standard Accounts Payable and what we call “grower accounting.” Could you walk us through the specific calculations required to generate a fair settlement statement for a grower today?
Standard AP is a passive process where you receive an invoice from a vendor and pay it; grower accounting is an active, computed process where you, the buyer, produce the document for the seller. To get to a final settlement, the system has to take the contract price and then layer on a series of complex variables: you add or subtract the basis, subtract the moisture shrink, and then deduct drying charges, storage fees, and quality discounts for things like low test weight. Then, you have to look at the grower’s account to see if any advances were already paid against that contract and net those out so you don’t overpay. The result is a settlement statement that serves as a detailed breakdown for the grower, showing exactly how 1,000 bushels of wet corn turned into a specific dollar amount in their bank account. Without a calculation engine that can handle these variables in real-time, you’re forced to do it all by hand, which is where the errors crawl in.
In your experience, why do standard “Purchase Agreements” in an ERP fall short when trying to manage Hedged-to-Arrive or deferred-payment contracts?
A purchase agreement is designed for a known quantity at a known price, which is fine for the cash market, but it’s completely inadequate for the sophisticated marketing tools used by growers today. An HTA contract, for instance, allows the futures leg of the price to be fixed while the basis remains floating, meaning the final price isn’t actually determined until a later “price-fix” event. Standard systems can’t handle a pricing mechanism that resolves over the life of the contract; they want a price on line one of the order right now. Additionally, deferred-payment contracts often require the settlement to land in a future tax year for the grower’s benefit, which creates a timing mismatch that standard ERP logic isn’t built to navigate. This forces the staff to track the “real” state of the contract in a parallel system, which completely defeats the purpose of having an integrated ERP.
For a diversified operation like E&H Farms in Kansas, which deals with everything from soybeans to pinto beans, how does an integrated extension like AgriERP manage the “messy” reality of multi-entity consolidation?
Diversified operations like E&H Farms are juggling a lot of moving parts—they aren’t just growing corn; they are managing seed wheat, pinto beans, and traditional row crops across multiple legal entities. An extension like AgriERP allows them to use harvest tickets as the primary data capture point, which then feeds into a centralized system that can handle intercompany transfers and consolidations without losing the lot-level detail. For example, if they move seed wheat from one entity to another for processing, the system maintains the lot tracking and quality attributes (like germination rates or purity) through the entire transfer. This allows the leadership to see a consolidated view of their open positions and inventory across the entire enterprise, while still being able to drill down into the specific settlement history of a single field or grower.
When an operation is ready to move away from their “ugly” legacy workbooks and evaluate a new system, what is the most effective way for them to test a vendor’s capabilities in a demo?
The best advice I can give is to stop looking at the “pretty” dashboards and instead bring your two ugliest, most complicated contracts to the demo table. Find a contract that’s partially priced, or a deferred-payment deal that straddles two different tax years, and ask the vendor to walk a load through the entire lifecycle—from the moment the truck hits the scale to the moment the final settlement journal hits the GL. You want to see how the system handles a “price-fix” event against futures movement and how it calculates the drying fee for a load that came in at 18% moisture. If the vendor can’t show you that logic working in a live session with your own messy data, they aren’t going to be able to handle your business during the chaos of harvest. Shortlist the partners who don’t just talk about “agriculture” but can actually demonstrate the math behind the settlement.
What is your forecast for the evolution of grain accounting technology over the next few years?
I expect we will see a much tighter integration between the physical sensors at the elevator—like automated moisture probes and scale hardware—and the ERP’s settlement engine, essentially removing the manual data entry step entirely. By the end of this decade, the “scale ticket” as we know it will be a digital-first object that triggers real-time margin calls and position updates the second the grain hits the pit. We’re also moving toward a world where blockchain-style ledgers could provide growers with instant, transparent access to their settlement status, reducing the need for the endless “where is my check” phone calls that plague elevators today. The operations that thrive will be those that treat their data with the same respect they treat their grain, moving away from siloed spreadsheets and into a unified, “single source of truth” architecture that can handle the volatility of the global market.