Reviewed and updated June 2026, native export tools, SQL Manager and the CSV encoding traps verified on PrestaShop 1.7, 8 and 9.
At some point every PrestaShop store hits the same wall: the data you need is in the shop, but the people and systems that need it are everywhere else. Your accountant wants order totals split by tax rate. Your warehouse wants today's unshipped orders as a pick list. You want last quarter's invoices in a spreadsheet you can sort and pivot. PrestaShop holds all of it. The question is how to get a clean CSV out of the back office without it arriving as garbled characters, mismatched columns, or a file your accounting software refuses to import.
This guide is specifically about exporting orders and invoices as CSV: what PrestaShop's native tools actually give you, the encoding and locale traps that quietly corrupt those files, and how to pull exactly the columns you need. Exporting the product catalogue is a different job with its own quirks, for that, see product import and export in PrestaShop.
What PrestaShop gives you out of the box
PrestaShop has two native ways to get order data out, and most merchants only know the weaker one.
The list-page Export button
Open Orders → Orders and there's an Export button in the top toolbar. Click it and PrestaShop hands you a CSV of the order list exactly as the grid shows it, and that's the catch. It exports the visible columns of the list (reference, customer, total, payment, status, date), honouring whatever filters you've set on the grid, and nothing more. You can't add the billing VAT number, you can't split the total into net and tax, and you can't pull per-product lines. It's a snapshot of a screen, not a reporting tool. The same button exists on Customers → Customers and the catalogue, with the same fixed-column limitation.
SQL Manager, the powerful tool nobody mentions
The second route is hiding under Advanced Parameters → Database → SQL Manager. This lets you write a read-only SQL SELECT against the database and export the result straight to CSV. Want every order from last month with the customer's VAT number, the invoice total split tax-excluded and tax-included, and the carrier name? That's one query joining ps_orders, ps_customer, ps_address and ps_order_invoice, and SQL Manager exports it with one click.
The honest catch: it requires SQL. The order tables aren't intuitive. Totals live across several columns (total_paid, total_paid_tax_incl, total_paid_tax_excl), invoice data sits in a separate ps_order_invoice table keyed by order, and tax breakdowns are spread across ps_order_detail_tax. Get a join wrong and you'll silently double-count rows or miss orders that have no invoice yet. For a one-off finance request it's the most capable tool in core; for a report you run every month, hand-editing SQL gets old fast. Which is the gap the rest of this guide is about.
To make this concrete, here's a read-only query you can paste into SQL Manager for a monthly accounting export, order reference, both net and gross totals, and the invoice number, for one date range:
SELECT o.id_order,
o.reference,
o.total_paid_tax_excl,
o.total_paid_tax_incl,
oi.number AS invoice_number,
o.date_add
FROM ps_orders o
LEFT JOIN ps_order_invoice oi
ON oi.id_order = o.id_order
WHERE o.date_add >= '2026-06-01 00:00:00'
AND o.date_add < '2026-07-01 00:00:00'
ORDER BY o.id_order;The LEFT JOIN matters: it keeps orders that don't yet have an invoice (an INNER JOIN would silently drop them). It only reads, nothing is written. Add AND o.valid = 1 if you want only orders PrestaShop counts as real sales. This is fine for an occasional pull; the trouble starts when you run the same query, reformat it and email it every week. That repetition is what the no-SQL exporters below remove.
The traps that corrupt a PrestaShop CSV
Most "the export is broken" complaints aren't about missing data, they're about a file that opens wrong. Three things cause nearly all of it, and they're worth understanding because they bite the native export, SQL Manager exports, and any module equally.
| The trap | What you see | Why it happens |
|---|---|---|
| Missing UTF-8 BOM | "Müller" becomes "Müller", "Łódź" turns to mojibake when you double-click the file in Excel | Excel assumes the system locale, not UTF-8, unless the file starts with a byte-order mark telling it otherwise |
| Delimiter vs decimal clash | A €1.299,00 total spills across two columns, or rows shift sideways | In comma-decimal locales (DE, FR, PL) the spreadsheet treats the comma as a column separator and the CSV delimiter collides with the number format |
| Unquoted text fields | An address with a comma ("12, Rue de la Paix") breaks into two columns and every column after it shifts | Free-text fields that contain the delimiter character must be wrapped in quotes; if they aren't, the row's structure falls apart |
The fixes are unglamorous but absolute: write the file as UTF-8 with a BOM so Excel reads accents correctly on a double-click; keep dots as the decimal separator and let the importing software localise; and quote every text field that could contain a comma, quote or newline. A well-built export does all three for you. When you roll your own via SQL Manager, the BOM in particular is the one you'll forget, and it's why the same data looks fine in Google Sheets but mangled in a colleague's Excel.
Beyond the built-in export: choosing your columns and filters
The real day-to-day need isn't "all orders", it's "these orders, with these columns." Different jobs need different shapes of the same data, and that's exactly what the native list Export can't do. This is the reason our Orders CSV List Exporter exists: it adds a proper export screen to the back office where you pick the columns and narrow the rows, without writing a line of SQL.
So what does that mean in practice? You choose from grouped columns, Order information, Invoice / delivery-slip numbers, Totals (every tax-excluded and tax-included figure separately), Customer, the full Delivery and Invoice addresses including VAT number, and product lines, and tick only the ones a given report needs. Then you narrow the rows by date range, one or more order statuses, and payment method, in any combination. "All paid-and-shipped orders from last month, with invoice numbers and tax-split totals" becomes a few clicks rather than a query. It writes UTF-8 with the BOM and proper field quoting, so the file opens cleanly in Excel on the first try. The traps above are handled for you. It runs entirely from the back office and reads your live data without touching core, so an upgrade can't break it.
Let's be precise about what it is and isn't: it's an on-demand export you run when you need it, with the columns and filters you choose, not a scheduler, an FTP uploader, or an email-out pipeline. If your goal is a finance-ready or warehouse-ready file pulled in seconds without SQL, that's exactly the job it does.
Invoices are their own export
Invoice data isn't just "orders with a different name." An invoice is a legal accounting document with its own sequential number, its own date, its own per-tax-rate breakdown, and it may not always map one-to-one with an order. For accounting you usually want the invoice as the unit, not the order. Which is why our Invoice CSV List Exporter is a separate tool, filtering by date range, order status and payment method and outputting a CSV shaped for accounting import rather than warehouse picking.
One upstream point worth flagging: an export is only as clean as the numbering behind it. If your invoice numbers have gaps or restarts, common after testing, or when PrestaShop's default sequence resets oddly, your accountant will reject the file regardless of how tidy the CSV is. Sequential, gap-free numbering is what our Invoice Number module is for, and it's worth getting right before you start exporting for tax reporting.
Common export jobs, and how to shape them
Monthly accounting
Filter to the month's date range and the statuses that count as a real sale (typically Payment accepted, Shipped, Delivered, not Cancelled or Payment error). Include invoice number, invoice date, the net and gross totals, and the customer VAT number. Hand that to your accountant or import it into your accounting software directly. Doing this from the invoice exporter keeps the unit correct for the books.
Warehouse pick lists
Filter to today's date and the "to-prepare" statuses, include product lines, quantities and the delivery address, and skip everything financial. This is fundamentally an order-fulfilment task; if your picking and packing flow is where time leaks away, the export is one piece of a bigger picture covered in order management workflows that save you hours.
VAT and OSS reporting
For EU One-Stop-Shop declarations you need sales broken down by destination country and tax rate. Export the invoice totals with the delivery country and the per-rate tax figures, then pivot in your spreadsheet by country. This is the export where the BOM and decimal-separator handling matter most. A comma-decimal slip can silently inflate a country's total.
Customer segmentation
Exporting customers and their purchase history for a marketing platform is a related but distinct need, it pulls from the customer list, not orders, and feeds email tools rather than your accounts. Rather than stretch this guide across it, that's its own topic; the order export here is for finance and fulfilment.
Frequently asked questions
How do I export orders from PrestaShop to CSV?
Two native routes. The Export button on Orders → Orders gives you the visible grid columns, honouring your filters. Quick, but you can't add fields like the VAT number or split totals into net and tax. For full control, Advanced Parameters → Database → SQL Manager runs a read-only SELECT and exports the result; it's the most capable core tool but requires SQL. For repeatable, no-SQL exports with chosen columns and filters, the Orders CSV List Exporter adds a proper export screen.
Why does my exported CSV show garbled characters like "Müller"?
Excel is reading the file as the system locale instead of UTF-8 because the file has no byte-order mark (BOM). Write the CSV as UTF-8 with a BOM and accented names render correctly on a double-click. This is the trap you'll forget when rolling your own export via SQL Manager, it's why the same file looks fine in Google Sheets but mangled in a colleague's Excel.
Why do some rows shift sideways or split into extra columns?
Two causes. In comma-decimal locales (DE, FR, PL), a total like €1.299,00 collides with the CSV's comma delimiter and spills across columns. Keep dots as the decimal separator and let the importing software localise. And any free-text field containing a comma ("12, Rue de la Paix") must be wrapped in quotes, or it breaks the row. A well-built export quotes every text field that could contain the delimiter, quote or newline.
Should I export orders or invoices for my accountant?
Invoices, usually. An invoice is a legal document with its own sequential number, date and per-tax-rate breakdown, and it may not map one-to-one with an order, so for the books you want the invoice as the unit. The Invoice CSV List Exporter outputs a CSV shaped for accounting import. First make sure your invoice numbering is gap-free (testing often leaves gaps); the Invoice Number module handles that, and it's worth getting right before you export for tax reporting.
When is it worth automating exports instead of running them by hand?
When someone logs in, runs the same export with the same filters, reformats it and emails it to the same person every week, that's a process, not a task. For genuinely real-time, system-to-system flow (orders pushed into an ERP as they're placed), PrestaShop's web service API is the path, with Zapier or Make routing files onward. Below that bar, a fast, filtered, correctly-encoded on-demand export is less brittle than a pipeline you have to maintain.
When to automate, and when not to bother
Manual exports are completely fine for occasional needs, a one-off finance request, an ad-hoc analysis. The honest test is frequency and repetition: if someone on your team logs into the back office, runs the same export with the same filters, reformats the file and emails it to the same person every single week, that's a process worth automating, not a task worth doing by hand. PrestaShop's web service API is the path for genuinely real-time, system-to-system data flow (orders pushed into an ERP as they're placed), and tools like Zapier or Make can route a generated file onward. For everything below that bar, a fast, filtered, correctly-encoded on-demand export is not just good enough. It's less brittle than a pipeline you have to maintain.
The principle underneath all of it: PrestaShop already holds clean, structured order and invoice data. Getting it out well is mostly about two things, pulling exactly the columns and rows a given job needs, and writing a file that opens correctly in whatever software reads it next. Get those two right and "getting the data out" stops being a recurring headache and becomes a thirty-second task.
