Caltru

Guide

WooCommerce profit reports: what the built-in analytics shows and what it misses

What a WooCommerce profit report needs: what built-in Analytics shows, what it leaves out, and a checklist for profit figures you can trust.

Updated

Most WooCommerce shops can say what they sold last month in a few clicks. Far fewer can say which products made money, and by how much. The difference is not a missing chart. It is a set of decisions about costs, dates and gaps that a sales report never has to make. This guide covers what WooCommerce’s own reporting gives you, what it leaves out, and how to judge any profit report, including one you build yourself.

What WooCommerce Analytics shows

WooCommerce Analytics is a sales reporting tool, and a capable one. The reports most relevant to profit are:

  • Revenue: gross sales, returns, coupons, net sales, taxes, shipping and total sales, by day, week or month.
  • Products and Variations: items sold, net sales and number of orders per product, with category and stock status.
  • Categories: the same sales figures grouped by product category.
  • Orders: individual orders with their totals and statuses.

Every one of those figures describes money coming in. None describes what it cost you to earn it.

What it misses

Cost and profit

Recent WooCommerce versions have a built-in Cost of Goods Sold field, and the order screen shows each line’s cost and an order cost total. But WooCommerce’s COGS documentation states that the feature does not integrate with Analytics. You can see the cost of one order at a time; there is no report that adds costs up into gross profit or margin by product, category or period.

Delivery and payment costs

WooCommerce records what the customer paid for delivery, not what the carrier charged you. Payment gateways rarely write their fee onto the order. So even with product costs entered, the two costs that come with every order are absent, and free-shipping orders look more profitable than they are.

Unpaid orders, by default

Analytics dates orders by a setting under Analytics → Settings, and the default is the date the order was paid. Orders without a paid date, typically bank transfer or cash on delivery until payment is recorded, are left out of the Revenue and Orders reports until then. That is a reasonable choice, but it means figures move as payments arrive, and a profit report built on a different date will not match it.

Per-product profit and per-order profit

The two views answer different questions, and a good report gives both.

Per-product profit asks which products earn their place: units sold, revenue, cost of goods, gross profit and margin. It is what you use to set prices, drop products and decide what to promote. Shipping and gateway fees belong to an order, not to any one product in it, so per-product figures are naturally gross profit, before those costs.

Per-order and per-period profit asks whether the business as a whole kept money. This is where carrier costs and gateway fees come off, and delivery charged to customers is added back, giving net profit for a day, a month or a year.

Mixing the two causes trouble. Spread a €6 parcel across three products in an order and you have invented an attribution nobody can check. Keep product figures at gross profit and subtract order-level costs once, at the total. The guide on calculating net profit walks through the sum.

Margin, read correctly

Margin is gross profit divided by revenue. Two habits keep it honest.

Compare margins in percentage points. A move from 50% to 60% is ten points. Reporting it as “margin up 20%” is arithmetically true and practically misleading.

Look at margin and profit together. A product with a 70% margin that sells twice a year matters less than one with 30% that sells daily. Sort by gross profit to see what pays the bills; sort by margin to see what is mispriced.

Refunds in the right month

A refund issued in May against an order from March can be booked in either month, and the choice changes what your reports say.

Booking it against March means March’s profit changes in May. Every report you exported for March is now wrong, and a quarter you closed is open again. Booking it in May, on the refund date, leaves March as it was and shows the refund when the money actually left.

Two further details separate a careful report from a rough one:

  • Return the cost only for what came back. If two of three units are returned, two units’ cost comes back to stock, not three.
  • Do not spread amount-only refunds. A goodwill refund with no product behind it should appear as its own line. Prorating it across the products in the order moves profit between products that had nothing to do with it.

Unknown costs

This is where most profit reports fail quietly. A product with no cost entered is usually treated as costing nothing, and in WooCommerce’s own field an unset cost defaults to zero. That product then shows a 100% margin. It can top the best-performers list while you know nothing about it.

A trustworthy report does three things with missing costs:

  1. Keeps their revenue out of profit, or at least labels it.
  2. Puts a figure on the size of the gap: how much revenue is standing on lines with no cost.
  3. Excludes uncosted products from “least profitable” lists, where they would otherwise rank for the wrong reason.

Costs added after a sale are a related problem. Applying today’s cost to an old order is a reasonable estimate, but it is an estimate, and a report should be able to show it with and without them.

A checklist for a profit report you can trust

  • Cost recorded at the time of sale. Changing a supplier price today must not change last month’s profit, and recalculating an old order must not re-cost it at today’s price.
  • Revenue excluding VAT, and costs on the same VAT basis.
  • Missing costs counted, not zeroed, with the revenue they affect shown as its own figure.
  • Estimated costs marked and excludable.
  • Refunds dated by the refund, returning cost only for units that came back, with amount-only refunds kept separate.
  • Carrier costs and gateway fees subtracted per order, including on free-shipping orders, and delivery charged to customers added back.
  • A clear accounting date, paid or created, applied consistently.
  • Comparisons with the previous period, with margin changes in percentage points.
  • Variations shown on their own or folded into the parent, as you choose.
  • Exports that match the screen, filters included, so a figure in a spreadsheet can be traced back.

If a report fails the first item, the rest matter less: its past figures will drift every time a cost changes.

How Caltru Ledger approaches it

Caltru Ledger is a free WooCommerce plugin built around that checklist. It records each order line’s cost at the moment of sale and never rewrites it, keeping costs in WooCommerce’s own field. Its profit reporting shows revenue, cost of goods, gross profit and margin by period and by product, each compared with the period before, and net profit once you have entered what each delivery method and gateway costs you. Refunds land on the refund date, and goodwill refunds are reported as their own line.

Its data quality screen puts a number on the gaps: how much of the last 90 days’ revenue is standing on lines with no cost, with the missing products listed worst-first by how much profit each one overstates. It can count unpaid orders on their creation date, which suits shops taking bank transfers, so its figures can differ from Analytics for that reason.

It does not cover overheads such as rent and salaries, landed costs or multiple currencies; those limits are listed on the scope page.

Stop finding out when a customer does.

What to order, how many, and the arithmetic behind it — inside the WooCommerce admin you already use.

Not an ERP and not a purchasing suite. Caltru works out what to order; placing the order stays with you. What's deliberately not included