You already sold those jars. Twice.

A shop orders thirty jars for Friday. The promise lives in a text message, the jars sit on the shelf looking available, and the Saturday market sells twelve of them again. You find out on packing day, with the box already open.

BatchDash writes the promise down as a sales order. Confirming holds the stock against the shelf, shipping draws the actual batches, and the ledger keeps who bought what, on which day, at which price.

Request access Sign in

01Sales orders

One document, from the phone call to the box

The whole order sits on one screen, in the order you would say it out loud. Who it is for and on what terms, the day it has to leave, the line in the product’s own unit at the price you agreed, and the buyer’s own instruction on the line where the person packing will read it. Under the header comes the state: one line, nothing shipped, and the shelf eight jars below the thirty that were promised. Discount and shipping are written as amounts, so the total adds up in front of the buyer. The address is copied onto the order as written, and editing the customer next year never rewrites what shipped this year.

A confirmed sales order in BatchDash: the customer and their trade terms, the ship-by date, a line short of stock with the shortfall recorded as demand, the totals, the unpaid state and the ship-to address.

02Sales orders

Confirming makes the shelf tell the truth

From Confirm until each line ships, the order’s quantities count as reserved on their products. Reserved is computed from the open orders every time it is shown and never stored, so it cannot drift away from what is actually promised.

The product page reads "30 reserved for 1 sales order", and the link opens the orders holding them.
Confirming past what you have is allowed. The missing eight jars become demand, which is the number that sizes your next batch on the planner.
A batch on hold, waiting for its release check, is never counted as reserved and never ships. The release gate wins over the promise.

03Sales orders

Shipping is a ledger entry

Ship a line and name the batches going in the box, or name none and the released stock closest to its date goes first, which is what most Fridays want. Batches on hold are listed and grayed out instead of hidden, because you can see those jars on the shelf and leaving them out would read as a bug. The shelf it leaves from is a field, so a lot in the van is never confused with a lot in the fridge. The movement books at your weighted average cost, with the line’s price and the order’s reference on the row, so margin per product is read off sales that actually happened.

The ship dialog in BatchDash: the shelf it leaves from, the released batches with their expiry dates and balances, and the box to mark the order paid at the same time.

04Sales orders

And then, whether they have paid

Paid is a flag with a date on it, kept apart from where the order stands, because a shipped order can go unpaid for a month and a deposit can land before anything leaves. Mark it from the totals block, where the amount is, or tick the box in the ship dialog when the parcel and the money change hands together. The list has an Unpaid filter, which on a Monday morning is the only screen you want.

05Sales orders

A sale with no name gets the same document

Leave the customer empty and you get a walk-in order: the same lines, the same reservation, the same lot draw, filed under its own reference. Market stalls and door sales stop being the part of the business nobody can reconstruct in January.

Recording a sale straight off a product page stays exactly as it is, under "Record what leaves". An order writes down a promise; that one writes down something that already happened. Both land on the same ledger.

06Sales orders

Afterwards, the customer file holds it

Every customer page carries what you know about them: how to reach them, how they buy, what they have spent with you, and the standing instruction somebody wrote down once so nobody has to remember it. Below that sits every order they have placed, with how much of each one shipped and whether it was paid. Writing the next one, the price fills itself in: the trade price for a customer on wholesale terms, with the last price you actually agreed one tap underneath. Returns are one action on a shipped line, back into stock on the batch it left from or written off.

A customer page in BatchDash: their trade terms, contact details, order count and revenue, the standing delivery instruction, the shipping address, and every order placed with its shipped-lines counter, paid badge and status.

Works with

StockA ledger every figure walks back to TraceabilityAny lot, forward or back, in minutes CostingReal prices, margins that stay true

Sales ordersIn the help center