A season of settlements, one register
Sell grain across a season and the settlement statements pile up — one per load or per delivery period, each one a self-contained PDF with its own gross quantity, price and deductions, and no relationship to the statement before it or after it. Answering a simple question like "what did we average per bushel this season" means opening every single one and adding it up by hand, because no individual statement was ever built to answer that question on its own.
Multiply that by however many commodities an operation markets in a given year, and the manual version of this task turns into a genuinely large spreadsheet exercise every single season, rebuilt mostly from scratch each time rather than growing naturally as settlements arrive.
A season register solves a different problem than reading any one settlement carefully — it's about taking every settlement, regardless of which elevator issued it or how its statement is laid out, and putting every load into the same running spreadsheet.
That distinction matters because the two problems have different natural solutions. Reading one settlement carefully is about accuracy on a single document — getting every deduction right on that one statement. Building a register is about accumulation over time — making sure nothing from the whole season gets lost, miscounted, or left out of the running total simply because it arrived on a busy week and never got added in.
Why a stack of settlements doesn't add itself up
Every elevator's layout is different
A large grain company's statement and a small independent elevator's handwritten settlement carry the same underlying numbers in completely different formats — there's no shared template to copy figures from.
One statement can be one load or a dozen
Some elevators settle every truckload separately; others batch a week of deliveries into one summary — a register has to handle both without double-counting or losing load-level detail.
Statements arrive on no fixed schedule
A settlement lands whenever a load is delivered and priced, which during harvest can mean several in a single week — hard to keep pace with by hand.
A revised statement can arrive weeks later
A correction to an earlier settlement — a re-graded load, a pricing adjustment — needs to be reconciled against the original entry, not simply added as a new, disconnected line.
What this doesn't do, stated up front
Doesn't connect to an elevator's grower portal
There's no login, no API. You download or receive each settlement statement yourself, the way you already do, and upload it here.
Doesn't calculate marketing strategy or forward pricing advice
The register shows what was actually delivered and paid — deciding whether to sell, hold or contract ahead stays a marketing decision, not something this tool makes for you.
Doesn't audit whether the price offered was competitive
It confirms the statement's own math is internally consistent — comparing prices across elevators or against a benchmark is a separate analysis.
What gets read
| Field | Kept as |
|---|---|
| Elevator or buyer name | Its own column, per load |
| Delivery or settlement date | Sortable date field |
| Gross quantity and price | Numeric fields per commodity |
| Dockage, drying, storage, checkoff | Separate deduction columns |
| Net amount paid | Reconciled against gross and deductions |
How it works
Upload settlement statements as they arrive, or all at once
Any elevator, co-op or buyer, any format — PDF, scan or fax.
Every load is read
Gross quantity, price and each deduction, kept linked to the statement it came from.
Added to the register
New loads appended, revised statements matched against and flagged next to the original entry.
Export
Excel, CSV or JSON — one row per load, sortable by elevator, date or commodity.
A register, built load by load
| Date | Elevator | Bushels | Net paid |
|---|---|---|---|
| Sep 14 | County Co-op | 4,200 | $21,800 |
| Sep 21 | County Co-op | 5,100 | $26,650 |
| Oct 3 | Riverbend Grain | 3,800 | $19,540 |
| Oct 3 | Riverbend Grain (revised) | 3,800 | $19,890 |
Four settlements, two elevators, one revision — and one register that shows all of it in date order, with the revised October 3rd settlement kept next to the original so the correction is visible rather than replacing the earlier row silently.
This isn't a connection to the elevator's portal
Worth being precise about the boundary. Many elevators offer their own grower portal with a payment history — this doesn't log into that, sync with it, or replace it. You download or receive each settlement statement the way you already do, and upload it here. What this adds is a single register across every elevator you sell to, which no single elevator's own portal will ever show you.
When a settlement is later corrected
A re-graded load or a pricing adjustment sometimes means an elevator issues a revised settlement weeks after the original. Uploaded alongside the original, the revision is matched to it rather than treated as an unrelated new load — the register shows both, with the difference between them visible.
How often to run this
As statements arrive is the simplest habit during an active selling period — a few minutes per settlement keeps the register current with almost no batching effort. For a season with only a handful of deliveries, running it once at season end works just as well.
Selling to more than one elevator or buyer
An operation spreading sales across two or three elevators — for price shopping, storage capacity, or relationship reasons — ends up with settlement statements in as many different formats. Every one reads into the same register regardless of source, which is where the real value shows up: a single sortable view of the whole season, not three separate piles that each need their own manual total.
Who this is for
Grain and oilseed operations
A season register built as settlements arrive, instead of a year-end scramble through a folder of PDFs.
Operations selling to more than one elevator
One consistent register regardless of which elevator's format a given settlement uses.
Accountants and bookkeepers serving grain producers
A clean, load-by-load record that drops directly into a client's income summary.
Operations preparing for a loan review
A full season's sales history, in one sortable spreadsheet, ready for a lender to review.
Feeding a season register to an accountant
A register built load by load through the season, rather than reconstructed in a single sitting at tax time, is exactly the kind of record an accountant can work from directly — dated, load-level detail rather than a single annual sales total with no way to verify it.
Starting with one elevator
For an operation selling to several elevators, starting the register with the highest-volume one — and confirming the format reads cleanly — is a reasonable first step before adding the rest, the same way it's worth proving out any new record-keeping habit on the simplest case first.
Export formats
Excel, CSV or JSON. The Excel export in particular is built to be a working document, not just an archive — sortable by elevator, date or commodity, with formulas for a season average price a light lift to add on top.
Comparing price and dockage across elevators
An operation selling to more than one elevator often has a rough sense of which one tends to offer a better price, or a lower dockage rate, but rarely a precise one — comparing two individual settlement statements side by side gives one data point, not a pattern. A register spanning a full season, with every load from every elevator in the same structure, is what turns that rough impression into an actual comparison: an average effective price per bushel by elevator, or a dockage rate that's consistently a percentage point higher at one location than another.
That comparison doesn't answer the marketing question of where to sell next season on its own — basis, logistics and relationship all matter too — but it does put a real number behind a decision that's otherwise often made on impression alone.
A backup record independent of any single elevator
An elevator's own grower portal is a convenient record while it's available, but it's not something a farm controls — an account could be lost in an elevator merger or ownership change, a portal could be discontinued, or a relationship with a given buyer could simply end. A register built and kept independently, from the statements as they were originally issued, survives any of that. It's the same reasoning behind keeping paper receipts even when a store offers digital ones: convenient while it lasts, but not something worth being solely dependent on.
Scale tickets versus settlement statements
A scale ticket, issued at the moment of delivery, records gross and net weight for that specific load — it's not the same document as the settlement statement, which arrives later with price and deductions applied. Some operations keep scale tickets as their own record through the season and reconcile them against the eventual settlement once it arrives, which is a useful secondary check: does the quantity on the settlement actually match what the scale ticket recorded at delivery.
Where both documents are available, reading them together closes that loop entirely — the delivery record and the eventual settlement, confirmed to agree on quantity before the price and deductions are even considered.
Tracking a dockage rate over time
A single settlement's dockage percentage is just one number. A season's worth, or several seasons' worth, laid out in one register, can reveal a trend that's invisible one statement at a time — a dockage rate that creeps upward gradually, or one that spikes noticeably after a wet harvest. Neither is necessarily a problem, but both are the kind of pattern worth noticing and, if it seems off, worth a conversation with the elevator armed with the actual numbers rather than a general impression.
Keeping up during harvest itself
Harvest is exactly the period with the least spare time and the highest volume of settlement statements arriving — several a week isn't unusual for a larger operation moving grain to more than one buyer. Falling behind during that stretch is normal, and the register doesn't require real-time upkeep to be useful — a backlog of statements uploaded in one batch once the harvest rush eases builds the same complete register as processing each one the day it arrives.
Tracking open forward contracts against delivered settlements
An operation that forward-contracts part of a crop ahead of harvest is carrying an obligation — a promised quantity at a set price — that isn't itself a settlement statement, but that every actual delivery against it should eventually satisfy. Keeping the register alongside a simple list of open contracts makes it possible to see, at a glance, how much of a forward-sold position has actually been delivered against so far, and how much is still outstanding as harvest continues.
That visibility matters most late in a harvest, when the pressure to fill a remaining contract obligation before a deadline is real, and a clear register of what's already settled against it is more useful than trying to recall the running total from memory.
Privacy
Uploads go over TLS, encrypted end to end.
Processing runs on EU-hosted infrastructure.
Original documents are deleted immediately after extraction.
Pricing and sales data are never used to train AI models.
Full details are on the security page.