Grain delivery reconciliation starts from a very ordinary moment: harvest is running, three elevators send their intake reports in three different layouts, a scanned weighing slip arrives from a fourth, and a farmer emails to ask why he has not been paid yet. Someone has to match every truck to a contract, check the grade, correct the weight and work out what is owed. For a grain trader in Lithuania, we built an assistant that reads those documents and hands the matching, grading and settlement maths to code. People only look at the deliveries that were flagged.
The problem: grain delivery reconciliation by hand
None of it is difficult, but there is a lot of it, it comes in every format, and a small slip becomes a payment error. The usual pain points:
- Every elevator has its own format. One sends kilograms, another tonnes. Contract numbers show up in full, shortened, or not at all.
- The grade has to be worked out again. The contract says Grade I wheat or malting barley. The lab says protein 12.1 % or falling number 168 s. Each value has to be compared with the quality requirements.
- Settlement weight is not net weight. Moisture and impurities above the base levels reduce the weight that gets paid for, drying costs come off the price, and rapeseed earns a premium or a discount for its oil content.
- Quantities run over the contract. Part of a contract may be fixed-price and part still unfixed. There is a ±5 % tolerance band, and anything beyond it needs a decision.
- The same truck arrives twice. The farmer’s email repeats slips the elevator has already reported, sometimes with a different weight.
What we built
The assistant takes the documents as they come and turns them into one checked list of deliveries:
- Reading. The model reads Excel reports in different layouts, a scanned weighing and quality slip, and a farmer’s email. It pulls out each delivery (slip number, date, seller, contract, gross, tare and net weight, quality indicators) and quotes the line it took each one from. Where a report has no contract number, it may suggest one, always marked for a person to confirm.
- Contract and grade. Code finds the contract in the register and checks that seller, crop, intake point and delivery period all match. It then sets the grade from the buyer’s published quality requirements, starting at the contracted grade and moving down. Nine grade definitions cover wheat, barley, triticale and rapeseed.
- Weight and price. Code calculates settlement weight (net weight corrected for moisture above 14 %, or 9 % for rapeseed, and for impurities above 2 %). It applies the price difference between grades, a drying charge per point of moisture and the oil content premium for rapeseed.
- Quantity allocation. Deliveries are added to each contract in date order. Every tonne lands in the fixed-price part, the unfixed part, the ±5 % tolerance band or the overrun.
- Flags. Code marks duplicates, gross minus tare that does not equal net, late deliveries, deliveries with no matching contract, rapeseed from a farmer whose ISCC sustainability self-declaration is missing, lower grades and overruns. There are 19 flag types, each with a level: stop, review or information.
- Summary and reply. All deliveries end up in one table that exports to CSV for Excel. When a farmer has written in, code drafts the reply from the reconciled figures. A person edits it and sends it.
A few cases from the test pack (4 documents, 22 deliveries, 12 contracts, all fictional). A truck on a Grade III wheat contract had a falling number of 168 s, so the code moved it to Grade IV (feed) and took 36 €/t off the price. A rapeseed slip showed 24,260 kg net at 10.2 % moisture and 2.6 % impurities. That became 23,794 kg of settlement weight, with a 4.65 % oil premium for 43.1 % oil content and a drying charge. The farmer’s email claimed a slip at 24,980 kg that the elevator had reported at 24,760 kg. The code flagged it as a duplicate with a 220 kg difference and used the elevator weight. The model extracted every field of all 22 deliveries correctly against the answer key. A suite of 586 automated checks covers the rules, the extraction and the outcomes, without calling the model.
What changes for the purchasing team
| Before | With grain delivery reconciliation | |
|---|---|---|
| Input formats | Each elevator’s layout is retyped or reformatted by hand | Excel reports, scanned slips and emails are read as they arrive, each value with its source line |
| Grade | Lab values compared with the requirements by eye | Code checks every indicator against the grade requirements and names the one that failed |
| Settlement weight and price | Moisture, impurities, drying and oil premium worked out in a spreadsheet | Same formula for every truck, with each correction shown |
| Contract quantity | Running totals kept per contract, overruns found late | Every tonne allocated to fixed, unfixed, tolerance or overrun as it arrives |
| Duplicates and errors | Caught only if someone remembers the slip number | Duplicates, gross − tare ≠ net, late and contract-less deliveries are flagged before payment |
| Reply to the farmer | Written from scratch after digging through the reports | A draft built from the reconciled figures, ready to check and send |
Where people stay in control
The model has one job: read the document, extract the values and quote where it found them. It decides nothing. Matching contracts, grading, weight corrections, prices, quantity allocation and every flag are done by plain, testable code following written rules. Nothing goes for payment automatically. In the test pack, 11 of the 20 distinct deliveries came through clean, 7 were marked for review, and 4 lines were stopped: two duplicates from the farmer’s email, one weight arithmetic error and one delivery with no contract. The farmer reply is drafted by code and sent by a person.
The limit is honest too: the grade requirements come from the buyer’s public quality table, but the settlement terms in this build (base moisture, drying charge, price differences between grades, oil premium and tolerance) are sample values following common market practice. Before real use they must be replaced with the trader’s own contract terms and checked against already settled deliveries.
Where else this works
The same pattern fits anywhere deliveries are paid on measured quality:
- Feed and oilseed processing: intake slips checked against supply contracts, with protein, oil or moisture adjustments.
- Timber and biomass: weighbridge tickets and moisture readings reconciled against volume contracts and price bands.
- Dairy and fresh produce: collection records and lab results turned into supplier settlements with quality premiums and penalties.
Related use cases: Supplier invoice reconciliation with AI · KYB document check automation · Insurance policy document extraction. All Document checks & reconciliation use cases · How we deliver this: Custom AI solutions
FAQ
How do you calculate settlement weight for grain?
Settlement weight is net weight corrected for moisture and impurities above the base levels. In this build, net weight is multiplied by (100 − moisture) / (100 − base moisture) when moisture is above 14 % (9 % for rapeseed), and by (100 − impurities) / (100 − 2) when impurities are above 2 %.
Can AI read elevator reports in different Excel formats and scanned weighing slips?
Yes. The model reads Excel reports with different columns and units, scanned weighing and quality slips and farmers’ emails, and quotes the line each value came from. In our test pack it extracted every field of all 22 deliveries correctly.
Does the system approve grain payments automatically?
No. Code grades each delivery, calculates the price and flags duplicates, weight errors, late or contract-less deliveries, overruns and missing ISCC declarations. Nothing is paid without a human decision.
How many hours does your team spend matching elevator reports to contracts each harvest? Talk to us