Financial Revolution: advanced reporting for PrestaShop store owners

Last reviewed June 2026, the back-office field paths and table names below apply to PrestaShop 1.7, 8 and 9; menu labels shift slightly between versions, so the exact wording in your admin may differ.

PrestaShop will happily tell you how much you sold. Open Stats (the AdminStats controller, under the Dashboard / Stats menu depending on your version) and you get sales over time, best-selling products, carrier breakdowns, a sales-and-orders dashboard, and a sortable best-sellers list. What none of those screens will tell you is the one number that decides whether your store is actually a business: how much money you kept. Revenue is what PrestaShop measures by default. Profit is what you take home, and the two diverge far more than most merchants realise. This post is about closing that gap: the financial reporting a PrestaShop store needs to manage by margin instead of by turnover, what the back office gives you, where it stops, and how to get to true profit per product, per order, per customer.

One boundary first, so this post stays in its lane. This is financial reporting, money in, money out, what's left. It is not web analytics. Where your visitors come from, how they behave on the page, which traffic source converts, that's a separate discipline, and we cover it in what to track and what to ignore and the GA4 metrics that actually matter. Here we stay on the P&L.

Why PrestaShop's native stats can't tell you if you're profitable

The native Stats engine is built around revenue and volume because that's what lives cleanly in the order tables. When PrestaShop records a sale, it stores the price the customer paid, the tax, the shipping they were charged, and the order state. It does not, in any usable reporting form, store what that order cost you. That cost is scattered across places the Stats screens never join up:

• Wholesale cost. PrestaShop does have a field for it. wholesale_price on the product, set under Catalog → Products → [product] → Pricing → Cost price, stored on ps_product and copied to ps_order_detail.original_wholesale_price at the moment of sale. The catch: almost nobody fills it in, and even when they do, the native places it surfaces, the Stats → Catalog statistics profit-margin figure and the per-product profit column under Stats → Best-selling products / Product details. Are blended or per-product-aggregate views, never a per-order or per-customer one.
• Payment processing fees. The 1.4–3% Stripe, PayPal or card processor keeps never enters PrestaShop at all. A 100 € order is recorded as 100 € of revenue even though 97.10 € hit your account.
• Real shipping cost. The order stores what the customer paid for shipping, never what the carrier charged you. Offer free shipping and the native total shows shipping revenue of zero and a cost of zero, when you actually paid the courier 6 €.
• Refunds and returns. A refunded order can still sit in a state that counts toward "valid" revenue depending on your order-state configuration, quietly inflating the top line.

So the native "Profit margin" number is directionally fine for a sanity check and useless for a decision. It can't tell you which of two products you should promote, because it can't see that one carries a 2 € card fee and a 30% return rate while the other ships free of those drags.

Revenue is the most misleading number in your store

Consider two PrestaShop stores side by side. Store A turns over 50,000 € a month; store B does 20,000 €. The native dashboard makes A look like the clear winner. Now layer in the costs PrestaShop doesn't track: A sells low-margin electronics with a 12% return rate, pays 1.9% in card fees, and subsidises shipping; B sells own-brand goods at 60% margin with almost no returns. Run the real arithmetic and B keeps more euros every month. The merchant staring at the native Stats screen would optimise for exactly the wrong store.

This is the whole case for financial reporting in one example. The metrics that actually move a store are second-order. They only exist once you subtract cost from revenue:

• Gross margin per product. Selling price minus wholesale cost, minus the payment fee, shipping subsidy, and proportional overhead attributable to that line. The product that looks like your hero on the best-sellers list is sometimes the one quietly losing money once fees and returns are in the picture.
• Contribution per order. What a single order leaves behind after its own variable costs. Two 80 € orders are not equal if one shipped free across the country and the other was click-and-collect.
• Profit by customer segment, tying lifetime value to acquisition. The relationship between what a customer is worth and what they cost to win is a topic on its own; we won't re-derive it here, the data on customer value vs. acquisition cost lives in what to track and what to ignore.
• Real return rate by product and category, a 30% return rate isn't a best-seller, it's a defect or a misleading description eating your margin twice (you pay shipping out, you eat shipping back, you may not resell the item).

What you can get from PrestaShop today, and the export wall

Before reaching for anything extra, it's worth knowing exactly how far the box takes you, because for a small catalogue it might be far enough.

That last row is where most merchants end up, exporting orders to a spreadsheet, hand-stitching in fee schedules and shipping invoices, rebuilding the same pivot table every month. It works once. It does not work as a weekly habit, and a report you only run when you're worried is a report that catches problems a month late. The honest native ceiling is this: PrestaShop can show you revenue in a dashboard and cost only if you go digging through SQL Manager with your own queries. Joining the two into a standing, scheduled, drill-downable profit view is the wall the back office doesn't take you over.

If you're comfortable in SQL Manager, you genuinely can get a long way. A query joining ps_orders, ps_order_detail and original_wholesale_price will hand you a real per-order gross margin. What you can't easily do there is fold in external cost data (your Stripe fee schedule, your carrier invoices), schedule it, or hand it to a non-technical colleague. That's the line between a clever query and a reporting system.

The SQL Manager query that gives you real per-order gross margin

Here's a starting query you can paste into Advanced Parameters → Database → SQL Manager. It sums each order's revenue against the wholesale cost captured at the moment of sale, so you get gross margin per order, the thing the native screens won't show you. Adjust the table prefix (ps_) if yours differs, and the valid-order filter to match your order states:

SELECT
    o.id_order,
    o.reference,
    o.total_paid_tax_excl                              AS revenue_excl_tax,
    SUM(od.product_quantity * od.original_wholesale_price) AS cost_of_goods,
    o.total_paid_tax_excl
        - SUM(od.product_quantity * od.original_wholesale_price) AS gross_margin,
    ROUND(
        100 * (o.total_paid_tax_excl
            - SUM(od.product_quantity * od.original_wholesale_price))
        / NULLIF(o.total_paid_tax_excl, 0)
    , 1)                                               AS margin_pct
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.valid = 1
GROUP BY o.id_order
ORDER BY gross_margin ASC;

Two honest caveats. This is gross margin only. It subtracts cost of goods but not payment fees, real shipping cost, or returns, because PrestaShop doesn't store those (which is the whole point of this article). And it's only as truthful as your original_wholesale_price data: orders placed when the cost field was empty will show 100% margin and skew the list. Sorting ascending (gross_margin ASC) puts your worst orders at the top, which is usually what you want to look at first.

From data to decisions: what changes when you can see profit

So what? The point of all this isn't a prettier dashboard. It's that four everyday decisions stop being guesses:

• Pricing. A 5% rise on a healthy-margin, steady-demand product is a confident move when you can see the current true margin next to its sales trend. Blind to cost, the same decision is a coin flip.
• What to promote. Profit reporting routinely reorders the best-sellers list. The unit-volume champion and the profit champion are frequently different products, and you want your homepage slot, your ad spend and your bundle offers pointed at the second one.
• Inventory. What to restock, discontinue or clear should follow margin, not volume. A slow mover with a 65% margin may deserve more visibility; a fast mover at 4% may need a price rise or a quiet exit.
• Discount strategy. A flash sale that books 10,000 € of revenue but 500 € of profit after the discount, the fees and the shipping isn't the win the revenue chart implies. Margin-aware reporting tells you that the morning after, not at quarter-end.

Closing the gap with the Financial Revolution module

This is the specific job our Financial Revolution module exists to do: take the revenue PrestaShop already records, let you capture the costs and expenses it never tracks at all, and turn the result into a standing profit-and-loss view inside the back office, no monthly spreadsheet, no SQL by hand. So what does that get you?

• A real profit-and-loss view, not just a revenue dashboard. Revenue, your captured costs and operating expenses, tax/VAT and the resulting profit, broken down by category, so the bottom line you read is the one you actually keep rather than a turnover figure.
• Cost and expense tracking PrestaShop has nowhere to put. Record the costs and overheads the platform never stores (payment-processor fees, real shipping, operating expenses) and have them netted off revenue automatically instead of bolted on in a spreadsheet.
• Cash-flow, tax and VAT reporting in one place, cash-flow movements, tax and VAT reports, invoices and corrections handled inside the back office rather than reconciled by hand after the fact.
• It lives in your admin, read it from the back office on the same weekly cadence you already check orders, instead of exporting and rebuilding, with CSV export when you need to hand the numbers to an accountant.

Honest boundary: a reporting module reports. It doesn't set your prices or refund your card fees. Its job is to make the true number impossible to miss so you can act on it. And it's only as accurate as the cost data behind it, which is the next point.

Make it trustworthy: fill in the cost data first

Financial reporting is garbage-in, garbage-out, and the most common reason a profit report looks wrong is empty cost fields. Before you trust any margin figure, native or module, do the unglamorous groundwork:

• Populate wholesale / cost price on every product (Catalog → Products → Pricing → Cost price). Bulk-edit or import it via the Catalog import if you have hundreds of SKUs; a margin report over half-empty cost fields is worse than no report, because it looks authoritative and isn't.
• Know your real fee schedule, the actual percentage and per-transaction fee your payment provider charges, which you can read off a Stripe or PayPal statement, not the headline rate.
• Get your real carrier costs, not the customer-facing shipping price, from your courier invoices, especially if you offer free or flat-rate shipping, where the customer-paid figure tells you nothing.
• Tidy your order states so refunded and cancelled orders aren't silently counted as valid revenue. Check which states are flagged as logable/paid under Shop Parameters → Order Settings → Statuses.

Build the reporting habit

The most accurate report in the world is worthless if nobody opens it. The stores that compound are the ones where a number, not a hunch, ends the argument, and that only happens on a rhythm:

• Weekly: total profit (not revenue), your top and bottom performers by margin, and any swing worth a second look. Five minutes from the back office.
• Monthly: trends and seasonality, and whether a specific initiative, a price change, a new supplier, a promo, actually moved profit rather than just revenue.
• Quarterly: the whole strategy against the data. Which categories earn their shelf space, which customers are worth keeping, where the catalogue's dead weight is.

PrestaShop measures revenue out of the box because revenue is the easy number to store. Profit is the number that runs the business, and getting to it means subtracting the costs the platform scatters or ignores, wholesale, fees, real shipping, returns. Whether you get there with a careful SQL Manager query, a disciplined spreadsheet, or a module that does the joining for you, the discipline is the same: manage by what you keep, not by what you turn over, and read it often enough to catch the slide before it's a quarter old.

Frequently asked questions

Why does PrestaShop's native profit margin look wrong or empty?

Almost always because the cost-price field is empty. PrestaShop's Stats → Catalog statistics margin is calculated from wholesale_price, and if you never filled that in on your products, the figure is meaningless. Even when it's populated, the native number is one blended global percentage that ignores payment fees, real shipping cost, and returns, so it's fine as a rough sanity check and useless for deciding which product to promote. Fill in cost prices first; then decide whether the native view is enough or you need per-order detail.

Can I calculate real profit per order without a module?

Yes, for gross margin, the SQL Manager query above joins ps_orders and ps_order_detail on original_wholesale_price and gives you margin per order. What you can't do in SQL Manager without real effort is fold in external costs (your Stripe fee schedule, carrier invoices), schedule the report, or hand it to a non-technical colleague. That gap. Joining external cost data into a standing, drill-downable P&L. Is the line between a clever query and a reporting system like Financial Revolution.

Where does PrestaShop store the cost price, and how do I bulk-fill it?

The cost price lives in wholesale_price on ps_product (and per-combination where you set it), edited under Catalog → Products → Pricing → Cost price. At the moment of sale PrestaShop copies it to ps_order_detail.original_wholesale_price, which is why historical orders keep the cost that was true when they were placed. For hundreds of SKUs, fill it via the Catalog CSV import rather than by hand, and remember that orders placed before you populated it will show no cost, so don't trust margin on old orders.

Does Financial Revolution track payment fees and shipping costs automatically?

It gives you the place to record them and nets them off revenue automatically once they're in, but it can't read your Stripe statement or courier invoice for you. The module's job is to capture the costs PrestaShop has nowhere to store (processor fees, real shipping, operating expenses) and fold them into a back-office P&L so you stop rebuilding a spreadsheet. The accuracy still depends on you entering your real fee schedule and carrier costs; garbage in, garbage out applies here as much as anywhere.

Is this the same as my GA4 or analytics data?

No, and conflating them is a common mistake. This is financial reporting: money in, money out, what's left. GA4 and the like are web analytics: where visitors come from, how they behave, which channel converts. They answer different questions and neither replaces the other. For the analytics side, start with what to track and what to ignore and the GA4 metrics that actually matter.