Merchgain - Gross Margin & Profit Reports for WooCommerce

No. Start with the products that sell the most. Profit and margin are calculated on whatever has a cost, and the report always says how much of your revenue that covers, so a partly filled catalog gives you real numbers, not wrong ones. The missing cost warning links straight to the products that still need one. WooCommerce has no bulk editor for the cost field, but the REST API and WP-CLI can set the cost of many products at once, for example from a spreadsheet. Longer answer

They have no cost recorded, and Merchgain reports them as "no cost data" rather than as a cost of zero. Their revenue still counts; they are left out of profit and margin, and the coverage line tells you how much of your revenue that is. Once their products have a cost, the report also estimates them: today's product cost times the quantity sold, the same way WooCommerce would record it if the sale happened today. The estimate has a panel and columns of its own, every estimated figure is marked, and it is never added to the recorded profit. If a cost price changed since the sale, the estimate is off by exactly that change, which is why it stays apart. Longer answer

Open the report for the days of the sale: choose Custom range in the date selector, set the first and last day, and click Apply. Gross profit at the top is what the sale earned on items with a recorded cost. Sort the table by Profit, lowest first, to see the products sold below cost. The dates are part of the report address, written as year-month-day, so you can bookmark it or edit it by hand: /wp-admin/admin.php?page=merchgain&range=custom&from=2026-11-27&to=2026-11-30. A date written any other way opens the last 30 days instead. Merchgain does not compare two periods for you. Open a second report for a period of the same length just before the sale, on the same days of the week (here from=2026-11-20&to=2026-11-23), and compare the two. Enter your costs before the sale starts. WooCommerce records the cost on each order at the moment of sale. An item sold before its product had a cost has none recorded, so the report can only estimate it from today's cost, in a panel of its own. If you fill in your costs just before the sale, the period before it rests almost entirely on that estimate. Refunds count in the period they were issued, so items returned after the sale show up as negative amounts in the weeks that follow, not in the report for the sale days. Longer answer

Because those costs live in that plugin's own storage—a field of its own or, for ATUM, a table of its own—not in the WooCommerce core field. Merchgain tells you so instead of leaving you guessing: the missing cost warning counts how many of those products have a cost kept by another plugin and names it. Recognized: Cost of Goods: Product Cost & Profit Calculator for WooCommerce, WooCommerce Cost of Goods, ATUM Inventory Management for WooCommerce, Booster for WooCommerce, BjornTech PayPal POS integration for WooCommerce, Ni Cost of Goods for WooCommerce, and Cost Of Goods For WooCommerce. It counts them; it never uses them. A number taken from a field nobody can check is worse than a gap, and a shop with two cost plugins in its history has two fields that disagree, neither of them dated. Moving the values into the WooCommerce field is the durable answer, and the page below shows how. Longer answer

No, it is gross profit: revenue minus the cost of goods sold. Shipping, payment fees, advertising, and other running costs are not deducted, because WooCommerce does not record them as a cost of the order in any standard form. Tax and shipping are left out of revenue as well. Longer answer

Profit divided by revenue. A product bought for 60 and sold for 100 gives 40 profit and a 40% margin. This is not markup on cost, which for the same product would be 66.7%. The two get mixed up often, so the definition is printed under the report as well. Longer answer

From the Cost of Goods Sold field built into WooCommerce 10.3 and newer. Merchgain does not store costs of its own and does not add a second cost field to your products. Longer answer

Because Analytics does not read the cost field at all. WooCommerce records the cost on every order, but none of the Analytics reports uses it, and the WooCommerce documentation says the feature does not integrate with Analytics for now. Merchgain reads the cost from the orders directly, so it works whether Analytics is switched on or off. Longer answer

No. Merchgain makes no outgoing connections at all: no analytics, no license check, no update ping of its own. Everything is calculated by your own database and displayed in your own admin. The one exception is your own choice: an AI assistant you connect to your store can read the report through Merchgain's abilities, as the next question explains. Longer answer

Only if you connect one yourself. On WordPress 6.9 or later, Merchgain registers read-only abilities through the WordPress Abilities API: a profit summary for a period, the products sold at a loss, and the products without a cost. An AI assistant you connect to your store, for example through an MCP plugin, can call them as a logged-in user with the "view WooCommerce reports" permission, and gets the same figures as the Profit & margin screen. Merchgain itself sends nothing anywhere and changes nothing in your store. Longer answer

The report runs in the admin only, never on the storefront, and results are cached for an hour. Entering a cost in the product editor clears that cache immediately, so the numbers never wait for a timer. For anything else that changes the figures, such as an order status, a refund issued elsewhere, or an import, there is a Recalculate button at the top of the report. Longer answer

Yes, and with the classic post-based storage as well. Cost values live in the order items table, which is the same in both layouts. Longer answer

Anyone with the "view WooCommerce reports" capability, which is the same permission WooCommerce uses for its own sales reports. A shop manager has it, and so does a bookkeeper account limited to reports only. The report has its own item in the admin menu, Profit & margin, sitting just below the WooCommerce block. It is not inside the WooCommerce submenu, where an account limited to reports would never see it: that submenu needs a permission such an account does not have. Longer answer

All of it. There is no date limit. Any range can be selected, including a single month from years back; profit and margin appear wherever a cost was recorded on the sold item. Longer answer

Completed, processing, and refunded. Refunded is in the list on purpose: a full refund flips the parent order to that status, and leaving it out would make a fully refunded order count as minus its own value instead of zero. WooCommerce Analytics excludes only pending, failed, and cancelled by default, so this set is one status narrower: it skips on-hold. Longer answer

The month the refund was issued, not the month of the original sale. A September sale refunded in November leaves September untouched and shows as a negative amount in November. Reports of closed months do not change behind your back. Longer answer

That is WooCommerce, not Merchgain. Creating a refund makes the core recalculate the cost of every item on the parent order using the product's cost as it is today. If the product cost changed in the meantime, the stored history changes with it. Merchgain reports what is in the database; it does not silently keep a second copy. Longer answer

Because WooCommerce cannot tell the two apart. Saving a cost of zero, on the product or on an order item, makes the core store nothing at all rather than a zero, so "cost of zero" and "no cost entered" end up identical in the database. Rather than guess, Merchgain always says "no cost data" and never "cost 0". Free samples, giveaways, and downloadable extras will therefore appear on the missing cost list. Longer answer

They are left out of the report and named in a warning above the numbers. Merchgain does not convert exchange rates, and adding several currencies into one total would produce a number that looks right and is not. Longer answer

Because a product that sits in several categories is counted in each of them. A mug in both "Kitchen" and "Gifts" adds its sales to both rows, so the rows add up to more than the store actually sold. The alternative, picking one category and dropping the sale from the other, would quietly understate every shared category, which is worse. The summary cards are counted from the order items themselves, so they are never double counted. The screen says this under the table, and a CSV export of the category view says it on the last line, with both numbers. Longer answer