Stock FAQs

Not a fully automatic send-to-supplier order, but predictive ordering calculates what you need based on your most recent stock count versus your set par level and recent sales, with an optional buffer. It produces an order list you can process through Loaded or use manually against your supplier.

Yes — ordering through the platform is optional. What matters is receiving the invoice into Loaded, which updates your stock on hand and live cost-of-goods pricing regardless of how you placed the order. Plenty of customers order via portal, phone or email and just receive invoices into Loaded; others order through the platform to control what staff can order.

Yes — you can enter counts directly in Loaded, print the stocktake sheet, or export it in a format that suits your process.

Your first stocktake after go-live is treated as an opening count, not a variance report, since there's no prior Loaded count to compare against. The recommended approach is to finish your last stocktake in your old system first (for a proper variance report there), then enter that completed count into Loaded as your opening balance — so your next stocktake in Loaded generates a real variance report.

Yes — the unit you receive an item in (invoice), the stock unit it's held in, and the unit used in the recipe all need to be consistent (weight-to-weight, volume-to-volume, or count-to-count). Mismatches are usually why cost-of-goods figures come out wrong or blank.

If your team uses it interchangeably behind the bar or in the kitchen, it should be one stock item. Loaded's stock costing works off whether the product gets used the same way regardless of brand — if yes (milk, gloves, cling film), keep it as a single item and let the average cost absorb small price swings between suppliers. Only split it into two items when a specific brand is genuinely non-negotiable for a recipe. Splitting everything by brand "just in case" is the single biggest cause of a bloated, hard-to-maintain stock list.

Create a single "incorrect item" stock item and link any of these one-off or wrongly-shipped lines to it instead of creating a new real stock item every time. This keeps your genuine stock list clean and stops your reporting from being cluttered with items you'll never order again. When the item is returned or corrected, raise a credit note against that same "incorrect item" so it nets out cleanly.

This almost always means the unit you're receiving the product in doesn't match the unit you're counting it in. A classic example: wine gets received as a 750ml bottle but is set up to be counted as "each," or fresh herbs are ordered by the "bunch" — a unit with no fixed weight — so Loaded has nothing consistent to convert against. The fix is to make sure your counting unit and your ordering/receiving unit are the same real-world measure. It's rarely a small error either — a mismatched unit typically throws the cost out by a large, obvious margin, which makes it easy to spot once you know what to look for.

Set the item up by its actual unit — for example, "12 x 750ml" — rather than as a generic "12-pack," and keep the volume (750ml) as the underlying measure. That way the same stock item can be decremented correctly whether you're selling a full bottle or pouring a 150ml glass, and your invoice AI can keep matching future deliveries automatically because the unit stays consistent.

It's your most recent invoice price, not a rolling average. That makes it a genuinely useful early-warning tool: sort your stock item list by live price and anything that jumps out is almost always a units or data-entry error on the last invoice received, not a real price change. Run this check regularly rather than waiting for your next stock take to catch it.

It's a costing tool for planning ahead, not a record of current spend. Use it when you want to cost a recipe using a price you expect to pay in future rather than what you're paying right now — for example, costing a summer salad in winter using an estimated in-season tomato price, so your menu pricing decision reflects reality rather than an inflated off-season cost.

You've got two options. The precise option is to break the parent button into individual flavour buttons, each linked to its own stock item, but that's more setup work than most venues find worthwhile. The simpler, still-reliable option is to receipt all your post-mix syrup as one combined stock item linked to the single POS button — you'll get a bit of flavour-level variance noise, but your overall cost of goods and usage reporting will still be accurate, and stock takes stay much faster.

Set the other business up as a "supplier" in Loaded, then raise a purchase order to them for the stock you're sending, with the quantity entered and the price set to zero. This deducts the stock from your on-hand count properly — so your stock take and cost of goods stay accurate — without it appearing as a phantom sale or getting lost in your invoicing. You can still send the purchase order to them as a delivery record if you want the paper trail.

This happens when a new stock take is created from scratch instead of pulling from your saved System Template. Recipe-linked ingredients only populate correctly when your stock take areas are built inside the System Template — go to the template, scroll to the bottom, and add each area (bar, dry store, walk-in, etc.) there. Once that's done, every future stock take you create from that template will automatically include both what you've counted by area and what's tied up in recipes.

No — there's nothing to compare it against yet, so your first stock take won't produce a meaningful variance figure. What it will give you immediately is an accurate stock-on-hand dollar value, which becomes the baseline every future stock take is measured against.

Both can be correct at once, and the mismatch is usually caused by one specific invoice or pack size being mapped incorrectly rather than an actual pricing problem. A common culprit is a case size (say, a 24-pack) getting linked as if it were a single unit, which spikes the cost of goods on the day that invoice was received but gets diluted out once you average across a full month. Check the item's recent invoice history and unit setup for the specific day in question before assuming your margins have genuinely moved.

This means the button for that item on your POS hasn't been linked to its recipe in Loaded yet — until that link exists, Loaded has sales data from the POS but nothing to match it against for cost, so the item shows blank rather than wrong. Go into your POS item links, search for the unlinked product, and connect it to its recipe; once linked, cost of goods and margin data for that item will populate on your next report.

This is usually a sync issue rather than a setup mistake, and it's normally fixed by disconnecting and reconnecting the Xero integration from your Loaded account settings. Once reconnected, refresh the export screen and the new code should appear as an option.

For most venues, consolidating down to a small number of generic Xero codes (food purchases, beverage purchases, freight, general/other) works better once Loaded is your day-to-day system. The detailed breakdown already lives in Loaded's own reporting, so keeping the same granularity in Xero just adds manual coding work at export time without adding new insight. The practical benefit of consolidating is being able to bulk-export a whole batch of invoices in one go.

No — the Xero integration only pushes data one way, from Loaded into Xero, and never reads back what already exists in Xero. It will only flag a duplicate if that exact invoice originated in Loaded and you try to export it twice. For any supplier whose invoices already flow into Xero automatically or that you enter there yourself, still receipt them in Loaded so your stock levels and pricing stay current, but don't also push them across to Xero.

This error means the GL/account code you're trying to export against in Xero has its tax rate configured as a revenue or non-expense account type, when it needs to be set as an expense or cost-of-sales type to accept a purchase. Check the specific account code in Xero's chart of accounts and confirm its tax rate is assigned to an expense or cost-of-sales account — your accountant may need to make this change if the code was set up for a different purpose.