Connecting PrestaShop to your accounting software: Xero, QuickBooks and more

Last reviewed June 2026. OSS rules current as of the post-2021 EU regime; back-office paths verified against PrestaShop 1.7, 8.x and 9.x. Always confirm tax treatment with your own accountant.

Here is the distinction that decides how painful your month-end is: PrestaShop is the system that takes the money, and your accounting software is the system that has to explain the money to a tax authority. Those are not the same job. Your store records an order with a customer, a carrier, a payment method and a cart of products. Your accountant needs a sequentially numbered invoice, a revenue account, a tax code, and a credit note for every refund, in a format that reconciles to the cent. Connecting the two is the work of translating one model into the other. Get the translation right and the books close themselves; get it wrong and you are hand-reconciling VAT at 11pm on the last day of the quarter.

This guide is specifically about wiring PrestaShop into accounting software, Xero, QuickBooks and the others, so that orders become correct, auditable invoices without retyping. It is not about connecting PrestaShop to a full ERP for stock and purchasing (that is a different problem with a different shape, see connecting PrestaShop to your ERP and, for the "when do I need it" question, when your store outgrows manual work). Here, the scope is the ledger: invoices, tax, refunds, fees, and the numbers your accountant signs off.

What actually has to flow from PrestaShop to the books

Before you pick a tool, get clear on what data the connection has to carry. PrestaShop already generates most of it. The integration's job is to map each piece to the right place in your chart of accounts, not to recreate it. The objects that matter live in well-defined PrestaShop tables, and knowing their names tells you exactly what an integration is reading:

• The invoice, not the order. A PrestaShop order (ps_orders) is not yet an accounting document. The invoice is a separate object (OrderInvoice / ps_order_invoice) generated when the order reaches an invoicing state, and it carries its own number. Your books care about the invoice. Sync orders that have no invoice and you will create revenue that doesn't legally exist yet.
• Tax, broken down per rate. PrestaShop stores tax per line and per invoice (ps_order_detail_tax, ps_order_invoice_tax). A single order can carry two or three different VAT rates, standard-rate goods, reduced-rate goods, zero-rated shipping. The integration has to preserve that breakdown, not just a single total.
• Refunds and cancellations as credit notes. A refund in PrestaShop is a credit slip (OrderSlip / ps_order_slip), with its own sequential number. In your accounting software it has to land as a credit note against the original invoice, not as a negative sale, and never as a silent deletion.
• Payment versus invoice. What the customer paid (ps_order_payment) and what you invoiced are two events. Marking an invoice "paid" in the books should be driven by the payment record, so cash and revenue reconcile separately.
• Gateway fees and shipping. Stripe and PayPal take a cut before the money lands; shipping income (what the customer paid) and shipping cost (what you paid the carrier) are two different lines. None of this is visible in a naive "order total → revenue" sync.

So what? If you can name these five flows, you can evaluate any connector in five minutes, you simply ask which of them it handles and which it quietly drops on the floor.

The decision before the tool: who owns the invoice number?

This is the single choice that shapes every accounting integration, and most guides skip it. In nearly every jurisdiction, sales invoices and credit notes must be sequential and unique, and in some jurisdictions the sequence must be gapless, or any gap must be explainable and auditable. The question is which system is the source of truth for that sequence.

If PrestaShop owns the numbering, the native sequence is configurable but blunt, and an unexplained gap (a cancelled or missing invoice, a manual database change, a failed migration, or a badly configured sequence reset) is exactly the kind of thing an auditor flags. Two of our modules exist for precisely this control point: Invoice Number and Order Number let you set the prefix, the starting value and the format so your PrestaShop documents follow the gapless, per-year sequence your accountant expects, instead of fighting the core's defaults. The benefit is narrow but real: the document your customer downloads and the document your accountant files carry the same, legally valid number, so reconciliation is a lookup, not an investigation.

Xero

Xero is the common choice for UK and European stores, and it earns it: a well-documented API, native multi-currency, and VAT handling that holds up across borders. For PrestaShop the connection is almost always indirect, a middleware service or a dedicated module reads invoiced orders and creates corresponding Xero invoices, because Xero has no PrestaShop-native plugin of its own.

The four things that actually determine whether a Xero connection is correct:

• Chart-of-accounts mapping. Your PrestaShop categories (or products) have to map to Xero revenue accounts. A store that sells physical goods and digital downloads usually wants those in separate accounts, decide the mapping before the first sync, because re-mapping after thousands of invoices is grim.
• Tax-rate mapping. A PrestaShop tax rule (Back Office → International → Taxes → Tax Rules) is not the same object as a Xero tax rate. You map each one explicitly: PrestaShop "FR Standard 20%" to Xero's matching rate, and so on for every country you sell into. Skip one and that country's sales post with the wrong, or no, tax.
• Payment status. An invoice should only be marked paid in Xero when PrestaShop confirms payment. Drive it from the order's paid state, not from invoice creation, or your cash position will read high.
• Multi-currency. If you sell in GBP, EUR and USD, let Xero own the exchange rates and post invoices in the currency of sale. Don't pre-convert in the integration, you'll lose the audit trail of the original-currency amount.

The most common Xero mistake is syncing too much. Start with invoiced, paid orders only. Draft orders, abandoned carts and pending payments have no business in your books until money has changed hands.

QuickBooks Online

QuickBooks Online is common for US merchants and is usable in some European setups too, with a mature connector ecosystem, most middleware platforms support it out of the box. Whether it actually suits a European store depends on your local tax and e-invoicing requirements, so check those before committing. The wrinkle for cross-border sellers is that QuickBooks models sales tax (US, destination-based, per state/county) very differently from VAT (EU). If you sell in both, the integration has to create the right tax entry based on the customer's location. A US order gets a sales-tax line, an EU order gets a VAT line, and that logic lives in the connector, not in QuickBooks.

Practical configuration that pays off:

• Use classes or locations. If you run more than one PrestaShop store (a separate shop per country, say), QuickBooks classes let you keep each store's revenue separable in the P&L without a second QuickBooks file.
• Batch, don't stream. Real-time sync sounds appealing; a daily or hourly batch is more reliable and far easier to debug when one invoice fails. You want to find a problem in a batch of 40, not chase it through a live stream.
• Decide the product granularity. Does each PrestaShop product become a QuickBooks item, or do you aggregate revenue by category? Per-product gives you product-level reporting and a much larger item list to maintain; per-category keeps QuickBooks lean. Most stores are happier aggregating.
• Mirror credit slips to credit memos. A PrestaShop credit slip should create a QuickBooks credit memo against the original invoice, same amount, same tax treatment.

The other platforms, and why your country decides

Xero and QuickBooks dominate the English-language conversation, but the right tool is usually whatever your local accountant and tax authority expect. The integration approach shifts accordingly:

• Sage, long-established in the UK and France, common for larger businesses; the integration approach depends on the Sage product, with options ranging from API connectors (Sage Business Cloud, Intacct) to middleware and scheduled exports.
• Datev, the de-facto standard in Germany, because most German tax advisors (Steuerberater) work in it. They rarely want an API; they want a Datev-compatible export they can import. For these accountants, a clean CSV/export pipeline beats any real-time connector.
• Fakturownia / inFakt / wFirma, Polish invoicing and tax platforms. Polish numbering and JPK reporting rules are strict, which makes the "who owns the invoice number" decision above especially load-bearing here.
• Fattura24 / Aruba, Italy mandates electronic invoicing (fatturazione elettronica) through the SDI exchange system. These platforms handle the SDI submission; your PrestaShop integration's job is to feed them a correctly structured invoice, not to talk to SDI directly.
• FreshBooks / Debitoor-style tools, simpler invoicing for micro-businesses and freelancers, usually fed by export rather than deep integration.

For any platform without a turnkey connector, the integration almost always comes down to a structured export that the accounting software (or your accountant) imports on a schedule. That is not a downgrade. For a Datev or Fattura24 workflow it is exactly what the receiving side wants.

What an accounting export file actually contains

If the export route is yours (Datev, JPK, "just send me a CSV"), it helps to know what columns the receiving side expects, because a clean header is most of the battle. The accountant's import doesn't want your storefront's order view, it wants invoice-level rows with the tax broken out per rate. A workable CSV header for a sales-invoice export looks like this:

invoice_number,invoice_date,order_reference,customer_name,customer_vat_number,country,currency,net_amount,tax_rate,tax_amount,gross_amount,payment_method,document_type
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,200.00,0.00,0.00,200.00,bankwire,invoice
INV-2026-000412,2026-06-18,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,50.00,19.00,9.50,59.50,bankwire,invoice
CN-2026-000031,2026-06-20,XKBKTSXPM,"ACME GmbH",DE811234567,DE,EUR,-50.00,19.00,-9.50,-59.50,bankwire,credit_note

Two things to notice: each tax rate gets its own row (so a multi-rate invoice spans several lines that sum to the document total), and a refund appears as a credit_note with negative amounts against the original order_reference, never as a deleted or edited invoice row. Confirm the exact column names and date format with your accountant before the first run; Datev and JPK each have their own required layout, but the shape, one row per rate, credit notes as negatives, is constant.

Two roads into the books: native module vs middleware

Once you know what has to flow and who owns the numbering, there are two realistic ways to actually move the data. They are not mutually exclusive. Plenty of stores run a module for invoices and a middleware connector for a specific platform, but it helps to see the trade-off cleanly.

On the module side, our Financial Revolution module handles invoice generation, numbering and export in formats your accounting platform can consume. When the deliverable is a clean file on a schedule, the Datev or JPK case, Invoice CSV List Exporter pulls the invoice and per-rate tax data your accountant imports, while Orders CSV List Exporter covers the raw order side when that's what the receiving system wants. The practical upshot: you can stand up an accurate accounting feed from the back office, with no recurring middleware bill and no order data leaving your server. Which is often the deciding factor for a Datev or JPK workflow where the accountant just wants a clean file on a schedule. (And if that schedule should be hands-off, Cron Manager is what runs and records the recurring export so a missed run is visible, not silent.)

Middleware earns its subscription when you want a live, hands-off sync to Xero or QuickBooks specifically and value the built-in retry, logging and pre-mapped connectors. If your reason for reaching for Zapier or Make is broader store automation rather than the ledger itself, that's a different topic. The mechanics of building those workflows are covered in Zapier and Make for PrestaShop and the no-code angle in automating workflows without writing code.

Cross-border VAT: the part that turns an accounting task into a legal one

If you sell across EU borders, VAT is where an accounting integration stops being a convenience and starts being compliance. PrestaShop captures the raw facts; your books have to report them correctly.

• OSS (One-Stop Shop). Since July 2021, an EU store can report VAT for all member states through a single OSS return, but only if your records know which country's rate applied to each sale. PrestaShop already stores the destination and the applied tax rule per invoice; the integration has to carry that country dimension through to the books, or your OSS return is guesswork.
• B2B reverse charge. Sell to a business with a valid EU VAT number and you charge no VAT, the buyer self-accounts. That means your integration has to post the sale as a reverse-charge entry, not a zero-VAT sale, which are different things to a tax authority. Validating the number at order time is the prerequisite; our Automatic EU VAT Checker verifies VAT numbers against VIES in real time so the order is tagged correctly before it ever reaches your books.
• Non-EU exports. Sales outside the EU are typically zero-rated but still have to appear in the books as exports, present, not invisible.

The rule of thumb: get cross-border VAT right before you scale volume. A wrong tax mapping is a small annoyance at 30 orders a month and a five-figure correction at 3,000.

Pitfalls that bite every accounting integration

Independent of which tool you choose, the same handful of bugs recur. Designing for them upfront is cheaper than discovering them at year-end:

• Duplicate invoices. The classic. A sync that runs twice, or retries after a timeout, can post the same invoice twice. The fix is an idempotency key, almost always the PrestaShop order or invoice ID, so the accounting side recognises and skips a repeat.
• Rounding drift. PrestaShop and your accounting software can round tax per-line versus per-total differently. A one-cent gap on one order is noise; on thousands of orders it becomes a reconciliation that never quite balances. Decide the rounding rule once and make both systems agree (PrestaShop's round mode and round type live under Shop Parameters → General).
• Currency mismatch. A customer pays in GBP, your books are in EUR. The entry needs both the original-currency amount and the converted amount at the right rate, or your foreign-currency reporting is fiction.
• Forgotten gateway fees. A payment processor's percentage isn't a discount on revenue, it's an expense. Record the gross sale and the fee separately, or your margins look better than they are and your bank balance won't tie out.
• Refunds that vanish. The most common place a manual process breaks is refunds. If credit slips don't flow automatically into credit notes, your revenue is systematically overstated. Automate this path first, not last.

A sane rollout, by store size

You do not need the most sophisticated pipeline. You need one that is accurate, reliable, and saves more time than it costs to run. Match the effort to the volume:

• Under ~50 invoices/month: a weekly export (CSV/Datev-style) that your accountant imports is genuinely enough. Don't over-engineer.
• ~50–500/month: a daily automated sync or scheduled export, with refunds automated and a failure alert so you find a broken run the same day, not at month-end.
• 500+/month: near-real-time integration with idempotency, logging and monitoring, the volume where a silent duplicate or missed credit note is expensive enough to justify the engineering.

And whatever the size: talk to your accountant before you build. Ask which chart of accounts to use, what tax codes they expect, what export format they actually import, and whether they want PrestaShop or their own system to own the invoice numbering. Then run the new pipeline in parallel with your existing process for one full month and reconcile the two before you switch off the manual fallback. The goal isn't a clever integration. It's a quarter-end where the books are already closed because every order, refund and tax line translated itself correctly the first time.

Frequently asked questions

Should the invoice number come from PrestaShop or from my accounting software?

Pick one as the book of record and stick to it. If you issue customer-facing invoices at order time and the store is your primary sales ledger, PrestaShop should own the numbering, but then you must control the prefix, format and sequence tightly so it's gapless and audit-proof (this is what Invoice Number and Order Number are for). If your accountant insists on issuing all legal documents from their system, let it number them and treat the PrestaShop order ID as metadata, and suppress the customer PDF so the two don't conflict.

How are refunds supposed to reach my accounting software?

As credit notes, never as deleted or edited invoices. A PrestaShop credit slip (OrderSlip / ps_order_slip) maps to a credit note (Xero) or credit memo (QuickBooks) against the original invoice, same amount, same tax treatment, negative values. Automate this path first, because a manual refund process is the single most common reason books overstate revenue.

Do I need a paid middleware subscription, or can I just export a file?

For an export-oriented accountant, Datev in Germany, JPK in Poland, or anyone who says "just send me a CSV". A scheduled export is exactly what they want, and a module like Invoice CSV List Exporter does it with no recurring fee and no order data leaving your server. Middleware (Synder, A2X) earns its subscription when you specifically want a live, hands-off API sync to Xero or QuickBooks with retry and logging handled for you.

How do I avoid double-posting invoices when a sync retries?

Use an idempotency key, almost always the PrestaShop order or invoice ID, so the accounting side recognises and skips a repeat. Without it, any sync that runs twice or retries after a timeout can post the same invoice again, and you find out at reconciliation. It's a one-line design decision that prevents the most common accounting-integration bug.

My cross-border VAT looks wrong in the books. Where does that go wrong?

Almost always in the tax-rate mapping or the missing country dimension. PrestaShop stores the destination and applied tax rule per invoice, but the integration has to carry that country through to the books for OSS reporting, post B2B sales to valid EU VAT numbers as reverse-charge (not zero-VAT), and treat non-EU sales as zero-rated exports rather than dropping them. Validate VAT numbers at order time (Automatic EU VAT Checker checks against VIES) so each order is tagged correctly before it reaches the ledger.

Related reading

• When your store outgrows manual work. Deciding whether accounting integration is the first step you need
• Connecting PrestaShop to your ERP, the stock-and-purchasing half, a different shape from the ledger
• Zapier and Make for PrestaShop, when broader store automation, not the ledger, is your reason to integrate