Why QuickBooks alone breaks: lots, expiry, and multiple units
Where an accounting-only stack stops fitting a food operation — what QuickBooks is genuinely built for, the three edges it can't cross, and how to decide what should own the plant versus the books without turning your team into the glue between them.
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
After this lesson you can draw a clean line through your own stack: name what QuickBooks was built to do well, name the few food-specific jobs it was never built for, and decide — on purpose — what should own the plant and what should keep the books. This isn't a case against QuickBooks, and it recommends no replacement. It's about seeing where one tool's lane ends so you stop paying for the gap by hand.
What QuickBooks is actually built for
QuickBooks is accounting software, and inside that lane it's very good. It keeps your books: invoices and bills, accounts receivable and payable, payroll, sales tax, and the financial statements your bank and your accountant want to see. Its inventory features can tell you how many of an item you have on hand and what that stock is worth. For the money side of a growing food business, it earns its place.
So this lesson isn't a complaint about the tool. The trouble a manufacturer runs into is never that QuickBooks is bad at accounting. It's that food operations quietly ask it to do a second job — run the plant — that no accounting package was designed for. Once you can see exactly where that second job begins, the fix stops being "get rid of QuickBooks" and becomes "stop asking it to be something it isn't."
Where the accounting lane ends
Three edges show up again and again. None of them is a flaw in the software. Each is simply a place where the shape of accounting and the shape of food manufacturing stop lining up.
Lots and expiry don't live on an invoice
An invoice records a sale: who bought what, for how much, and when. What it does not record is which specific lot left your dock, or when that lot expires. In QuickBooks Online there's no native field for a lot number or an expiration date — not on your items and not on the invoice that ships them.
That matters because traceability isn't a number in a box; it's a chain. Real links backward to the supplier lot an ingredient came from and forward to every finished lot and every customer it reached. An accounting system keeps a history of money moving. Genealogy is a different history — of physical goods becoming other goods — and the books were never built to hold it. The day a customer names a suspect lot, an invoice list tells you who you sold to, not which lot they got.
QuickBooks Desktop Enterprise is a partial exception — confirm it at the source
QuickBooks Desktop Enterprise's higher tiers (Platinum and Diamond) can track lot
numbers and expiration dates when you turn on the Advanced Inventory add-on — though
you choose either serial numbers or lot numbers, not both, and it's still an inventory
attribute bolted onto the books rather than batch genealogy. Feature sets and tiers
change; confirm the current list on Intuit's own help pages before you rely on it.
Checked against Intuit's help documentation in July 2026.
Buying, making, and selling in different units
Food moves through your operation in more than one unit. You buy peppers by the bag, pull them by the pound, and ship finished sauce by the case of twelve jars. Handling that cleanly takes the system can convert on its own.
QuickBooks Online has no units-of-measure feature at all — the common workaround is to create a separate item for every unit, which multiplies your item list and scatters the truth about one physical thing across several records. (Desktop Premier and Enterprise do carry a units-of-measure feature; QuickBooks Online does not, as of July 2026.) When the tool can't convert a bag to a pound to a case, your people do it, in their heads or in a side sheet, every time they receive, consume, or sell. That's exactly where counts drift and where a batch's real cost gets fuzzy — which is why getting units of measure right is a job that belongs to whatever owns the plant, not to a person with a calculator.
It doesn't run production
The deepest edge is production itself. Making food is a physical event: a recipe, or , consumes specific input lots and yields a finished lot with its own code, its own expiry, and its own cost built from what actually went in. Around that event live the rules food runs on — and a that actually stops a batch from moving.
Accounting has no concept of any of that. It records the financial result of production, not the event — so a batch, its genealogy, its expiry logic, and its holds have to live somewhere else. This is the edge that turns "we use QuickBooks" into "we use QuickBooks plus six spreadsheets."
The pattern most operations land on
Once those three edges are clear, the sensible arrangement almost designs itself, and most growing manufacturers arrive at the same one: let each tool own the job it's built for. An operations system owns the plant — lots, batches, expiry, FEFO, QA holds, production, and the true cost of a batch — and it hands the books the summaries they need: what to invoice, what a batch cost, what your inventory is worth. QuickBooks keeps doing what it's good at, on clean numbers it didn't have to reconstruct.
The point of the split is that neither tool reaches outside its lane. The plant side holds the physical truth — which lot, which batch, what expires when. The books hold the financial truth. Bettr Manager is one operations system built around this idea — purchasing, receiving, inventory, production, and lot traceability in one place — and it's one of several that fit the shape; which one you'd pick isn't the point of this lesson. The point is the arrangement itself: a thin, well-defined handoff carries summaries from the plant to the books, and no important number has to be kept in two heads at once.
When the team becomes the integration layer
There's a failure mode that this split is meant to avoid, and it's worth naming because so many operations are living in it. When no single system owns the plant, the connective work doesn't disappear — it lands on people. Someone types a receiving into a spreadsheet, again into QuickBooks, and a third time into a lots tab. Someone reconciles the three when they disagree. Operators have a plain description for what the crew quietly becomes at that point: the integration layer — the humans who copy numbers between tools and settle the differences by hand.
It's expensive in a way that hides. The person doing it is usually your most capable one, spending hours moving data instead of making product, and the whole arrangement holds only until they're out sick or move on. Piling on more point tools doesn't fix it — every new app is one more place the same number has to be entered, which is why operators talk about "app fatigue." The goal was never more software. It's fewer places a single number lives, so the team stops being the glue.
Drawing your own line
You don't need to choose a system today to do the useful thing, which is to draw the line clearly for your own operation. Put every job you do on one of two sides. The plant side owns the physical world: receiving and lots, batch production, expiry and FEFO, QA holds, and what a batch truly costs. The books side owns the money: invoices, bills, payroll, tax, and financial statements.
Then look at the jobs currently sitting on the wrong side — the lots you keep in a QuickBooks custom field, the expiry you track in a side sheet, the unit conversions you do by hand — and note where each one belongs. Finally, name the handoff itself: exactly what the books need from the plant (what to invoice, what a batch cost, what stock is worth) and how that information moves today. That seam, kept thin and deliberate, is the difference between two tools cooperating and a person standing between them.
Where this leaves you
You can now say plainly what your QuickBooks is for, what falls outside its lane, and roughly how the plant and the books should hand off to each other. That's a real decision made on purpose, instead of a stack that grew by accident one spreadsheet at a time.
The natural next question is the one this whole course has been walking toward: if something other than a spreadsheet should own the plant, how do you actually choose it without buying a system that's too heavy or too thin? That's where the course turns next — from naming the wall to picking your way over it.
