Service

Cooperative management software development

For the managers, secretaries and boards of agricultural cooperatives and producer groups who need member records, intake, grading, pooled sales, settlement, levies, supplies ordering and voting designed around how their cooperative actually trades.

The problem

What goes wrong today

Where it usually starts

A producer cooperative of any size tends to run on an intake book at the weighbridge or the store, a grading sheet, a spreadsheet of members with their shares, an accounts package that treats every member as a supplier and a customer at once, and a secretary who holds the rules in her head.

  • A member delivers three loads of grain in a week; the weights are on tickets, the moisture and grade on a separate sheet, and the two are matched by hand at month end.
  • The pool for that grade is sold in four parcels over the winter at different prices, and the settlement to each member depends on their tonnage, their grade, the pool average, the storage levy and the deduction for the fertiliser they ordered through the cooperative in spring.

Where it gets harder

The statement that explains all this is built in a spreadsheet, one tab per member, and a transposition error in one tab costs a long afternoon and some trust.

  • The AGM notice goes out by post, proxies arrive as letters and the vote count is a show of hands weighted by shares that someone checks afterwards.
  • Scheme membership certificates and assurance documents for each member sit in a filing cabinet and are hunted for when a buyer asks.
  • Nobody can tell a member, on the phone, what they are owed today.

Scope of the service

What the build covers

A custom cooperative management build normally covers:

  • A member register with shareholdings Share classes, voting rights and the history of transfers
  • Intake records per member and per delivery with weights Grades and quality measures such as moisture or protein entered at the point of intake, with the ticket as the record
  • Pools by crop Grade and season into which intake is allocated
  • Pooled sales recorded as parcels against a pool with price and tonnage
  • Settlement rules That turn pool proceeds into a per-member amount by tonnage and grade, with advances, interim and final payments
  • Levy and deduction rules For storage, drying, capital retention and supplies bought through the cooperative
  • Input supplies ordering by members with prices Delivery and deduction from settlement
  • Member statements showing every intake Sale allocation, levy, deduction and payment
  • Payment runs exported to the bank and the accounts package
  • AGM notices Proxies and voting weighted by shares
  • A document store per member For scheme certificates and assurance records kept as supplied

We follow one crop through a season with you first: intake, grading, pooling, the first parcel sold, the interim payment, the final settlement and the statement. Each step becomes a named stage in the scope document, and the settlement and deduction rules are written out in plain words before anything is built.

Deliberately out of scope

  • The general ledger, payroll, and the cooperative's statutory filings, which stay with the accountant and the secretary
  • The system supplies exports and the records behind them. Scheme and assurance documents are stored and dated as records, and the system never asserts a member's status

When the scope grows

Scoping scenario

A grain cooperative with two hundred members and three intake sites wants weighbridge tickets captured at the site, pools by grade with advances paid at intake, two interim settlements, a final settlement after the last parcel, supplies deducted at settlement and AGM voting weighted by share class. The multi-stage settlement and the share-weighted voting are what make it a custom project.

Deliverables

What you receive

  • Discovery notes from following one crop from intake to final settlement
  • A scope document naming each stage and writing out the settlement, levy and deduction rules in plain words, with what is out of scope
  • Design of the intake screen, the pool view, the settlement run and the member statement on desktop, tablet and the member portal on a phone
  • The build, deployed to your hosting or ours, with an audit trail on every intake, grade and settlement change
  • Migration of members, shares, open pools, supplies balances and historic statements from spreadsheets and the accounts package, where relevant
  • Training for the intake clerks, the finance person, the manager and the secretary, with a written guide per role
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access to the member spreadsheet, intake tickets, grading sheets, the accounts package and last season statements, with the manager as the day-to-day contact.

    Project stage: Onboarding
  2. Planning

    A crop walk-through with the manager, the finance person, an intake clerk and a board member; the settlement rules, scope document and milestone plan are agreed.

    Project stage: Planning
  3. Design

    Clickable designs of intake, the pool view, a settlement run and a member statement, reviewed against last season figures the finance person knows by heart.

    Project stage: Design
  4. Development

    Built in stages: members and shares first, then intake and grading, then pools and sales, then settlement, levies and statements, then supplies, voting and documents.

    Project stage: Development
  5. Client review

    The cooperative re-runs last season on the new system: intake from real tickets, the parcels actually sold, and the settlements compared line by line with the statements sent.

    Project stage: Client review
  6. Revisions

    Differences found in the re-run, and changes to statement layout and deduction order, are made and re-checked against the written rules.

    Project stage: Revisions
  7. Ready for launch

    Members, shares and open balances migrated and reconciled, bank and accounts exports tested, cut-over planned between seasons or between settlements.

    Project stage: Ready for launch
  8. Delivered

    The cooperative runs on the new system; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Weighbridge and grading instruments at intake sites
  • Accounting packages for settlements, levies, supplies invoices and member balances
  • Bank payment files for member payment runs
  • Email and SMS providers for intake receipts, statements and AGM notices
  • Supplier catalogues and ordering for input supplies
  • E-signature tools for share transfers and proxies
  • Document storage for scheme certificates and assurance records
  • Buyer contract and parcel confirmation feeds where the cooperative trades through a merchant

How we would approach it

Worked example

Concept demo

A grain cooperative with three intake sites and share-weighted voting

In this scoping scenario, a grain cooperative with two hundred members received deliveries at three sites, each with its own weighbridge and a clerk grading for moisture and protein. It wanted tickets captured at the site and allocated to pools by grade, an advance paid per tonne at intake, two interim settlements as parcels were sold through the winter, a final settlement after the last parcel, storage and drying levies and spring supplies deducted at settlement, and an AGM where votes were weighted by share class and proxies were recorded.

The scope we would propose: an intake screen per site linked to the weighbridge, pools by crop and grade with allocation rules, a settlement engine that runs advances, interims and finals from written rules with every figure traceable to a ticket or a parcel, levies and deductions applied in a defined order, member statements and payment files, and voting with share weights and proxies. The reason this needs a custom build is the settlement: an accounts package can pay a supplier, but it cannot explain to a member why their tonne of feed wheat paid what it did after three parcels and a drying levy.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of members, share classes and intake sites
  • Crops, grades and quality measures captured at intake, and instruments to connect
  • Settlement structure: advances, interims, finals and the deduction order
  • Levy rules and supplies ordering with deduction from settlement
  • Voting rules, proxies and the AGM process
  • Volume and condition of member, share, pool and statement history to migrate
  • Bank and accounts package exports to be shaped
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

When is a custom build the right choice rather than the package?

When your settlement structure, share rules or intake sites break the assumptions of the cooperative management package. During discovery we lay your crop walk-through against the package and say plainly whether configuration covers it or whether, for example, your multi-stage settlement with deduction ordering needs custom work.

Can every figure on a member statement be traced?

Yes, that is the point of the build. Each line on a statement links back to an intake ticket, a pool allocation, a sale parcel, a levy rule or a supplies order, and changes to any of them are recorded with who made them and when.

Can you migrate our open pools and balances mid-season?

Usually yes, though we prefer a cut-over between settlements. We import members, shares, intake to date, parcels sold and balances, reconcile against your spreadsheets and the accounts package, and agree the first settlement on the new system before switching. What can be carried over is stated once we have seen the data.

Does the system handle our scheme and assurance records?

It stores them per member with dates, as records the cooperative keeps and supplies when a buyer asks, and can warn when a dated document is due to lapse. It does not verify or assert membership of any scheme; that stays with the cooperative and the scheme body.

Who owns the system afterwards?

The cooperative does. Source code and data are handed over at delivery; hosting and maintenance are optional, separately agreed and movable to another provider.

Get a project quote for cooperative management software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote