AGS Product Sales Report Pro - WordPress Plugin

Guide to Setting Up and Using AGS Product Sales Report Pro

AGS Product Sales Report Pro is the name many users still use when searching for Product Sales Report Pro for WooCommerce from the Aspen Grove Studios, WP Zone, and BerryPress ecosystem. In this guide, the product is treated not as just another plugin listing, but as a practical tool for a WooCommerce store owner who needs to quickly generate a clear product sales report, review the catalog, prepare an export for accounting, or compare performance across categories.

Below, you'll find installation, initial checks, report tab configuration, order and product filtering, variation handling, grouping, fields, export formats, presets, troubleshooting, and limitations. This guide does not cover purchasing, license activation, or obtaining the paid version. It assumes the site administrator already has the installation file and the goal is to enable the plugin safely, configure a useful report, and understand why the numbers in the export may differ from expectations.

The main value of AGS Product Sales Report Pro shows up where standard WooCommerce analytics are not enough: when you need to choose specific fields, export the results to a file, save a reusable preset, include or exclude order statuses, review variations separately, account for refunds, add custom fields, and prepare a report that can be handed off without manually building a spreadsheet.

What Problem the Plugin Solves in a WooCommerce Store

Built-in WooCommerce analytics give store owners basic reports on revenue, orders, products, coupons, and inventory. For day-to-day monitoring, that is often enough: you can see which products sold, how many orders came in, and which metrics changed over the selected period. But when preparing a report for purchasing, warehouse operations, accounting, or a marketplace manager, it is usually not enough to look at a chart - you need an accurate table with the right columns and filters.

AGS Product Sales Report Pro is built for exactly that practical use case. It generates a product sales report for a selected period and lets you narrow the data by order status, categories, tags, product IDs, custom fields, customer roles, and other conditions. The result can be downloaded in a spreadsheet-friendly format, opened as an HTML table, or emailed if that option is available in the version and extension setup you are using.

It is important to understand what the product does and does not do. This is not a full BI platform, not an external analytics service, and not a visual dashboard packed with dozens of charts. The plugin is most useful as a detailed product reporting tool: which products sold, in what quantity, for what amount, with what discounts, refunds, taxes, stock levels, SKUs, and additional fields.

When a Product Report Works Better Than a Standard Summary

The standard WooCommerce report is good at answering the question, "What happened in the store overall?" Product Sales Report Pro is better at answering, "Which exact rows do I need to pass on for action?" For example, a buyer may need to see SKU, quantity sold, current stock, and category. Accounting may care more about gross sales, post-discount sales, taxes, and refunds. A content manager may need product names, variations, and categories to decide which product pages need updates.

The same store can use multiple presets: a weekly report for fast-moving products, a monthly export for accounting, a report for a specific category, a separate table for size or color variations, or an export filtered to orders with a certain status. Saving repeatable settings is what turns the plugin from a one-off export tool into an actual operating procedure.

Where the Product May Be Unnecessary

If the store gets everything it needs from the built-in Analytics section in WooCommerce, and reports do not need to be exported regularly or shared with other people, a separate report builder may be unnecessary. If you need live charts, cohort analysis, ad spend, profit tracking with cost of goods, subscriptions, a mobile app, or external data processing without putting load on the site, a broader analytics platform may be a better fit. Product Sales Report Pro makes the most sense when the main pain point is flexible tabular product sales exports, not building a full analytics center.

Who AGS Product Sales Report Pro Is For, and Who Should Choose a Different Reporting Approach

The plugin is especially useful for stores where decisions are made at the product-line level, not just based on total revenue. If the store owner regularly decides what to reorder, which items to remove from the catalog, where to review refunds, which SKUs were part of a promotion, and which categories drive turnover, Product Sales Report Pro helps gather that data in a practical format.

Even a small store with just a few dozen products can benefit if the owner regularly needs a file for operational tracking. But the biggest payoff appears in catalogs with variations, categories, tags, custom fields, and multiple stakeholders in the process: the administrator builds the report, the warehouse manager checks stock, accounting verifies totals, and marketing reviews category performance.

User Roles and Access to Reports

The official documentation shows order filtering by customer roles: guests, customers, shop managers, administrators, and other roles created by WordPress or WooCommerce. That is not the same as giving different staff members permission to view plugin settings. It refers to whose orders will appear in the report. So before launching regular exports, separate these two questions: who is allowed to create the report in the admin area and whose purchases should be included in the table.

If the report is intended for an internal team, it is usually best to leave plugin configuration to an administrator or shop manager and share only the finished file with recipients. If you need to display the report on the front end of the site, the developer offers a separate solution, Frontend Reports for WooCommerce, which works with report presets. That setup should be configured carefully: a report may contain commercial data, so access to a report page should never be left public without checking permissions.

What to Check Before Installation and First Launch

Before installation, it is important to prepare not only WordPress, but also the store data itself. The report is built from WooCommerce orders, products, variations, and fields. If the store has inconsistent order statuses, duplicate SKUs, messy category structures, or custom fields created by other extensions, the plugin will not fix that data. It will only give you a way to output it in table form.

The official documentation lists requirements such as a self-hosted WordPress installation, active WooCommerce, PHP ZIP for XLSX support, sufficient memory and execution time limits, and MySQL or MariaDB. These details matter most for large catalogs and long reporting periods. A smaller store may never hit those limits. But if order volume is high, it is worth discussing PHP execution time and memory limits with your hosting provider in advance.

Minimum Technical Checklist

• WooCommerce is active and contains real orders. Without orders, the report will be empty even if the products are set up correctly.
• The site runs as a single WordPress installation. The documentation notes that WordPress Multisite is not supported, so network installations require a different solution or separate validation.
• PHP ZIP is available if you need XLSX. Without that extension, CSV or HTML is the safer choice.
• Administrator permissions are sufficient for report configuration. Some settings, such as CSS for the HTML report, may be restricted by user capabilities.
• Orders are synchronized when using HPOS. WooCommerce High-Performance Order Storage uses separate order tables, and reporting plugins need to work correctly with the selected storage model.

Before generating your first real report, run a short validation export. Pick a small period that includes 2 or 3 familiar orders and compare the rows against the order records manually. That is much faster than running a monthly report right away and then trying to find one mismatch across hundreds of rows.

Preparing Store Data

If the goal of the report is purchasing, review SKUs and variations. If it is for accounting, review order statuses, refunds, taxes, and discounts. If it is for category analysis, make sure products are not assigned to multiple categories without a good reason, because grouping by category can inflate totals when the same product belongs to more than one category.

It is also worth deciding in advance which orders should count as "sales" for a given report. For some stores, that means only Completed. For others, it means both Processing and Completed, because the order is already paid and being fulfilled. Statuses such as Cancelled, Failed, Refunded, and Pending payment should be included only when you clearly understand why they belong in that specific table.

Installation, Activation, and the First Check in the Admin Area

Installing Product Sales Report Pro works like any standard WordPress plugin: the administrator uploads the ZIP archive through Plugins - Add New - Upload Plugin, installs it, and activates it. After activation, a Product Sales Report-related menu item appears under WooCommerce. The exact menu labels may vary slightly by version and current branding, so use the WooCommerce menu and the developer's documentation as your guide.

The first check is not just a formality - it protects you from drawing false conclusions. If the report is empty, that does not automatically mean the plugin is broken. More often, the reason is the date range, order statuses, selected category, variation handling, or a custom field. That is why the first run should be as simple as possible.

The Safest First Run

1. Open the Product Sales Report settings page from the WooCommerce menu.
2. Select a short period where you know there are completed or processing orders.
3. Enable only the statuses that actually exist in the orders you are checking.
4. On the product tab, start by leaving all products included, with no category, tag, or ID filter.
5. In the report fields, keep only the core columns: product ID, SKU, name, quantity, and sales amount.
6. Choose a simple format such as CSV or HTML so you can review the output structure quickly.
7. Click Download Report or use the HTML preview if it is available in your version.
8. Open 2 or 3 orders from that period and confirm that the report rows match the actual line items.

If the basic report matches the orders, you can move on to more advanced setup. If it does not, do not change ten settings at once. Check the date range, WordPress timezone, statuses, refunds, variations, and product filter. That order makes it much easier to find the real cause.

Why You Should Not Start With a Large Report

A long date range, all statuses, all categories, separate variations, refunds, shipping rows, and custom fields all add load to the database and make the output harder to interpret. If the report takes a long time to generate or looks unexpected right away, it becomes difficult to tell which setting caused the result. It is much easier to start with a clean base table and then add options one at a time.

A required step before regular use is to save the test result and write down which statuses, fields, and filters were enabled. That way, if something changes later, you can return to a known-good configuration instead of rebuilding the setup from scratch.

Configuring the Report Tabs: From Date Range to File Format

The strength of Product Sales Report Pro is not a single button, but the system of tabs. It lets you gradually narrow the order set, choose the products, group the rows, define the fields, format the output, and only then download the file. The logic works like a funnel: first determine which orders are allowed into the report, then which products from those orders matter, then how to combine rows and which columns to display.

If you treat the tabs as a random set of toggles, it is easy to generate a report that is technically valid but does not answer the real business question. A better starting point is a clear statement such as: "I need a report on these products, for this period, with these statuses, in this format, so this specific person can make a decision."

Order Filtering Tab

This tab defines the date range and order-level conditions. The documentation describes preset ranges, custom dates, dynamic expressions, order statuses, filtering by order fields, customer roles, and customer fields. For most stores, the first two settings that matter are the date range and statuses.

Date Range and End Time

Pay special attention to the end time of the reporting period. The documentation states that the end date and time are treated as an exclusive boundary: the report includes orders up to that moment, but not the exact end moment itself. So for a full day, it is safer to use the start of the next day rather than trying to capture the final second. You do not need to memorize specific dates here - what matters is the principle: the period must cover the full intended interval without cutting off boundary orders.

Dynamic dates are useful for reusable presets, such as reports for previous days or the last month. But before saving that type of preset, make sure the expression is calculated relative to the WordPress timezone the way you expect. A date-range mistake produces one of the most deceptive outcomes: the report looks correct, but quietly omits part of the orders.

Order Statuses

WooCommerce uses statuses to show the state of an order: pending payment, processing, completed, canceled, refunded, failed payment, and other states. In Product Sales Report Pro, a checked status means orders with that status will be included in the report. For sales reports, most stores start with Processing and Completed, but the right choice depends on how the store operates.

If you include canceled or unpaid orders in a revenue report, the total may look higher than the real result. If you exclude Processing, the warehouse may miss products that are already paid for but not yet completed. That is why status rules should be documented either in the preset name or in an internal operating note.

Product Filtering Tab

This tab controls which products from the selected orders appear in the report. You can leave all products included, choose categories, specify product IDs, use tags, work with fields, set variation modes, include products with no sales, exclude free products, add shipping rows, and account for line-item refunds.

ID filtering is useful for spot checks or reports on a small product set. Category filtering is useful for purchasing and marketing. Tags help when categories define the catalog structure but tags are used for campaigns, seasonality, or internal collections. Custom fields matter when the store stores additional product attributes through WooCommerce or third-party extensions.

Variations: Combine or Separate

For variable products, there are two practical approaches. If a buyer needs to understand total demand for a model, variations can be grouped together. If the goal is to see which size, color, or configuration sells best, variations should be shown separately. Neither mode is universally better. The best mode is the one that matches the decision the report is meant to support.

After changing the variation mode, manually review a few orders. The same product may appear as a single row in one report and as multiple rows in another, and that is normal. It only becomes a problem when the format no longer matches the purpose of the report.

Grouping, Sorting, and the Risk of Double Counting

Grouping adds another layer to the report. For example, you can group by an order field or by a product attribute. The documentation warns that some fields should not be used for grouping if they already participate in the report as calculated or built-in fields. Otherwise, the result may conflict with the logic of the columns.

A separate risk is grouping by category. If a product belongs to multiple categories, its sales may appear in the report more than once, which can push category totals above the actual sales amount. That is not necessarily a plugin bug. It is a consequence of the chosen catalog structure and grouping method.

Report Fields and Column Order

The Report Fields tab lets you add the fields you need, remove unnecessary ones, rename headers, and reorder columns by drag and drop. For a working report, this is not cosmetic. The right column order saves time for the person using the file: SKU and product name together, then quantity, amount, refunds, stock, category, or a custom field.

Do not include every available field "just in case." A report that is too wide is harder to read, slower to process, and more likely to cause mistakes during manual sorting in spreadsheets. It is better to create separate presets for different jobs: warehouse, accounting, marketing, and refund control.

Format, File Name, and HTML Reports

Product Sales Report Pro supports multiple export formats, including CSV, XLSX, XLS, HTML, and HTML Enhanced. CSV is convenient for general sharing and imports. XLSX is convenient for Excel and familiar spreadsheet workflows. HTML works well for viewing the result in a browser. HTML Enhanced is useful when you need to quickly search, sort, and page through rows inside a browser-based table.

The file name can include dynamic parts tied to the preset and dates. That is useful for archiving: a file with a clear name is much easier to find later. The main thing is to avoid service characters in the file name that may not work well in the operating system or email attachments.

Product-Specific Scenarios: Variations, Refunds, Shipping, and Custom Fields

This section covers the settings that matter most specifically for Product Sales Report Pro. They cannot be replaced with a generic instruction like "export the report" because they change the meaning of the numbers. A single toggle can turn a model-level report into a size-level report, add shipping rows as separate entries, or change how refunds affect quantities and totals.

Variation Reports for Inventory Decisions

Stores selling apparel, cosmetics, accessories, parts, or consumables often use variable products. From the customer's perspective, this is one product with a choice of size, color, volume, or configuration. From the warehouse perspective, those may be different SKUs with different stock levels. Product Sales Report Pro lets you either group variations together or list them separately.

For purchasing, separate variation output is usually more useful because total demand for a model does not tell you which sizes are running out. For marketing or a high-level report to management, a combined row may be better because it shows the overall strength of the product in the catalog. A solid preset library usually includes both options.

Practical Variation Validation

Choose one variable product with several orders across different attributes. Generate one report with variations combined, then a second report with variations separated. In the first report, expect one consolidated row. In the second, expect rows for specific variations or SKUs. If both exports look the same, check whether the product is actually set up as variable and whether different variations were sold during the selected period.

Refunds and Discounts in Reports

The plugin includes fields related to refunds, post-discount sales, discount amount, taxes, and totals. The documentation also explains the option for including line-item refunds: if enabled, amounts and quantities may reflect refunds in the refund period rather than necessarily in the period of the original order. That is an important detail when reconciling numbers.

If accounting compares a Product Sales Report Pro report with WooCommerce Analytics, agree in advance on which metrics are being compared: gross sales, post-discount sales, taxes, refunded amounts, quantity sold, or quantity refunded. Different reports answer different questions, and a mismatch does not always mean something is wrong.

Shipping as a Report Row

The Include shipping setting adds shipping methods as separate rows with ID, name, usage count, and shipping amount. That is useful when a manager needs to see which delivery methods customers actually choose and how much revenue those methods generate. But at that point, it is no longer a pure product report. If the same file is expected to contain only product rows, shipping rows can be confusing.

Use a separate preset for shipping if you need that data on a regular basis. Do not mix it into a purchasing report where every row is expected to represent a product or variation.

Custom Fields and Fields Added by Third-Party Extensions

Product Sales Report Pro can work with custom fields added by WooCommerce or other plugins to orders, products, variations, or users. The documentation specifically notes that the list of available fields depends on the site's configuration and active extensions. That means one store may see a delivery field, another may see an event date field, and a third may see data from an extra product option.

The practical value here is significant: you can build a report for orders with a specific delivery date, output a supplier flag, filter by a custom field, or add an important internal code to the table. But this is also where mistakes happen most often. The field may not be named the way a manager sees it in the interface. It may be stored at the order level, product level, or order-item level. It may be missing from older orders. That is why any custom-field setup should first be tested on a small dataset.

Practical Example: A Weekly Report for Purchasing and Warehouse Operations

Let's look at a real working scenario. The store sells variable products, and the warehouse manager decides each week what needs to be reordered. They need a file showing SKU, product name, variation, quantity sold, current stock, category, and post-discount sales amount. Overall store revenue does not solve that problem because purchasing decisions happen at the level of specific product rows.

Goal

Generate a repeatable weekly export of sold products and variations that can be opened in a spreadsheet, sorted by quantity sold, and handed off to the buyer. The report should exclude unpaid and canceled orders, show only actual sales, and be saved as a preset so the settings do not have to be rebuilt the following week.

Preparation

• The store has orders in the target period.
• SKUs are filled in for both simple products and variations.
• Order statuses are used consistently: paid orders are in Processing or Completed.
• Current stock is tracked in WooCommerce if the stock field is needed in the report.
• The administrator understands whether refunds should be included in this specific purchasing export.

Setup Steps

1. Open the Product Sales Report page in the WooCommerce menu.
2. On the Order Filtering tab, choose the date range. For a weekly report, you can use a preset range or a dynamic expression if you have already verified how it is calculated on your site.
3. Enable Processing and Completed if those are the statuses that represent paid sales in your store.
4. On the Product Filtering tab, leave all products included or choose specific categories if purchasing is split by business line.
5. For a variable catalog, enable separate variation output so size, color, or configuration does not collapse into a single row.
6. If free items are not relevant to purchasing, enable the option to exclude free products.
7. On the Report Fields tab, add Product SKU, Variation SKU, Product Name, Variation Attributes, Quantity Sold, Current Stock Quantity, Gross Sales (After Discounts), and Product Categories, if those fields are available in your configuration.
8. Rename the headers so the recipient can understand them without access to the admin area, for example: "SKU," "Variation," "Sold," and "In Stock."
9. On the Grouping & Sorting tab, sort by quantity sold descending or by SKU if the file will be matched against an internal inventory system.
10. On the Display & Format tab, choose XLSX or CSV, enable the header row, and add a totals row if needed.
11. Save the settings as a preset with a clear name, such as weekly-stock-sales.
12. Download the report and open it in a spreadsheet.

Verifying the Result

After exporting, choose 2 or 3 rows and open the corresponding orders in WooCommerce. Check the SKU, quantity, order status, and whether a refund exists. Then sort the report by quantity sold and confirm that the top rows really look like your fast-moving items. If the report shows only part of the catalog, check the date range, statuses, category filter, and the "show only products with sales" setting.

Scenario takeaway: a good purchasing preset should be concise, repeatable, and easy to verify. If it contains too many columns, the recipient will start deleting extras manually, which increases the chance of mistakes.

A Common Obstacle

If current stock looks incorrect or causes an error in an older plugin version, check the changelog and updates. Product Sales Report Pro has had fixes related to the Current Stock Quantity field. If the site is running an older build, it is smarter to update a staging copy and rerun the report there than to keep hunting for a problem in the preset settings.

How to Validate Report Accuracy and Avoid Mixing Up Different Metrics

Any sales report becomes useful only after validation. WooCommerce uses similar-sounding terms: gross sales, net sales, total sales, discounts, taxes, refunds, and shipping. Product Sales Report Pro adds its own fields and output modes. If you compare different metrics as though they were the same thing, you may wrongly conclude that the plugin is calculating incorrectly.

Validation should move from simple to complex: date range, statuses, products, variations, fields, refunds, totals. Do not start with the monthly grand total. Start with a single order that has a clear product line item. Then verify an order with a discount. Then an order with a refund. Then a variable product. Once those checks pass, you can trust a larger report much more confidently.

Spot Check Against a Single Order

1. Choose an order with one product and no discount.
2. Generate a report for a period that includes only that order or the smallest possible number of neighboring orders.
3. Check the product name, SKU, quantity, and amount.
4. Add a category or current stock field to the report and confirm that it belongs to the product rather than the order as a whole.
5. If everything matches, repeat the check on an order with a variation and an order with a discount.

What to Compare Against WooCommerce Analytics

WooCommerce Analytics presents reports using its own logic: products, orders, revenue, discounts, refunds, taxes, and shipping. Product Sales Report Pro generates the table you define. A comparison is only valid when the period, timezone, statuses, metric type, and refund handling rules all match. For example, gross sales before discounts and sales after discounts are different metrics. Shipping as a separate row and shipping as part of a total are also different views of the data.

If you need to explain a discrepancy to the team, save two things side by side: the Product Sales Report Pro preset and a screenshot or CSV from WooCommerce Analytics for the same period. Then note which statuses are included, which fields are being compared, and whether refunds were counted. That turns an argument about "wrong numbers" into a technical settings review.

Validating Large Catalogs

For stores with large numbers of products and orders, report generation may take longer. The documentation describes Advanced settings such as increasing the execution time limit, disabling object caching when memory issues occur, debug mode, and CSS for HTML reports. These settings do not need to be enabled in advance. They are useful when you have a specific symptom: a timeout, a memory error, suspected conflict, or the need to adjust the appearance of an HTML report.

If the report is too heavy, first try narrowing the date range, limiting categories, removing unnecessary fields, and disabling separate variation output if it is not needed. You can also use the "Show only the first" setting for quick top-item reports. Server limits should be changed only after you confirm the report truly needs more resources rather than simply including too much data.

Presets, Automation, and Integrations with Other Solutions

Presets are one of the most practical parts of Product Sales Report Pro. They let you save a configuration and return to it later. Without presets, the administrator has to reselect the date range, statuses, fields, format, and sorting every time, which increases the risk of human error. With a preset, the report becomes an operating standard: the same question is asked of the current store data each time.

How to Name Presets So the Team Does Not Make Mistakes

A preset name should explain the purpose, the period, and the important limitation. For example, weekly-stock-processing-completed is much clearer than report-1. If the report excludes free products, includes refunds, or shows variations separately, that should also be reflected either in the name or in an internal instruction. Otherwise, the team will forget what the preset actually does after a few weeks.

Using It with Scheduled Email Reports

Official sources indicate that Product Sales Report Pro can be used together with Scheduled Email Reports for WooCommerce for regular report delivery. This is useful when a manager needs a file every morning or every week without manually logging into the admin area. The practical order is simple: first create and validate the preset manually, then enable the schedule, then verify the first automated email and its attachment.

The main point of friction is the date range. For automated reports, it is better to use a dynamic range that recalculates each time relative to the run date. But dynamic periods are exactly what you need to validate most carefully: the wrong expression can cause incomplete files to be sent automatically on a regular basis.

Using It with Frontend Reports

Frontend Reports for WooCommerce can be useful if the report needs to appear on the front end of the site or on a private team page. It is not a replacement for Product Sales Report Pro, but a way to display an already prepared report or download link outside the admin area. Product Sales Report Pro builds the preset. Frontend Reports displays it in the right place on the site.

Before using that combination, check access permissions carefully. A sales report may include commercial data and sometimes custom fields that should not be visible to outsiders. Without a protected page, user role restrictions, or another access-control mechanism, it is better not to enable this type of display.

When Ninjalytics Is a Better Fit

BerryPress positions Ninjalytics as a more modern direction for reporting, with visualization, templates, calculated fields, an improved interface, and support for importing Product Sales Report Pro presets. If what you need is a straightforward tabular report inside WordPress, the current product remains a clear and practical option. But if the team wants charts, broader analysis, live preview, multi-platform reporting, or a path toward a more advanced analytics workflow, Ninjalytics is worth evaluating as an alternative.

Safe Improvements Without Editing the Plugin Core

Product Sales Report Pro already includes a built-in Report CSS field for HTML and HTML Enhanced reports. That is a rare case where a small visual enhancement can make sense inside the product itself rather than through theme or plugin file edits. The documentation also notes that only users with the edit_theme_options capability can modify this field. This approach is much safer than editing extension files directly: the setting can be removed or replaced without being lost during updates.

Below is a small CSS example for an HTML report. It does not affect calculations, does not interfere with CSV or XLSX exports, and is intended only to make the table easier to read in a browser. Use it on a site copy or with a test preset, especially if the report is being shared with the team through HTML Enhanced.

/* Improves readability of the Product Sales Report Pro HTML report */
table.product-sales-report {
  border-collapse: collapse;
  width: 100%;
  font-size: 14px;
}

table.product-sales-report th,
table.product-sales-report td {
  border: 1px solid #d8dee6;
  padding: 8px 10px;
  text-align: left;
}

table.product-sales-report th {
  background: #f3f6f9;
  font-weight: 700;
}

table.product-sales-report tr:nth-child(even) td {
  background: #fafbfc;
}

Before applying it, check the actual table class in the HTML report. If the class is different, adjust the selector to match your output. After pasting the CSS, open the HTML report and make sure the table is easier to read and that no rows or headers have disappeared. To roll the change back, remove the CSS from the Report CSS field and save the settings again.

Do not edit plugin files. Any customization made through the extension core can disappear during an update and make support harder. For visual tweaks, use the built-in CSS field, a child theme, or another safe WordPress mechanism if you truly need it.

Performance, HPOS, and Limitations You Should Know in Advance

Order reports always depend on the database. The more orders, fields, variations, conditions, and groupings you include, the heavier the queries become. Product Sales Report Pro includes settings for time limits, object caching, and debugging, and the changelog shows that the developers have paid attention to HPOS, field caching, and issues with specific fields. But that does not change the basic rule: a report should be as wide as necessary to solve the task, and no wider.

HPOS and Shipping Report Accuracy

WooCommerce High-Performance Order Storage uses separate tables for orders. The Product Sales Report Pro changelog includes a fix related to shipping report accuracy in HPOS mode. That makes it especially important on HPOS stores to keep the plugin updated and validate shipping reports on a small date range. If shipping rows are used in management reporting, do not rely on an old preset without a control check.

Object Caching and Memory

The Disable WordPress object caching setting is intended for situations where report generation runs into memory errors. Do not enable it without a clear symptom: caching often helps the site perform better. If a report fails, first narrow the selection and remove unnecessary fields. If the issue remains, test disabling object caching only as a diagnostic step and record whether it changes the behavior.

Debug Mode and Export Formats

Debug mode can show SQL queries and other technical information, but the documentation warns that it is intended for HTML output and can corrupt XLSX files. So do not enable debug mode for reports that are sent to staff or accounting. Use it only for troubleshooting, then turn it off and regenerate a clean export.

WordPress Multisite Limitation

The documentation states that Product Sales Report Pro does not support WordPress Multisite. If the store runs in a multisite network, do not assume the standard workflow will be supported without separate validation. For a multisite setup, it is better to choose a solution that explicitly supports that architecture or move reporting into a separate service layer.

How to Build a Repeatable Reporting Process Without Manual Confusion

The most common mistake when adopting a reporting plugin is treating it like a "download spreadsheet" button instead of part of a process. One administrator may generate the correct file today, but next week choose a different period, forget the Processing status, add an extra field, or send CSV instead of XLSX. The result is that the team ends up comparing files that are not equivalent and wasting time explaining discrepancies. Product Sales Report Pro gives you the tools for repeatability, but the process itself still needs to be defined inside the business.

A practical operating procedure should be short: which presets exist, who runs them, when a file is considered final, which statuses are included, where the finished export is stored, and who is responsible for verification. This is not bureaucracy. It is how you make sure a product sales report stays the same working artifact every time instead of becoming a new manual experiment on each run.

Minimum Preset Set for a Team

For most WooCommerce stores, it is enough to start with three presets. The first is warehouse-focused: period, paid statuses, SKU, variations, quantity, current stock, and category. The second is financial: period, statuses, gross sales, post-discount sales, taxes, refunds, a totals row, and a format that opens easily in a spreadsheet. The third is marketing-focused: category or tag, sorting by quantity or amount, a top-position limit, and name and SKU fields for quick handoff into advertising or content work.

If the team handles shipping separately, do not add shipping rows to every report. Create a separate preset for shipping methods. If you use reports by customer role or custom fields, keep those separate as well. The more precisely a preset matches the task, the less likely the recipient is to start manually deleting columns and changing the sort order.

How to Describe a Preset Next to the File

Each recurring report should have a short human-readable description. For example: "Weekly purchasing report: latest completed and processing orders, variations separated, free items excluded, sorted by quantity sold." That line is more useful than a long technical preset name. You can store it in an internal guide, a manager's task, or the name of the folder where exports are saved.

If dynamic dates are used, add a note explaining how they are calculated. Otherwise, a manager may assume the preset always builds a calendar-week report when it is actually pulling previous days relative to the time of execution. This matters even more for automated delivery: the file may arrive in the morning, in the evening, or after a technical delay, and the date range still needs to behave as expected.

Validation Check Before Sending a Report

Even after a preset is configured, it is worth keeping a short validation checklist. It takes only a few minutes but protects against costly decisions based on bad data. The reviewer does not need to recalculate the whole store manually. It is enough to confirm that the file answers the question it was created to answer.

• The date range matches the task. Check the report title, file name, or the first rows of the table if they are included in the Display & Format settings.
• The order statuses are the expected ones. If this is a purchasing report, it should not include unpaid or canceled orders unless that is part of a separate task.
• Variations are shown in the correct mode. In a catalog with sizes and colors, the wrong variation mode changes the meaning of the entire file.
• The columns have not changed by accident. The recipient should see familiar fields in a familiar order.
• One questionable row has been checked manually. Open an order or product from the top of the report and compare it with the export.

If the check fails, do not treat manual edits in Excel as the main fix. It is better to return to the preset, correct the configuration, and generate the report again. Manual editing is acceptable only as a temporary note, not as a permanent operating method.

How to Store Exports Without Mixing Versions

In Product Sales Report Pro, the file name can be set in the format settings. Use clear names without unnecessary symbols: report purpose, period or creation date, and a short status indicator. For CSV and XLSX, avoid long marketing-style titles, leading spaces, quotation marks, and unusual symbols. The simpler the name, the fewer issues you will have when sending, archiving, or importing the file into other systems.

If the team stores reports in a cloud folder, create separate directories by purpose: stock, finance, marketing, shipping. Do not drop test files there under the same names. A test report should be clearly labeled, otherwise it is easy to mistake it for a live one a month later.

What to Do After Changing Catalog Structure or Fields

Changes to the store structure can break the old reporting logic. New categories, mass SKU updates, moving products between categories, adding a supplier field, or updating an extra-options plugin can all affect the export. After changes like that, do not wait for the next scheduled report. Run a short preset check in advance.

Pay especially close attention to custom fields. If a new field starts being filled only for new orders, an older reporting period will look incomplete. That is not a Product Sales Report Pro error. It is a property of the data: the report cannot display a value that did not exist in the order or product at the time. During transition periods, it is better to note in the report that the field is not populated across the full history.

When to Split Reports Instead of Overloading One

Sometimes a user tries to build one "master" report that will work for the warehouse, accounting, marketing, and management. In practice, that file becomes bloated: dozens of columns, mixed shipping rows, refunds, variations, categories, custom fields, and multiple sales metrics. It becomes hard to validate and even harder to use.

The better approach is multiple focused reports. A warehouse report can be short and sorted by quantity. A financial report can include amounts, taxes, and refunds. A marketing report can show categories, tags, and top-performing items. If two departments need the same source, let them use one validated preset. If the questions are different, do not hesitate to create separate presets.

Implementation rule: if an employee always manually deletes the same columns, sorts the file the same way, or filters rows by the same condition after every export, that is a sign to create a separate preset instead of continuing with manual cleanup.

When AGS Product Sales Report Pro Is the Right Choice

AGS Product Sales Report Pro is a strong option when a WooCommerce store needs repeatable, configurable, and verifiable product sales reports. It is especially well suited to warehouse operations, purchasing, accounting, category management, and variable product analysis. The product's strength is not a pretty dashboard with charts, but a precise table builder: date range, statuses, products, variations, fields, sorting, format, and preset.

Before using it regularly, configure one simple report, validate it against real orders, and then create 2 to 4 working presets for different team roles. For large catalogs, do not overload a single file with every field at once. For HPOS, shipping rows, refunds, multi-category products, and custom fields, always run a control check on a small date range first.

If the product covers your use case after validation, you can go to the AGS Product Sales Report Pro download and test it on a store copy or on a short reporting period. That approach is safer than turning on automated delivery right away and making management decisions based on an unverified export.