Fees and landed cost

The sticker price of a jar is not what the jar costs you. Add €30 of shipping to a €100 order and everything in the box just got 30% dearer. BatchDash treats those fees as part of the cost rather than letting them vanish into overhead.

Fee types

On the order page, the Fees & shipping card takes five kinds of fees:

• Delivery / shipping
• Payment fee (card or transfer charges)
• Platform fee (marketplace commission)
• Other, with a free label for anything else
• Rounding on the invoice, the few cents between an invoice’s lines and its total, plus or minus

Click Edit on the card, enter the amounts and save.

The same dialog carries the VAT the document printed, if it printed any. That figure is not a fee: it changes what the goods cost only when your business recovers it. VAT on what you buy has the whole rule.

How fees spread across lines

Fees are split across lines in proportion to line value, then folded into each line’s cost.

An example. An order carries €200 of habaneros and €100 of jars, plus €30 of delivery. The habanero line absorbs €20 of it, the jar line €10. Each line shows the result in two columns: Allocated fees (its share) and Effective cost (the unit price with fees folded in).

That effective cost is the line’s landed cost: what the goods actually cost you once they reached your door. The concept has its own article: landed cost.

The divisor is what the line actually bought: the ordered quantity while the line is still open, and what arrived once it was closed short or came in over. A delivery fee the vendor charged in full over a crate that came half empty belongs on the half that came.

So: you order 20 kg, the vendor charges €15 to deliver it, and 12 kg turn up. While the rest is still expected the fee rides on the 20, at €0.75 a kilo. Close the rest and the same €15 sits on the 12 that came, at €1.25, and the ingredient’s ledger gains a line under that delivery: “Cost restated €1.20 → €1.70: fees re-spread after the line closed short.” The average cost moves with it, and the row says who moved it.

Where it ends up

Nothing moves while the order is a draft. When a line is received, its effective cost enters the ingredient’s weighted average cost, and from there every formula that uses the ingredient. Skip the fees and your recipes look cheaper than they are. Enter them and the margin you read is the margin you get.

A fee the app fills in

A draft created from Buying arrives with its delivery fee already set, from the vendor’s delivery terms, and the fees card says so: “Delivery · from the vendor’s terms”. It is a prediction, not an invoice, and the note is there so it never passes for one.

Save the fees and the note goes, whatever figure you save. Even typing back exactly what was prefilled counts: you have looked at it and agreed, and from then on the number is yours.

Fees that arrive after the goods

The invoice with the real delivery fee usually lands after the crates do, so the Fees card stays editable on a received order. Saving it re-costs every delivery already booked against that order, replays each ingredient’s average cost, and leaves a line under the delivery row in the ledger saying what changed and why. Your average cost catches up instead of staying quietly wrong.

VAT on what you buy

The same dialog carries the VAT the document printed, if it printed any, and what it does to your cost depends on one switch. VAT on what you buy has the whole rule: the switch, the four fields, the worked example, more than one rate on an invoice, and what the reader does with a tax line.

More than one rate on the invoice

Most wholesalers put food at one rate and everything else at another, on the same receipt: chili at 5.5%, jars and carriage at 20%. The amount stays one figure, because that is what the paper prints; the rates say whose it is. Type the document’s rate in the VAT row, the charges’ rate beside it, and the rate of any line that differs on the line itself: Edit on the line while the order is open, or VAT rate in the line’s ⋮ menu once it has arrived, since the invoice usually lands after the crates. A line at another rate says so on its row: “VAT 20%”.

Each line then carries the tax it was actually charged. Without the rates the amount spreads by line value, which is right on a single-rate document and a few percent out per line on a mixed one: on €100 of chili at 5.5% beside €100 of jars at 20%, the chili reads about 6% cheap and the jars 6% dear. The order’s total is the same either way.

The dialog checks the rates against the amount as you type: “The rates come to €27.50.”, in amber when that is not the amount in the box. A line’s rate is set away from that dialog, so the card repeats the sentence whenever the rates stored on the order do not come to its amount. That is usually a rate typed wrong, or a line still waiting for its own.

Empty the amount and save, and the entry is gone: its rates go with it, the lines’ own included.

Every money box on an order line, a delivery and a reading has a word under it saying which column of the invoice to copy: before VAT when your business recovers VAT, incl. VAT when it does not. Once the order or the reading holds a VAT amount, its own switch decides instead, because the lines have to be what the paper prints: incl. VAT when the prices include it, before VAT when it is added on top.

When the paperwork reader finds a tax line on a document, it fills this row for you and works out from the printed total whether the prices contained the VAT. It reads the rates too, when the document prints a rate column or a code per line.

The row stays editable on a received order, like the fees beside it. Saving a change re-costs every delivery booked against the order and leaves a line under each one in the ledger: “Cost restated €10.81 → €10.00 after the VAT entry changed.”