How it's calculated

Net profit = revenue, minus refunds, marketplace fees, advertising, shipping, cost of goods and other costs. Every profit figure on every screen is that one calculation.

Revenue excludes marketplace-collected sales tax, because that is the buyer's money passing through to the state. Refunds are attributed to the month the ORDER was placed, not the month the refund was processed, so a return is netted against the sale it reverses.

That has a consequence worth knowing before you see it: a month keeps changing after it ends, and the current month always looks more profitable than it will end up, because its returns have not happened yet. Compare a finished month with another finished month.

Posted fees remain the default reporting basis. In FBA inbound costs, save an allocation backed by matching shipment, inventory and native sales records. In Reports, choose Match inbound cost to sales and select the saved allocations. Only their verified freight moves from its posted expense to the original sale months; product costs and other charges keep their existing treatment.

For a verified shipment of 100 identical units with $100 freight, selling 10 units recognizes $10 and retains $90 against the remaining inventory. Posted credits reduce the freight pool. The report shows the expense adjustment and inventory-held amount, and its CSV and PDF use the same selection. If source records change, recalculate the allocation before using it again.

Amazon: item proceeds and buyer shipping from the Orders API; referral and FBA fees plus the settlement report; returned units from the Finances feed.

eBay: order totals from the Fulfilment API, tax-exclusive; final value and fixed fees per order.

Walmart: product charges from the Orders API; commission and item fees; returns from the Returns API.

Shopify: gross line-item revenue from the GraphQL Admin API; per-line order refunds. Shopify Payments fees are captured from each order's transactions; fees charged by other payment gateways are not exposed by the API, and the profit report shows them as absent rather than inventing a number.

Two numbers, deliberately. Gross units is what left the shelf; net units subtracts what came back. Purchasing reads one and performance reads the other, and collapsing them into a single figure would make one of the two wrong.

Everything is on your warehouse clock. Data is stored in UTC and every report, every schedule and every month boundary is converted to your warehouse timezone, so an order placed at 11pm on the 30th falls in that month, not the next one.

Each night, every SKU's sales history is fitted with several forecasting models at once — a naive baseline, a model built for intermittent demand, and statistical models that pick up trend and seasonality — and the one that fits that SKU's own history best is used, with a preference for the simpler model when two fit equally well.

A SKU without enough history gets the simpler candidates only. Nothing is forecast from a number of data points too small to support it.

When to reorder and how much are two different questions, and they read different inputs on purpose.

The trigger counts only stock that can actually be sold inside the cover window: units landing after it do not make a SKU look covered, because a stockout nobody saw coming is the expensive failure.

The quantity subtracts everything already coming — in production, sailing, and arrived — because re-ordering goods you have already paid for is the other expensive failure. The two answers are deliberately not the same arithmetic.

Each marketplace is polled on its own schedule into a per-channel ledger of orders, fees and refunds. Your fulfilment platform is polled for products, stock and label costs. Settlement checks compare available payout files with the ledger and report unresolved differences; a source feed alone does not prove that a period is complete.

The nightly cycle then forecasts demand, recomputes reorder points and emails the day's purchasing list. Nothing is written back to a marketplace, and every job records whether it ran, so a silent failure shows up on the system-health page rather than as yesterday's numbers looking like today's.

Only applies where a VAT registration is set up. Without one, nothing here changes any number you see.

The VAT you charge was never your income — you collected it for HMRC. So a £120 sale at the UK standard rate enters revenue as £100, and the £20 is reported separately. We use the VAT figure the marketplace actually states wherever it gives one, rather than recomputing it. Where we have to derive it, we use HMRC's VAT fraction — one sixth of the gross at the standard rate — not the rate applied to the gross, which would overstate the VAT and understate what you earned.

VAT is never a cost line. It appears nowhere in the profit formula: it already left through revenue, and subtracting it again would count the same money twice.

Where a marketplace takes VAT but never says who owes it to HMRC, it goes in its own line rather than the main VAT figure — guessing invents a debt or erases a real one, and some marketplaces genuinely never state it.

These figures are not a VAT return. The VAT lines are not reduced by refunds, so the memorandum overstates the VAT owed by whatever was refunded, and we have not yet checked them against a real accountant's. Reconcile one month with yours before relying on them.