Data Analytics Solution of the Year” 2026 in Agtech Breakthrough Awards 2026
Agentic AI, computer vision, generative AI
Web, mobile, and custom software
Engineering, warehousing, analytics
Farm, livestock, and crop software
Traceability and food supply chain
EHR, telehealth, and interoperability
ERP implementation and support
Dynamics 365 and Business Central
CRM consulting and integration
B2B ecommerce, ERP integrations and migrations
Track every grower's share of the pool by volume and grade, pay advances and progress payments on schedule, and close the season with a final settlement your members can check line by line.
Thousands of deliveries from hundreds of growers land in one commingled pool, the crop sells over months, and every grower expects an accurate share of the net. AgriERP holds the whole pool in one system, from the first scale ticket to the last equalization payment, so the numbers finance reports match the numbers operations recorded.
Pooling is a marketing practice specific to cooperatives. Instead of each grower selling their own crop at whatever price the market offers on delivery day, members deliver into a common pool. The cooperative's marketing staff sells the combined volume over the season, deducts the shared costs of storing, handling, and marketing it, and pays every member the average net price for product of like quality.
Pool accounting is the bookkeeping behind that arrangement. It answers three questions for every pool the cooperative runs:
The USDA has documented this model for decades. Its research on cooperative pooling describes a member's share of pool proceeds as determined by the volume of product contributed, adjusted for quality premiums or discounts, with pool operating costs allocated among producers and deducted before settlement. That is the entire discipline in one sentence, and it is harder to execute than it sounds.
Each structure has its own open and close rules, cost allocation logic, and payment timing. Your accounting system has to model all of them.
Marketing decisions sit with the co-op. Members receive the average price. Runs days for perishables, a year or more for storables.
The grower keeps some pricing control. Call pools sell at a grower target price; purchase pools pay the cash market on delivery day.
One commodity or grade per pool. Common in citrus and tree nuts.
One accounting system across many commodities and grades. Common in vegetables.
Opened for freeze or hail damaged product so distressed lots don't drag down the regular pool's average.
Growers get paid in stages, and the true price isn't known until the pool closes. This is the sequence most US cooperatives follow.
A scale ticket captures volume, grade, quality factors, and lot for every load.
A board-set amount per unit or a percentage of estimated value, paid at or near delivery.
Declared as pool contents sell and proceeds come in over the marketing year.
Operating costs, freight, storage, interest, dockage, shrink, and per-unit retains charged to the pool.
Pool closes once substantially all product is sold. Members receive the balance on their pro rata share.
Year-end patronage allocation, retained equity, and 1099-PATR reporting as a separate step.
Between step 1 and step 5 the cooperative is holding proceeds and costs in suspense across an entire season. Every advance is a liability against a final number nobody knows yet. That is the accounting problem pool software exists to solve.
Commodity pools are most common in fruit, vegetable, nut, rice, and dairy cooperatives, with cotton and grain cooperatives using them to a lesser degree.
Nut cooperatives commingle member deliveries into pools, often with separate classifications within a pool by variety and grade.
Regional marketing cooperatives run seasonal pools by growing region and fiber type, with a board-set advance, progress payments as bales sell, and a year-end distribution.
Southern rice cooperatives run seasonal pools settled per bushel after adjusting for freight, storage, and interest.
Grower pools that can take more than a year to fully close after harvest, with returns reported per barrel or per box.
A projected per-ton price at delivery, revised through the marketing year, settled on a final per-ton figure after the campaign.
Federal Milk Marketing Orders use marketwide pooling to compute a blend price. Dairy co-ops still reconcile it against their own member payments.
AgriERP was built for nut, dried fruit, fresh produce, row crop, and greenhouse operations, which puts it squarely in the sectors where pooling is standard practice.
These four get conflated constantly, including by software vendors. They are different things, they live in different parts of the ledger, and they follow different tax rules.
Governs how a marketing pool's sales proceeds and costs are aggregated and how an average net price is paid to members based on what they delivered. It is about the crop.
The multi-year cycle of returning retained patronage and per-unit retain equity to members, often on a rolling base-capital plan that runs a decade or more.
Amounts withheld from members based on units of product handled, fixed without regard to net earnings. Pooling cooperatives use them heavily to build capital, and many structure advances and settlement payments as per-unit retains paid in money.
Distribute the cooperative's net margins back to members in proportion to the business each member did with the co-op. They depend on whether the cooperative made money. Under Subchapter T, qualifying patronage dividends are deductible at the cooperative level and reported on Form 1099-PATR.
A cooperative accounting system has to keep all four straight and connected. The pool settlement feeds the patronage calculation, the retains feed the equity ledger, and the equity ledger feeds the redemption schedule years later. Break one link and members stop trusting the statements.
Standard ERP systems track dollars. Pool accounting tracks bushels, bales, pounds, and boxes, each with a grade attached, across hundreds of member accounts, over a season that doesn't line up with the fiscal year.
A generic inventory module knows quantity and cost. It doesn't know that lot 4471 came in at a moisture level that triggers a discount, or that two members' deliveries of the same variety belong in different quality pools.
There is no object in a standard ERP that represents "all Pima cotton delivered between September and December, sold over the following ten months, with costs allocated pro rata." Finance builds it in spreadsheets outside the system.
Advances, progress payments, and final settlements all net against a pool return that isn't final until close. General AP modules assume you know what you owe when you cut the check.
When the scale house, the warehouse, and the general ledger live in separate systems, every pool close turns into an argument about whose numbers are right.
Patronage allocation, retains, and revolvement get handled in a separate application or more spreadsheets, and reconciled by hand at year end.
Heavy customization on a platform that was never designed for pools becomes a liability at every upgrade. This is the hidden cost that turns into long-term technical debt.
AgriERP treats the pool as a first-class object in the system, connected to the same lot, contract, and member records that operations already uses.
Define seasonal, contract, single-product, multiproduct, and special pools with their own open and close rules. Assign deliveries to the right pool automatically from the contract and the grade on the receiving ticket. Run as many concurrent pools as your commodities and quality classes require.
Every scale ticket flows into the pool with its quantity, grade, quality factors, and lot number attached. Premiums and discounts apply at the lot level from the grading data, so each member's share reflects what they actually delivered.
Set the initial advance as a fixed amount or a percentage of estimated value. Declare progress payments as sales proceeds arrive and pay them by ACH or check. Every payment posts as a liability against the pool so the system always knows the outstanding balance owed to each member.
Charge freight, storage, interest, handling, marketing costs, and per-unit retains directly to the pool. AgriERP allocates them across members pro rata to units delivered, with contract-specific deductions applied where they belong. No separate cost spreadsheet, no manual allocation at close.
When the pool closes, AgriERP calculates each member's net return, reconciles it against every advance and progress payment already made, and produces the final settlement. Growers get a statement that shows deliveries, grade adjustments, deductions, prior payments, and the balance due on one page.
Members log in to see delivery history, pool status, payments received, and settlement statements without calling the office. Fewer phone calls in settlement season, and fewer disputes when the final number lands.
Pool results feed directly into patronage allocation and per-unit retain tracking, with equity recorded by member, by year, and by class. Revolvement schedules and 1099-PATR reporting pull from the same ledger, so year-end doesn't start with a reconciliation project.
Because the pool, the inventory, the contracts, and the general ledger live in one Microsoft Dynamics 365 environment, the number the board sees in the financial statements is the number the scale house recorded. Pool close stops being a negotiation between departments.
AgriERP runs on Microsoft Dynamics 365 Business Central and Finance & Operations, with an Oracle NetSuite edition also available. That matters for pool accounting for two reasons.
First, the general ledger, AP, inventory, and reporting underneath the pool module are enterprise-grade and maintained by Microsoft. You're not betting your cooperative's books on a legacy grain system with a shrinking user base.
Second, the agriculture-specific layer, including pools, grower contracts, grade-based settlement, and member equity, ships as maintained modules rather than one-off custom code. Upgrades don't break your settlement logic.
AI powered by Microsoft Copilot
For cooperatives that have outgrown a 20-year-old commodity accounting package and want modern reporting, mobile access, and a platform their auditors already know, this is the practical middle path between a generic ERP and a narrow co-op-only system.
We helped Grant4D to migrate from Quickbooks to the AgriERP standard package with D365 Business Central at the core to enhance ..
We implemented AgriERP Enterprise package with Dynamics 365 ERP for Rombola which digitized their processes, automated repetitive tasks and boosted overall productivity
Delivered by Folio3, a Microsoft Solutions Partner.
ERP Solution of the Year, 2025.
Agriculture and enterprise ERP expertise on one team.
Pool accounting is the method cooperatives use to track a commingled pool of member deliveries, aggregate the sales proceeds and shared costs, and pay each member an average net price based on the volume and grade they contributed. Members typically receive an advance at delivery, progress payments as the pool sells, and a final settlement when the pool closes.
Growers deliver into a common pool rather than selling individually. The cooperative's marketing staff sells the pooled product over the season. Costs of storage, handling, and marketing are deducted from the pool's proceeds, and the net is distributed to members pro rata to their deliveries, adjusted for quality premiums and discounts.
In stages. An initial advance is paid at or near delivery. Progress payments follow as sales proceeds arrive. When all or substantially all of the product is sold and costs are reconciled, the pool closes and each member receives a final settlement for the remaining balance on their share.
Pool accounting distributes the net proceeds of a specific commodity pool based on what each member delivered. Patronage dividends distribute the cooperative's overall net margins based on the business each member did with the co-op. A cooperative can run pools and pay patronage in the same year, and the two are calculated and taxed differently.
A per-unit retain is an amount the cooperative withholds from member payments based on the units of product delivered, regardless of whether the co-op earned a profit. Pooling cooperatives use them to build capital. They are treated differently from patronage dividends under Subchapter T.
A closed pool method carries any unsold inventory forward at the lower of cost or market and settles the pool at year end. An open pool method leaves the pool open into the following year until the product is sold. Which one a cooperative uses affects both member payment timing and tax reporting.
Yes. Cooperatives commonly run separate pools by commodity, variety, grade, region, and delivery window, plus special pools for damaged product. AgriERP supports concurrent pools with independent open and close rules and independent cost allocation.
Pool settlement results feed AgriERP's patronage allocation and member equity records, and 1099-PATR reporting pulls from the same ledger. Tax treatment varies by cooperative, so settlement and patronage rules are configured to match your bylaws and your tax advisor's guidance.
Tree nuts, dried fruit, fresh produce, citrus, row crops, rice, and cotton, along with member-owned grower networks and processing cooperatives. The pool module is commodity-agnostic; the grading and quality rules are configured per crop.
Agtech Breakthrough Award Winners'26
Recognized as the top data analytics platform in agriculture at the 2026 AgTech Breakthrough Awards. Trusted by farm owners, processors, and exporters to turn operational data into better decisions.
