-I'd suggest a common pricing unit---record PricePerOunce for ingredients
I do this on the Add Ingredient Form. She puts in the pounds and/or ounces and cost for items and it auto calculates the ounces and then the cost per ounce.
But
you are storing Pounds and Ounces in the Ingredient table???
Also, for basic database/application design:
Get a 30,000 ft overview description of the business. Build a conceptual model -even if only black boxes for the major things involved. Keep it high level, but account for all the major pieces. Map out where the pieces fit and relate to one another.
Even if "Financials" (Invoices, Payments....) are not the immediate goal/priority, get them into the big picture, --you'll know where they fit (if when) you get to that part in future. You may end up with multiple Suppliers, just put the black box and linkages in the high level model.
For your own benefit, rethink the LineItem record and table. My experience indicates that storing the Unit cost/price and the quantity of units in the record is a good practice -which shows the quantity of units used/sold and the cost per unit in the transaction -- that is, the facts related to that line item are a permanent record. If you rely on the Cost/Price in the Ingredient table ( or Product table generally) you will lose the ability to reprint an Invoice and other things.
Audit and accounting may not be the current focus, but put the required black boxes into your conceptual model now, and it will save the re-analysis, redevelopment effort in the future. I've seen many examples of "jeez I wish I had thought of that before...." and "..damn they keep changing the specs.."
More info on Conceptual Data model
Good luck with your project.