AGS Export Order Items Pro - WordPress Plugin

How to Configure AGS Export Order Items Pro for WooCommerce Reporting

AGS Export Order Items Pro is not about making your storefront look better. It is built for steady day-to-day work with WooCommerce orders: exporting order line items, seeing products, variations, quantities, amounts, taxes, shipping, customer fields, and extra metadata in a usable file. This guide shows how to treat the plugin as a working tool, not just a button that says "export everything."

This article will be useful for a store owner, content specialist, accountant, warehouse manager, and developer helping a team set up a repeatable export workflow. We will go from site preparation to file validation, with separate attention to filters, product lines, variations, custom fields, presets, output formats, troubleshooting, and alternatives.

This guide does not cover buying the plugin, bypassing activation, or obtaining a paid version. That is not the point here. The point is that you already have a working plugin and need to understand which settings to enable, which ones not to touch without a reason, how not to lose order lines, and how to verify that the report actually matches the task.

What problem order line export actually solves

In WooCommerce, a single order can contain multiple line items: a simple product, a product variation, shipping, a discount, tax, a refund, an extra field, or a customer note. The standard order list in the admin panel shows the order as one complete record. For warehouse work, accounting, or product-level reconciliation, you often need a different view: one row in the file should correspond to a specific purchased item or a clearly defined group of data. That is why AGS Export Order Items Pro should be treated as an order line export tool, not a general sales reporting tool.

This approach is especially useful when your store works not just with order totals, but with cart contents. For example, your fulfillment team may need the SKU, product name, quantity, and variation. Accounting may need the line amount, tax, shipping, and discount. A marketing specialist may need an export of orders by category, customer role, or a specific custom field. If all of that has to be pulled manually from individual order screens, errors show up quickly: one order gets overlooked, another ends up in the wrong status, and in a third case the parent SKU gets confused with the variation SKU.

The plugin handles this through a set of tabs with report parameters. The user selects a date range, order statuses, order and product conditions, output fields, file format, and additional display rules. After that, the report can be generated manually or saved as a preset for repeated use.

The main idea for a first run is simple: do not start with the maximum number of fields. First decide who will read the file and what decision they need to make from the data. For order fulfillment, product lines, quantities, variation details, the buyer's name, and the shipping method may be enough. For accounting, you will need amounts, taxes, discounts, and summary rows. For analysis, period filters, categories, tags, and customer roles matter more.

Who this plugin fits best, and when another tool may be better

AGS Export Order Items Pro works best for stores that need reports on a regular basis and need those reports to keep the same structure over time. If you need to export items from completed orders once a week, send the file to the warehouse, and avoid rethinking which columns to include every time, presets and configurable fields save more time than the short product description suggests.

The plugin fits stores with variable products, extra order fields, dedicated customer roles, multiple order statuses, and reconciliation tasks. The official documentation specifically describes filters by period, statuses, customer roles, products, categories, tags, custom fields, free items, refunds, and shipping. That makes the product useful not only for one-off CSV exports, but also for building a clean report for a specific operational role.

The plugin may be unnecessary if you only want to download a basic CSV once in a while with a few fields and do not save repeatable settings. In that case, the free version of Export Order Items for WooCommerce or built-in export features from another plugin may be enough. You should also look at other solutions if you need to import orders back into WooCommerce, transfer files to a remote server, run more complex automated jobs, or handle a large store migration. AGS Export Order Items Pro works well alongside other products from the same developer, but on its own it should not be expected to replace a full data exchange system.

Check your site type separately: the documentation lists compatibility with a standard standalone WordPress and WooCommerce installation, but notes that it is not compatible with WordPress Multisite. If your store runs in a multisite network, do not plan the rollout as if it were a normal single-domain setup. First confirm support for your architecture and test exports on a copy of the site.

What to check before installing it on a live store

Order exports work with commercially sensitive data: names, addresses, phone numbers, email addresses, cart contents, amounts, taxes, and internal labels. That makes preparation more important here than it would be for a decorative plugin. A reporting mistake may not break the public site, but it can lead to incorrect order fulfillment, inaccurate revenue reconciliation, or unnecessary customer data being shared with someone who does not need it.

Before installation, check four areas: the technical baseline, your order structure, user permissions, and the future path of the file. The technical baseline includes an up-to-date WordPress installation, active WooCommerce, a working admin area, and a backup. Order structure means statuses, product variations, custom fields, extra product options, and shipping fields. User permissions determine who can run the report and who can view exported data. The file path answers a practical question: where the file will go after download, whether that is accounting software, a warehouse spreadsheet, an internal folder, or email.

For a store with a large volume of orders, it makes sense to start with a short test export for a small date range. This is not just a time saver. It also shows which fields are empty, whether amounts are displayed with the right precision, how product variations appear, and whether statuses that should not be part of the calculation are slipping into the report.

After this preparation, you no longer have an abstract task like "set up an export." You have a specific workflow. For example: "Every Monday, export completed orders for physical products from the previous week, including the variation SKU, quantity, recipient name, shipping method, and warehouse note." With a scenario like that, configuration becomes much more precise.

Installation and the first check in the admin panel

The general installation path for a WordPress plugin is standard: open Plugins, go to Add New, use Upload Plugin, select the ZIP archive, click Install Now, and then Activate Plugin. After activation, the documentation points to this WooCommerce menu path: WooCommerce - Export Order Items. This guide does not cover licensing or product purchase, but it is important to understand that readiness is verified not by activation alone, but by the appearance of the report screen and the ability to generate a small test export.

The first check is best done on orders you already understand manually. Choose a small date range, one or two clear statuses, a minimal field set, and either CSV or HTML as the output format. HTML is convenient for quick browser-based validation because you can see headers, rows, and possible warnings immediately. CSV is better for moving data into a spreadsheet, but delimiter, encoding, or local application settings can make it harder to see the real file structure on the first try.

If the export screen opens but there is no data, do not assume the plugin is broken. More often, the problem is in the filters: the date range does not include the target order, the wrong status was selected, a product condition excludes the variation, or the order field does not exist in older orders. For the first test, it is better to disable all extra restrictions, generate a deliberately broad report, and then add filters back one by one.

Result check: after the first export, open one order in WooCommerce and compare it with one row from the report. Verify the order ID, product name, quantity, status, line amount, and selected SKU. If these basic fields match, you can move on to fine-tuning.

Do not leave debug mode enabled as a permanent setting. The documentation states that it is meant for diagnostic output and can corrupt XLSX files. Use it only when you genuinely need to understand why a parameter did not work, then switch back to the normal report format.

Configuring the date range and statuses without missing orders

The report period is one of the most sensitive settings. The plugin supports preset ranges as well as custom start and end dates. In practice, mistakes usually come not from the date itself, but from the end time and mixed time formats. The documentation specifically explains that the period end is treated as an exclusive boundary: if you set the end of the day literally to the last second, you can end up with an incomplete final interval. For a report covering a full day, it is more reliable to set the end to the start of the following day.

Order statuses should be chosen based on the purpose of the report, not out of habit. For a warehouse team, the important orders are usually the ones that still need to be processed or are ready to be packed. For accounting, paid and completed orders are usually the focus. If you want to analyze failed or abandoned outcomes, you can review canceled or failed orders separately, but mixing them into a working fulfillment export is risky.

How to choose statuses for a typical report

Start with one question: what does a row in this file actually represent? If the row is supposed to mean "this item needs to be packed and shipped," then include only the statuses that match your processing logic. WooCommerce separates order states into waiting for payment, pending confirmation, processing, completed, canceled, refunded, and payment failed. A report across all statuses can be useful for auditing, but it is not a good fit for everyday warehouse work.

• For order fulfillment, use the statuses your team actually works with when handling items.
• For financial reconciliation, separate paid, completed, and refunded rows so that sales and adjustments are not mixed together.
• For problem analysis, temporarily include canceled or failed orders, but save that as a separate preset.
• For a period-based report, verify the boundary orders: the earliest and latest orders should appear in the file exactly as expected.

Why the end boundary matters more than it seems

If a report covers a day, week, or month, the end boundary needs to be obvious to the person reconciling the file. Boundary errors are rarely visible right away: the total amount looks almost correct, the row count is off by only one or two entries, and the reason becomes clear only during manual review. That is why it helps to adopt a rule: after changing the date range, always verify the boundary order. Open the last order in WooCommerce that should be included in the report and make sure its row is actually present in the file.

If your store works across multiple time zones or receives orders overnight, also verify the WordPress time zone and the time format in relevant fields. The plugin should not be expected to compensate for incorrect site settings. It builds the report from the data it receives from WooCommerce and WordPress.

Filters by products, roles, and custom fields

The most valuable part of AGS Export Order Items Pro begins where a standard "order export" stops being useful. The documentation describes filters by products, categories, product IDs, tags, statuses, customer roles, order fields, and product fields. That lets you avoid exporting the entire store and instead build a file for a specific process.

A typical example is a store selling both physical and digital products. The warehouse only needs physical items from certain categories, accounting needs all paid line items, and the affiliate program manager needs orders from customers with a specific role. One shared report would be overloaded and risky: recipients would see unnecessary fields and end up deleting rows manually. It is better to create several presets with different filters.

Products, categories, and IDs

Filtering by products is useful when the report is built around a specific group within the catalog. You can select all products, products from certain categories, or specific product IDs. To find an exact ID, open the product list in WooCommerce and hover over the product name. WordPress usually shows the ID in a helper line. That approach is better than searching by a similar product name, especially if the catalog contains duplicates, variations, or products with the same opening words in the title.

There is one important limitation: the documentation states that when variable products are filtered by a custom product field, the filter applies to the parent product, not to an individual variation. So if your logic depends on the variation itself, validate the result against real orders with different options. Do not assume that every variation field will automatically become a line-level filter.

Customer roles and guest orders

Filtering by customer role helps separate retail, wholesale, partner, or internal orders. But it only works when the order is linked to a user account rather than placed by a guest. If most buyers check out without creating an account, a role-based report may end up empty or incomplete. In that case, first look at the share of guest orders and decide whether the relevant segment needs a registration requirement.

Custom order and product fields

Order and product fields are especially useful for stores with date-based delivery, internal statuses, supplier labels, extra options, or fields created by neighboring plugins. The logic is straightforward: you choose a field, set a condition, and get only the orders or rows where that condition is met. The important detail is that you need the exact field ID. The nice label you see in the admin interface and the technical key stored in the database may not be the same thing.

If the field you need does not appear in the list, check whether it actually exists in orders from the selected period. Some fields appear only after an order is placed with a specific shipping method, coupon, or product option. For the first test, create a fresh test order where the field is definitely populated, and only then configure the filter.

Order lines, variations, free items, shipping, and refunds

This is where the guide becomes product-specific, because this is where AGS Export Order Items Pro differs from a general order report. The report is built around order lines, which means you need to decide in advance which line types count as working data. A single order may include products, variations, shipping, discounts, refunds, and additional line types created by other extensions. If you include everything, the file will be complete but not always convenient. If you exclude too much, you may lose important information.

One row per product or one row per order

The Lines per order setting changes the meaning of the export. When the report outputs one row for each product line, the warehouse sees the actual products and quantities. When one row per order mode is enabled, it becomes easier to see order-level information without repeating customer data for every item. But that file is less suitable for fulfillment: if an order contains several products, the level of detail is no longer enough.

Choose the mode based on the recipient. If the file is for the warehouse, line-level detail is almost always the right choice. If the file is for a manager calling customers or checking addresses, one row per order may be cleaner. If the file is for accounting, test both modes on the same order with multiple products, a discount, and shipping. That is the fastest way to understand which format presents totals more clearly.

Variations and SKUs

SKU handling for variable products is a common trap. In the WordPress forum, one user described a situation where the export was expected to show the variation SKU, but the parent product SKU appeared instead. The developer's reply clarified the difference between a product field and an item-level field that, in the Pro version, can account for the purchased variation. The practical conclusion is simple: if your warehouse works by variation SKU, add the fields specifically tied to the order item and variation to your test report, then compare the file against the order screen.

The check should be concrete: create or find an order where the same parent product was purchased in different variations. Export the order ID, item name, SKU, variation ID, or another available variation field. If the two rows look identical even though the warehouse treats them as different products, then the selected field setup does not fit your workflow.

Free items and gifts

The plugin can exclude items with a zero gross amount before or after discounts. That is helpful when free gifts should not appear in a financial report. But for the warehouse, a zero-value item may still be a real product that needs to go into the package. So do not automatically exclude free items. First decide what a zero amount means in your store: a payment issue, a gift, a bundle, a sample, a bonus item, or a technical line.

Shipping and refunds

The settings include an option to enable shipping order items. The documentation clarifies that not the full set of built-in fields applies to shipping rows: for those rows, the important fields are shipping method ID and name, gross, tax, and total with tax. If the file is for the warehouse, shipping may need to be included because it determines how the order is sent out. If the file is for product analytics, shipping may just get in the way because it is not a product.

Refunds require an even finer distinction. A refund may appear as a separate adjustment row, a negative value, or something tied to status handling. For a financial report, refunds cannot simply be ignored. For a fulfillment report of current orders, by contrast, refund rows may be unnecessary. Create a separate preset for refunds and label it clearly so nobody mistakes it for the warehouse's working export.

Report fields: how to build a file that is easy to read and easy to import

The fields tab determines what ends up in the file and in what order. The documentation describes several key actions: selecting fields, including fields in the totals row, dragging fields to change order, renaming column headers, and adding a custom field through a dropdown. This is not cosmetic. The order and naming of columns determine whether an accounting system will accept the file, whether the warehouse can filter rows correctly, and whether a manager can quickly find the value they need.

Start with a minimal core

For the first working preset, build a minimal core: order ID, order date, status, product name, SKU or variation field, quantity, line amount, tax, buyer name, shipping method, and the custom field you actually need. Add extra columns only after validation. This lowers the risk of ending up with a wide table where the important columns get lost among dozens of optional ones.

If the report needs to be imported into another system, do not rename headers after the structure is approved. A label like "Variation SKU" may be more intuitive for a person, but an external system may expect a strict header such as item_sku. In that case, create two presets: one human-readable and one system-oriented. The first can use clear business-friendly column names, while the second should preserve the technical headers expected by the target system.

Custom fields and extra options

AGS Export Order Items Pro can include custom fields from the order, order line, product, or variation. Separate documentation for the Extra Product Options Addon explains that a companion addon can split fields from WooCommerce Extra Product Options into separate report fields instead of returning them as a single complex string. That is useful for stores where buyers choose engraving, size, date, color, configuration, or another option that the warehouse needs to see during fulfillment.

If you use those options, verify not only that the column exists, but that the value is readable. Sometimes the field stores an array, a technical key, or a serialized structure. If the value makes no sense to a human, do not send that file directly into an operational workflow. Either use the addon that can break the data apart, or leave the field for the developer and output a human-readable WooCommerce value alongside it.

Totals rows and rounding

The totals row option is useful for financial reconciliation: it lets you quickly see the total quantity, cost, tax, or shipping for the report. But totals only make sense for fields that can actually be summed. Do not enable totals for IDs, names, statuses, or text fields. The documentation also warns about tiny fractional tails caused by PHP's limited calculation precision. In normal reports, this is handled by rounding settings and by displaying the appropriate number of decimal places.

Short takeaway: a good export file does not start with a long list of columns. It starts with a clear purpose. If the recipient cannot explain why they need a specific column, that column should probably be removed from the working preset or moved to a separate technical report.

Presets as the foundation of repeatable reporting

Presets are one of the strongest practical arguments for the Pro version. You set up the period, statuses, filters, fields, column order, and format once, then save that configuration under a clear name. Later, the report can be run from the presets tab, edited through the pencil icon, saved with changes, or used as the basis for a new preset.

A preset name should answer three questions: who the file is for, what period it covers, and what it contains. A bad name is "Report 1." A good name is "Warehouse - completed orders - line items" or "Accounting - paid orders - amounts and taxes." If you use several similar reports, include the distinguishing detail in the name: category, customer role, file format, or whether refunds are included.

How not to break a working preset

Before editing a preset that people already use, make a copy. The documentation explains that after loading a preset, you can change the settings and save them back to the original preset with Save Changes, or create a new one with Create New Preset. For a live store, the safer approach is to create a new preset first, validate the file on a short test period, and only then replace the old workflow.

Be especially careful when changing fields and column order if the file is imported into an external program. For a person, a column moved from one position to another may barely register. For an import process, it can be a critical failure. If the file structure changes, warn every recipient and keep the previous preset available during the transition.

Using it with automated report delivery

The official materials mention integration with Scheduled Email Reports for WooCommerce, a companion plugin that can send saved reports on a schedule. That does not mean automation is necessary for every store. It becomes useful when a report needs to arrive on a strict cadence: for example, the warehouse gets a file every morning, accounting gets a weekly summary, or a marketplace manager gets a report for a specific seller role.

The safe order of setup is this: first build a manual preset, then validate the file on a short period, then connect the schedule, and only after that extend the date range. If the site has low traffic and depends on WP-Cron, scheduled delivery may be delayed. The Scheduled Email Reports documentation explicitly notes that WP-Cron is triggered by site visits, so for mission-critical emails you should configure an external scheduled check through your hosting environment or a scheduling service.

Output formats and file validation after export

AGS Export Order Items Pro supports several formats: CSV, CSV-ASCII, XLS, XLSX, HTML, and HTML Enhanced. The format should not be chosen at random. The same report may be convenient for browser review in HTML, for spreadsheet work in XLSX, and for import in CSV. It is better to define one primary format in advance and one backup format for troubleshooting.

When to choose CSV

CSV is still the most universal option for data exchange. It is accepted by spreadsheets, warehouse systems, accounting programs, and internal scripts. The downside is that the display depends on the delimiter, encoding, and settings of the application opening the file. If characters display incorrectly or all data lands in a single column, that is not always the plugin's fault. Often the file simply needs to be imported through a spreadsheet import wizard with the correct encoding and delimiter selected.

When to choose XLSX or HTML

XLSX is convenient for people who work in Excel or similar tools and do not want to import CSV manually. HTML is useful for quickly checking structure, especially when you are adding new fields, totals, or debug output. HTML Enhanced can be useful for viewing, but for importing into external systems, CSV or XLSX is usually the better choice.

Validate the result after every change

After changing filters, fields, or format, run a short validation against one well-understood order. That is faster than hunting for an error later in a large file. Open the order in WooCommerce and the report side by side. Verify not only the totals, but the meaning of the rows: a product line should not turn into a shipping line, the variation should be distinguishable from the parent product, refunds should appear as expected, and empty fields should have a clear explanation.

1. Generate a report for a small period that contains a known order.
2. Open the file in the same program the recipient will use.
3. Compare the order ID, status, product, quantity, SKU, line amount, and shipping.
4. Check the boundary order for the period to rule out an end-time mistake.
5. Save the preset only after the file structure has been confirmed.

If the file is meant for an external contractor, do not send a full report with personal data just for testing. Create a short file with a minimal number of rows and only the required columns. That is usually enough to validate the format.

Practical scenario: a weekly file for the warehouse and accounting

Let us look at a workflow that often comes up in a store selling physical products with variations. Every week, the store needs to export completed and processing orders, send the warehouse a list of items to fulfill, and give accounting the line amounts and taxes. One shared file would be too wide for the warehouse, so we will build two presets based on the same reporting logic.

Goal

Create repeatable reports without manually deleting unnecessary columns: the warehouse sees line items and shipping, while accounting sees amounts, taxes, discounts, and refunds. Both files use the same date range so both teams are reconciling the same orders.

Preparation

Before setup, you need active WooCommerce, the installed plugin, several real or test orders with different products, at least one variable product, one order with shipping, and one order with a discount. If refunds matter for accounting, add a test order with a refund on a site copy or use an existing example that is easy to verify.

Steps for the warehouse preset

1. Open WooCommerce - Export Order Items and set the date range for the target week.
2. Select the statuses the warehouse actually uses when fulfilling or checking orders.
3. In the product filters, keep all products or limit by category if the warehouse handles only part of the catalog.
4. In the fields tab, include the order ID, date, product name, SKU field or item field, quantity, variation, recipient name, and shipping method.
5. If shipping needs to appear as a separate row, enable shipping order items and verify that the warehouse understands those rows.
6. Choose CSV or XLSX depending on the warehouse team's usual tool.
7. Save the preset with a clear name and run a test export.

Steps for the accounting preset

1. Load the warehouse preset settings as a starting point, but save them as a new preset instead of overwriting the old one.
2. Add the line amount, post-discount amount, tax, total with tax, shipping, and discount fields.
3. Decide whether refunds belong in the main report or should live in a separate adjustments preset.
4. Enable the totals row only for numeric fields that actually need to be summed.
5. Configure amount rounding to remove unnecessary fractional tails from calculations.
6. Generate an XLSX file for manual review and a CSV file for import if the external system accepts CSV.

Validation and an important nuance

After exporting, pick one order with multiple products and compare it in both files. In the warehouse file, product rows and the shipping method should be easy to read. In the accounting file, amounts and taxes should match. If the variation SKU does not match expectations, return to the fields tab and verify which SKU field is being used. If the last order of the week is missing, review the period end date and time.

Expected result: two presets generate files for the same period but with different structures. The warehouse does not see unnecessary financial columns, accounting does not lose amounts, and the store owner can repeat the export without rebuilding the spreadsheet by hand.

Compatibility with HPOS, caching, and companion plugins

WooCommerce is gradually moving order data into separate High-Performance Order Storage tables. This matters for export plugins because older queries to wp_posts and wp_postmeta do not always return the right result under the new storage model. The AGS Export Order Items Pro changelog includes HPOS-related fixes for filtering by order fields, showing order meta in the dropdown, and filtering by customer roles in conditions involving large user counts. That means if HPOS is enabled, you should test filters, custom fields, and older presets especially carefully.

The practical validation is simple. First check whether HPOS is enabled under WooCommerce - Settings - Advanced - Features. Then generate a small report with standard fields and a separate report with a custom order field. If both reports match the order screens, you can move to the working date range. If custom fields do not appear or a filter behaves strangely, check that you are on a current plugin version, review the changelog, and temporarily fall back to a simpler filter before contacting support.

Cache and temporary files

Export output should not be cached like a normal public page. Both the paid product changelog and the free version mention fixes related to browser caching and temporary report files. The practical takeaway for a store owner is simple: do not manually store reports in public folders, do not treat a temporary file link as a permanent URL, and do not try to "speed up" exports with caching plugins. If a caching plugin interferes with the admin area, exclude report pages from aggressive admin-side optimization.

Using Frontend Reports

Frontend Reports for WooCommerce can display a report or a download link through a shortcode or widget by using a preset from a compatible reporting plugin. That combination can be useful for a private internal page where a manager downloads a ready-made report without opening the full settings screen. But the documentation warns that anyone with access to the page or post containing the report can view the data. So do not place reports with personal data on public pages, and do not assume the shortcode alone is a permission system.

A safe setup looks like this: the preset is created and validated in AGS Export Order Items Pro, page access is restricted through the site's normal protection tools or a private section, Frontend Reports shows only the required preset, and a test user verifies that they cannot see other reports. If different roles need access, it is better to create separate pages and separate presets with only the minimum fields each role needs.

Safe improvements without editing plugin code

For this product, it is not a good idea to invent PHP hooks or edit plugin files. Public sources do not provide a strong enough foundation to recommend a universal code snippet for changing export logic. What you can do instead is apply several safe improvements based on the product's own settings and standard WooCommerce practice.

Separate presets instead of one universal report

Create presets by role, not by the mood of whoever built the report. One preset for the warehouse, one for accounting, one for refund analysis, one for custom fields. That reduces the risk of accidentally sending unnecessary personal data or deleting required columns before import. When the workflow changes, create a new preset and mark the old one as archived until the team confirms the transition.

HTML as a control format before CSV

When you add a new filter or field, check the result in HTML first. This is especially useful for validating the date range, empty fields, and totals. Once the structure is confirmed, switch to CSV or XLSX. If you need debug mode, use it only with HTML, because the documentation warns that this output can damage XLSX files.

Data minimization for personal information

Do not include every customer field in the working file just in case. The warehouse may need a name, city, phone number, and shipping method, but not a full set of payment details. Accounting needs amounts and tax information, but not necessarily customer notes. The narrower the file, the easier it is to protect and the less harm a mistaken forward causes.

If the file will be exchanged with an external system, agree on the exact structure in advance and do not change it without versioning the preset. Inside WordPress, you can keep clear preset names, while the file itself can preserve the technical headers expected by the external system. It is not glamorous, but it is extremely practical discipline.

How to manage presets so reports do not drift across teams

Once the first successful setup is in place, a new problem appears: reports begin to take on a life of their own. One manager changes the period, another adds a field, accounting asks for a renamed column, the warehouse wants refunds removed, and a month later nobody is sure which file is the correct one anymore. With AGS Export Order Items Pro, this is especially relevant because presets are easy to edit and quickly become working templates for different people.

The most reliable approach is to treat a preset like a small internal document. It should have a name, an owner, a purpose, a list of recipients, and a control order used for validation. This does not require a separate system. A short note in your internal documentation or project task is enough. That note should record the fields, statuses, date range, file format, and the exact situations in which the preset is allowed to change.

A control order as your benchmark

Pick one order that captures the complexity of your store well: a variable product, a discount, shipping, a populated custom field, and, if relevant, a refund. Do not use a real customer order in public instructions, and do not distribute it to people who do not need access. But inside a closed team, a control order makes it much easier to see whether the report structure has broken after a plugin update, enabling HPOS, or changing a neighboring extension.

The validation process is simple: after changing a preset, export a short period that includes the control order and compare the expected values. The variation SKU should match the order screen. Shipping should either appear as a separate row or be absent according to your rule. The totals row should sum only numeric fields. The custom field should be populated with a meaningful value, not technical noise. If even one of these checks fails, the preset is not ready for the working date range.

Preset names and the rule "do not edit without a copy"

It helps to use a stable naming pattern: role, period, contents. For example, "Warehouse - week - line items" or "Finance - month - taxes and refunds." If one preset is meant for manual review and another for import into an external system, split them immediately. A human-readable file can use clear business labels, while a system file should preserve the expected technical column names.

A working preset should never be edited directly right before an urgent export. First load it, save it as a new preset, make the changes, validate the control order, and only then decide whether to replace the old version. That discipline can feel excessive while the team is small. It pays off quickly once the same report is used by the warehouse, accounting, support, and an outside contractor.

What to document after updates

The product changelog shows that updates can affect HPOS, field-based filtering, shipping methods, time warnings, temporary files, and output behavior. That is normal for an export plugin because it depends on WooCommerce's data model and order structure. After an update, you do not need to recheck the entire store, but you should rerun the control order export and compare the fields that matter most to your workflow.

• After WooCommerce changes, verify statuses, HPOS, and custom order fields.
• After product option changes, verify variation fields and extra order-line parameters.
• After shipping changes, verify shipping rows and shipping method fields.
• After changing the file format, verify encoding, delimiter, headers, and the totals row.

If you cannot explain why a field changed, do not hide the issue by manually editing the spreadsheet. It is better to temporarily roll back to the previous preset, document the symptom, and trace the field source. Manual file edits are acceptable as an emergency step, but they should not become a permanent part of your reporting process.

Sharing exports and handling personal data

Exports from WooCommerce almost always contain customer data. Even if the file looks like a normal product table, it may include a name, phone number, email address, shipping address, order notes, and internal labels. That means configuring AGS Export Order Items Pro is not just about asking "which fields do we need," but also "who is allowed to see those fields." This matters even more when the report is sent to a contractor, an outsourced warehouse, an external accountant, or a marketplace manager.

Start with the principle of the smallest sufficient file. For fulfillment, you usually need the product, quantity, variation, shipping method, and a limited set of contact details. For financial reconciliation, you need amounts, taxes, discounts, refunds, and order identifiers. For sales analysis, anonymized product lines without addresses are often enough. If one recipient asks for "all the data," ask what action they actually perform with each column.

A safe path for the file after download

Responsibility does not end when you click Export. The file may land in the browser's downloads folder, a cloud drive, an email thread, a chat, or an accounting system. Do not send the file through random channels if it contains personal data. It is better to define the storage location and retention period in advance. Old order files should not remain indefinitely on employees' personal computers.

If you use Scheduled Email Reports, configure recipients as strictly as you configure admin access rights. If you use Frontend Reports, check the page through a test user account. The Frontend Reports documentation explicitly warns that access to the page means access to the report. So a private report page should be protected not only from indexing, but also from accidental viewing by someone who should not see it.

How to prepare a file for an external system

When a CSV or XLSX file is sent to an external system, a separate risk appears: the recipient may silently ignore extra fields, misread the column order, or interpret the encoding incorrectly. For the first exchange, create a small test file with a few orders and agree on the structure in advance. Document the column names, amount format, delimiter, encoding, whether a header row is included, the rounding rules, and how empty values should be handled.

If the external system expects only product lines, do not include shipping rows and refunds in the same file unless that has been agreed upfront. If shipping needs to be included, label it as a separate line type or use a separate preset. If refunds should reduce totals, verify how the recipient handles negative values. A mistake here may not show up inside WordPress at all, but it will surface later in the warehouse or accounting system.

Practical rule of thumb: every working file should have one clearly defined owner. If nobody is responsible for the preset structure and the control-order check, the report gradually turns into a collection of random columns.

Troubleshooting common export problems

Problems in export plugins often look similar: "no data," "wrong SKU," "empty field," "broken file," "totals do not match." But the causes are different. Below is a troubleshooting guide tied specifically to AGS Export Order Items Pro and WooCommerce, not a generic checklist for any extension.

The report contains no orders

Symptom: the file is generated, headers are present, but there are no order rows. Possible causes include a date range that does not include the target orders, unsuitable statuses, an overly narrow product filter, or a custom field filter that is too restrictive. First disable the extra filters, keep a simple date range, and include several working statuses. If rows appear, add the restrictions back one at a time.

When to roll back the setting: if adding one specific filter makes the report go empty, do not save that preset as a working version. Create a copy and check whether the selected field or product category actually exists in the target orders.

The last order in the period is missing from the file

Symptom: the report is almost correct, but the order on the date-range boundary is missing. The documentation explains the exclusive end boundary and time format errors. Check whether 24-hour time and AM/PM were mixed, and set the end of the period to the start of the next day for a full-day interval.

Validation: find the last order in WooCommerce that should be included in the report and compare its timestamp with the configured period end. If the order was placed right around the end of the day, change the range and rerun the test on a short interval.

A variable product shows the wrong SKU

Symptom: the warehouse sees the parent product SKU instead of the SKU for the specific variation. In the WordPress forum, the developer explained a similar case as the difference between a product SKU and an item-level or variation-level SKU. The Pro version includes fields that can account for the purchased variation, but they must be selected explicitly.

Fix: add fields related to the line item and variation, then test the file on an order containing two variants of the same product. If the field you need is missing, check the plugin version and the variation structure in WooCommerce.

A custom field is empty or does not appear

Symptom: the field exists on the order or product, but it does not show up in the report. Possible causes include the field not being populated in orders from the selected period, a mismatch between the technical key and the visible label, data stored in a complex format, or an outdated plugin version under HPOS. Start with a fresh test order where the field is definitely filled in.

Fix: add the field through the custom fields dropdown, verify it in an HTML report, and only then move it into the working preset. If the field is created by an extra options plugin, consider the Extra Product Options Addon if it fits your data source.

XLSX shows errors or the file looks corrupted

Symptom: the file does not open, opens with a warning, or contains unwanted diagnostic output. The documentation clearly states that debug mode is intended for HTML and may corrupt XLSX. Disable debug mode, rerun the export in HTML for troubleshooting, and then generate the XLSX file again without diagnostic output.

When to contact support: if XLSX breaks even without debug mode and on a small date range, prepare a minimal preset, a list of active plugins, the report format, and a sample order. Do not send a full file with personal data if an anonymized example is enough for troubleshooting.

Totals differ by tiny fractional values

Symptom: numeric fields show extra decimal places. The documentation links this to PHP's limited calculation precision. Enable amount rounding and display the required number of decimal places. If the report is used for accounting, agree on the rounding format before the file enters the live workflow.

When AGS Export Order Items Pro is the right choice

AGS Export Order Items Pro is worth using when you need more than a one-time "snapshot of orders" and instead need a repeatable report built around WooCommerce order lines. Its strengths are filters, field selection and ordering, support for variations and custom data, presets, output formats, totals settings, and compatibility with the developer's companion reporting tools. The plugin delivers the most value when the exported file becomes part of a recurring process: fulfillment, accounting, supplier reconciliation, category analysis, or exporting extra option data.

Before using it in a live workflow, run a short test export and verify the boundary dates, statuses, variation SKUs, free items, shipping, refunds, and custom fields. Then save presets with clear names and do not change the file structure without testing on a copy of the site or over a short date range. If everything matches the order screens and your team understands the purpose of every column, you can download AGS Export Order Items Pro and move on to safe testing in your store.

If, on the other hand, you need order imports, complex remote file delivery, a large migration, or a unified analytics dashboard with charts, review the alternatives listed above. The right choice here depends not on the raw number of features, but on what file your workflow needs and who will be responsible for validating it.