FarmBooks — Photograph a Bill, Get Schedule-F-Ready Books
Two independent reads of every bill — OCR and vision — have to agree on each section's total, or a human sees the disagreement instead of a silently dropped line.
A farm bookkeeper retyping every co-op and dealer bill by hand.
Farm bookkeeping runs on paper that doesn't cooperate: co-op grain tickets, dealer parts invoices, chemical and seed bills, fuel statements, each with its own layout, and each one needing to be split across fields, entities, and IRS Schedule F categories before it means anything at tax time. The default tool is a spreadsheet and a bookkeeper retyping every line by hand.
That retyping is where lines get missed. A bill with several sections and subtotals is easy to mis-key or drop a line from, and nothing catches it until the books don't reconcile — usually months later, at tax time, when tracing the error back to its source bill is its own project.
Two independent reads of every bill, checked against each other before anything posts.
FarmBooks starts with a photo or an upload. The bill goes through a layout/OCR extraction pass and a separate vision read at the same time, co-equally — neither is treated as the fallback for the other. Vendor detection, line-item extraction, and allocation to the right farm field and entity follow, then IRS Schedule F categorization, then a review queue for anything the system isn't confident about.
The two reads are required to independently agree on each section's printed total. When they don't, the discrepancy surfaces for a human instead of a line silently vanishing into the ledger — in testing, the vision read recovered a $92.57 line that OCR alone had dropped. Handwritten bills skip auto-posting entirely and always land in the review queue. When a bookkeeper corrects a field or category assignment, that correction becomes a durable alias, so the same vendor resolves itself automatically the next time it shows up.
Every bill also gets a plain-English one-line summary, and the equipment roster is inferred from VIN and serial numbers found on repair bills rather than asked for up front. One login covers multiple farms, each scoped to its own learning, so a correction on one farm doesn't bleed into another's aliases. Output is a formula-driven .xlsx — a Month Summary and a Ledger tab with live SUMIF rollups — with two-way sync to a real SharePoint workbook, where a human's edit always wins over an engine write.
How a bill moves from photo to posted ledger.
Upload or photograph a bill; OCR/layout extraction and a separate vision read run co-equally
The two reads must independently agree on each section's total, or the discrepancy surfaces for review
Vendor detection, line-item extraction, and allocation to farm field and entity
IRS Schedule F categorization, with a review queue for anything uncertain
Handwritten bills always route to human review — never auto-posted
Bookkeeper corrections become durable aliases so the same vendor resolves itself next time
Plain-English one-line summary generated for every bill
Equipment roster inferred from VIN/serial numbers found on repair bills
One login, multiple farms, each scoped to its own learning
Extraction and reconciliation
- OCR/layout extraction pass and an independent vision pass, co-equal
- Cross-check on each section's total before anything posts
- Discrepancies surface to a human review queue instead of dropping silently
- Vendor code aliasing learned from bookkeeper corrections
Output and sync
- Formula-driven .xlsx: Month Summary and Ledger tabs with live SUMIF rollups
- Two-way sync to a live SharePoint workbook
- Human edits in the workbook always win over engine writes
- Python FastAPI extraction engine on Azure Container Apps with Cosmos DB
- Next.js 15 / React 19 PWA on Cloudflare Workers
Outcomes the engagement actually produced.
Neither read is a fallback for the other — both have to agree on each section's total before a bill is trusted.
In testing, OCR alone dropped a line that the independent vision read caught, which is the failure mode the cross-check exists to catch.
1,069 Python engine tests collected and 505 web tests passing across 59 files, run against a corpus of 23 photographed real bills.
No handwritten bill is ever auto-posted — it always routes to the review queue.
Buried in farm bills at tax time?
Preisser Solutions builds document-extraction systems that check their own work before anything posts. Scoping begins with a conversation about your bills and your books.
