PrestaShop Accounting, Invoices and E-Invoicing

What we would do

We would start with the last export your accountant accepted and trace it back to the issued invoices, credits and payment records. Inventory the existing shop version, modules, accounting and ERP integrations, theme PDF changes, historical data and markets before choosing a route. Agree who issues documents and who resolves failures. Keep a working native setting or import process when it meets the requirement; introduce a connector for a defined gap your current setup cannot cover.

Make the change on a private staging copy with the actual theme, modules and representative financial records. Isolate it from live accounting writes, national invoice submission, scheduled exports and customer emails, and use supported test accounts. Rehearse document creation, export, correction and recovery with the accountant and the staff who run the process. Plan the live switch around an agreed document boundary, retain the previous configuration and make reversal preserve every document already issued or accepted externally.

If your required mapping or connection needs new behaviour, the PrestaShop Custom Module Development Service can build it against a written specification and acceptance criteria.

Choose the smallest change that meets the requirement

Separate orders, invoices, revenue and payments

An order records a commercial workflow. An invoice records a numbered document. A payment records money attributed to a transaction. A bank settlement records what your provider paid out, often after fees. Keep these events separate in your export and reconciliation.

Invoice existence does not universally determine revenue recognition or the VAT chargeable event. Supplies, advance payments, cash-accounting schemes and unpaid receivables can need different treatment. Agree the trigger with your accountant and map it explicitly. Do not export only paid invoices when your accounting policy also requires unpaid issued invoices.

The table prefix varies by installation. Invoice location and tax treatment require joins to the order, relevant addresses, order details and tax records. Preserve historical location and classification data rather than assuming the invoice object holds a complete snapshot.

Recording a refund or creating a credit slip does not by itself prove that the gateway returned money. Check the installed payment module and provider transaction separately.

Choose the accounting feed and document owner

Choose one system to issue the authoritative invoice number. If PrestaShop issues it, carry the same legal identifier into the ledger. If the accounting system issues it, retain the order and invoice mappings and prevent conflicting customer-facing documents.

A connector or agreed import file should handle:

• Issued invoices, unpaid balances and partial payment allocations.
• Revenue accounts and tax codes for every supported transaction type.
• Credit documents linked to the original invoice.
• Original currency, reporting currency, exchange-rate policy and rounding.
• Gross payment, provider fees, refunds, chargebacks and settlement reconciliation.
• Separate customer shipping charges and actual carrier expense.

For Xero, confirm supported invoice, tax-code, payment and multicurrency behaviour for your organisation and subscription. For QuickBooks, confirm the company's country edition and automated-tax model. Customer location alone does not select a valid US sales-tax or EU VAT workflow.

For Sage, DATEV, Fakturownia, inFakt, wFirma, Fattura24, Aruba or another local platform, start with the receiving system's current import/API specification. A generic CSV is not automatically a DATEV, JPK or national e-invoice file. Debitoor is a closed historical product.

Decide whether you need individual product items in the ledger or a smaller set of mapped sales categories. Check any classes, locations or multistore dimensions against the accounting product edition. Choose batch frequency from posting deadlines and recovery needs; real-time processing is not inherently more reliable.

A module runs within the shop; a middleware service introduces another processor and credentials boundary. Review data destinations, access, retention and support for refunds before selecting either. A module can still send data externally when it uses external APIs.

Write a mapping sheet with the source field, destination account or tax code, transformation and exception owner. Include a sample sale and correction for each supported treatment. If products are grouped into sales categories, define what happens when a new product has no mapping: hold it for review rather than silently posting it to a convenient default. Ask the accountant to approve the receiving entries, not only the exported file.

Native exports and a query with one row per invoice

The Orders list export provides a defined set of list fields and respects the supported grid filters. It is not a configurable ledger or line-item report. Modern native CSV exports use semicolons. Orders > Invoices can generate PDF batches, which are different from a structured accounting feed.

Advanced Parameters > Database > SQL Manager lets authorised staff run SELECT reports and export the results. Keep access restricted because a read-only query can expose customer and financial data.

Always declare the row unit before joining. An order can have several invoices. Joining invoice rows to order totals repeats the order total and inflates sums. This example selects each numbered invoice's own totals and date. It uses shop 1, currency 1 and June 2026 as a concrete report scope; adapt them and the table prefix to your shop.

SELECT oi.id_order_invoice,
       oi.number AS numeric_invoice_number,
       oi.date_add AS invoice_date,
       o.id_order, o.reference, o.id_shop, o.id_currency,
       oi.total_paid_tax_excl AS invoice_net,
       oi.total_paid_tax_incl AS invoice_gross,
       oi.total_paid_tax_incl - oi.total_paid_tax_excl AS invoice_tax
FROM ps_order_invoice oi
JOIN ps_orders o ON o.id_order = oi.id_order
WHERE oi.number > 0
  AND o.id_shop = 1 AND o.id_currency = 1
  AND oi.date_add >= '2026-06-01 00:00:00'
  AND oi.date_add < '2026-07-01 00:00:00'
ORDER BY oi.date_add, oi.id_order_invoice;

This is a document inventory, including unpaid issued documents. It does not apply a revenue-recognition policy, extract credit slips or allocate payments. The numeric number is not the formatted legal identifier. Use the core/module formatting service for the correct language and shop.

For one row per order, keep order totals once and aggregate invoice identifiers separately. For picking, use a line-level report with SKU, combination, quantity and required shipping details. An order summary cell is not the same output.

Worked scenario: the order and invoice fall in different periods

An order placed before the reporting period can have an invoice issued inside it. A later invoice for that same order can belong to the following period. For the document inventory above, select each invoice by its own issue date: the order date neither excludes the earlier order's current-period invoice nor brings its later invoice into this period. Keep the order reference as the link between them.

CSV encoding, layout and export boundaries

Agree column names, delimiter, decimal convention, quoting, timezone and dates with the recipient. A UTF-8 BOM can help Excel detect encoding on double-click, but some importers reject it. Explicit text import lets you select UTF-8 and preserve leading-zero document numbers, postcodes and references.

Quote fields containing the delimiter, quotes or newlines and double embedded quotes. A decimal comma does not break correctly quoted CSV by itself. The delimiter, quoting and spreadsheet locale must agree. Test names such as Müller and Łódź, an address containing a comma, and a multiline note.

An illustrative tax-bucket exchange file could look like this. The rates and amounts demonstrate file structure, not the tax treatment of a particular transaction.

document_number,document_date,original_invoice,currency,tax_code,net,tax,gross,type
INV-2026-000412,2026-06-18,,EUR,STANDARD,50.00,9.50,59.50,invoice
CN-2026-000031,2026-06-20,INV-2026-000412,EUR,STANDARD,-50.00,-9.50,-59.50,credit_note

Your destination may require different grouping, signs and correction structures. Reconcile document totals across all rate rows and include tax classifications, not only numeric rates.

Orders CSV List Exporter supports order, product and invoice row modes, selectable totals and addresses, an invoice-address VAT number and a product-name/quantity summary. Saved profiles produce CSV, Excel or XML on demand or on a schedule, with email or server delivery. Check the installed release's fields and row modes in its module help.

Invoice CSV List Exporter lists invoices and credit slips by each numbered document's issue date, with invoice-level totals, aggregate VAT and invoice-address country, and All, Paid only or Unpaid only filtering. Saved profiles produce CSV, Excel, XML or PDF, with scheduled email or secure server delivery. Confirm the installed release's fields and payment-allocation behaviour in its module help.

Payment method is an output field in these exporters, rather than the advertised payment-method filter. Their paid/unpaid filter compares order-level recorded payment totals with order totals. For several invoices or partial allocations, reconcile invoice payments separately.

For OSS or another per-rate return, build a separate report that handles destination, tax classification, credit documents and currencies. Do not treat invoice-address country and aggregate VAT as a complete destination/per-rate report.

Write a reusable export specification

1. Name the recipient and purpose. Select only the customer and address fields that job needs.
2. Record the row unit, shop scope, date field, timezone and inclusive/exclusive boundaries. Keep a period-end example with the specification.
3. Fix the column order, formatted document identifier, original-invoice link, currency and tax-code mapping. Document whether credits have signed amounts or a separate document type.
4. Import a sample into the destination, including accents, leading zeros, embedded quotes and multiline text. Opening it in a spreadsheet is not an import test.
5. Record document counts and net, tax and gross control totals by currency with each handoff, and keep the recipient's acceptance or rejection result.
6. Save the layout as a profile where the installed tool supports it, or keep the settings in the staff runbook. Agree how a replacement file is identified so it cannot be imported as an additional batch.

Worked example: a credit document and a cash refund

The sample CSV above records invoice INV-2026-000412 for EUR 59.50, comprising EUR 50.00 net and EUR 9.50 tax, followed by a credit for those same amounts. The document balances offset in that example. That alone tells you nothing about whether the customer payment was received or returned.

Ask staff to resolve the layer that differs. A missing credit in the ledger needs document recovery; a recorded credit with a failed gateway refund needs payment recovery. Re-importing the invoice or changing its totals will not resolve either mismatch.

Order references, invoice numbers and numbering changes

The native order-reference fallback is nine random uppercase letters, such as XKBKTSXPM. It is separate from the internal numeric order ID and from a legal invoice number. PrestaShop 9 offers actionGenerateDocumentReference for extensions.

Under Orders > Invoices, native settings include the language-specific prefix, year display and position, annual reset and a one-use starting number. Core pads the numeric component to at least six digits, for example 000142; larger numbers are not truncated. It has no native width selector. Delivery-slip settings are under Orders > Delivery slips.

The native configuration names below help you identify which control is being reviewed. Read them in the intended shop and language context; make changes through the supported settings rather than a manual database update.

Core normally allocates from the maximum invoice number, optionally restricted by year. That query is not shop-filtered. Shop-scoped prefixes and settings do not establish independent counters. Review the whole series design before changing a multistore installation.

Changing native prefix or year-format settings can change how historical invoices are displayed when regenerated. The stored numeric number and invoice date do not freeze the whole formatted representation.

1. Choose a document series with your accountant, including shop identity and reset period.
2. Inventory existing numeric and formatted identifiers across all relevant shops and years.
3. Preserve issued documents and document the transition date.
4. Set the next value only after checking the target series. The core start setting is consumed directly once, so do not assume it is automatically raised above existing records.
5. Test concurrent creation, period resets, exports and document downloads on staging.

Formats such as RE-DE-2026-00001, FA-FR-2026-00001 or FV/00001/06/2026 can make a chosen series readable. They are examples, not universally required formats. Separate credit-note series may be appropriate or required locally.

Cancellation and refund do not automatically delete the invoice or free its number. Keep the numbered document and correction trail. For genuinely missing numbers, investigate deleted data, manual starts and integrations rather than renumbering old invoices.

Custom Invoice Numbering supports configurable document formats and reset modes; its module help covers the numbering controls.

Custom Order Numbering changes order references, using the native hook on supporting versions and a compatibility override on older ones; its module help lists the supported format tokens.

Do not use a payment-method token while an order reference is being generated: payment data may not yet exist and this module rejects {PAYMENT} there. Neither numbering module guarantees legal compliance or repairs an unexplained historical gap.

Customise PDF invoices without editing core

Invoice creation depends on enabled invoice settings, an invoice-generating order state or a supported manual action. On modern versions, inspect state flags under Shop Parameters > Order Settings > Statuses. Not every order immediately gets an invoice.

The PDF is rendered on demand. classes/pdf/HTMLTemplateInvoice.php gathers data. pdf/invoice.tpl and its tab templates define the layout; invoice.style-tab.tpl defines PDF styling. TCPDF supports a limited HTML/CSS subset.

1. Create a pdf/ directory in the active theme.
2. Copy only the needed invoice template or tab template from the core pdf/ directory.
3. Edit the theme copy and render a representative invoice.
4. Keep the customisation in version control outside the deployed shop. A theme update or reset can replace the theme's PDF copy, so check the deployed files afterwards and compare your customisation with upstream changes after upgrades.

For example, from the shop root, this creates a PDF template copy in an example theme named shop-child:

mkdir -p themes/shop-child/pdf
cp pdf/invoice.tpl themes/shop-child/pdf/invoice.tpl

PrestaShop 9 passes the invoice Address object in $addresses.invoice. A guarded, escaped buyer VAT field in a compatible template can use:

{if $addresses.invoice->vat_number}
  <p>{$addresses.invoice->vat_number|escape:'html':'UTF-8'}</p>
{/if}

Use built-in Legal free text and Footer text under Orders > Invoices for constant wording, such as approved payment terms or a seller tax ID. For dynamic data, use a supported extension point or a narrowly scoped PHP extension. Fetch data in PHP, then pass escaped values to the template; do not put SQL into Smarty.

If a legacy class override is necessary, it belongs under override/classes/pdf/HTMLTemplateInvoice.php and must extend the core class without losing its assigned variables. Check conflicts with existing overrides. Rebuild the class map/cache for the actual environment; older 1.6 uses cache/class_index.php, while modern installations use environment caches under var/cache/.

Use a genuine supply/delivery date for legal fields. A shipped-state timestamp or delivery-slip date is not automatically proof of actual delivery. Buyer vat_number, company and dni are address fields; customer siret is a customer field. Seller identifiers have a separate configured source.

Print IBAN/BIC only from the correct bank-payment configuration, and retrieve any customer PO reference from its actual capture field. Check the shop identity under Shop Parameters > Contact on modern versions.

Check the rendered result before replacing a template

• Use records with and without the optional company, VAT and PO fields. Empty values must not leave a misleading label or another customer's value.
• Render long legal names, multiline addresses, accented text and long product descriptions. Check page breaks, repeated headings, tax subtotals and the final total on a large invoice.
• Switch shop and document language deliberately. Check the seller identity, legal wording and bank details against the intended entity, rather than the administrator's current shop alone.
• Keep an approved baseline PDF and compare the changed output. Record which fields should differ so an unrelated amount, address or shared-tab change is caught.

Check country-specific invoice fields

First identify seller establishment, customer status, supply type and applicable invoicing rules. The following are focused checks, not a complete field specification for every transaction.

Configure each shop in the intended shop context before editing seller identity, language-specific legal text or numbering. Shared theme templates may need explicit shop-dependent content. Review All shops changes carefully.

Tax-rate configuration is separate from the seller's tax identifier and the wording on the PDF. Have your accountant validate representative domestic, cross-border, exempt and corrected documents.

Credit documents, archiving and PDF troubleshooting

Credit-slip and delivery-slip PDFs use order-slip.tpl and delivery-slip.tpl. Credit slips reuse invoice styling, address and tax tabs, so changes to those shared templates can affect both invoices and credit slips. Delivery slips use their own corresponding tabs. Test all three document types after template changes. Include the original-invoice relationship and correct refunded tax amounts on correction documents.

Preserve the issued representation. Historical product names and amounts mainly come from stored order details, so a catalogue rename alone normally does not rewrite an old invoice line. Template changes, address changes and order edits can still change a regenerated PDF.

Archive the first issued document from the invoice-creation workflow, rather than relying on a download hook that may never run or may overwrite an earlier copy. Store the document, structured payload where applicable, identifiers and acknowledgements with access controls and an integrity-preserving retention policy.

France generally requires business invoices to be kept for 10 years; see Service Public retention guidance. Germany generally requires invoice copies for eight years under UStG §14b, subject to applicable transitional and special rules. Agree the exact retention and archive requirements for your entity.

• Missing seller VAT ID: check configured legal/free text or your PDF extension. Tax-rate settings alone do not create a seller identifier.
• Wrong identity: check the intended shop's contact/address settings and the invoice's stored shop address.
• Missing glyphs: inspect the actual PDF font, renderer and font files. PrestaShop 9 already maps Polish and Czech to DejaVu Sans. Core has no invoice-font dropdown to switch.
• Large-order failures: read the PHP/TCPDF error, inspect logos and images, then tune memory based on measured need. PrestaShop 9 recommends a PHP memory_limit of at least 512M.
• Lost customisation: inspect active theme selection, theme PDF copies, cache and competing module/class extensions.

Financial Revolution provides financial documents, correction PDFs and reporting; its module help describes those features and their configuration.

Cross-border VAT and payment reconciliation

Keep country, tax code, net amount, VAT and gross amount consistent from the sale through credit documents and the ledger. A zero numeric rate is not a complete tax classification.

For OSS, preserve the relevant destination and applied tax treatment and include corrections. A valid EU VAT number alone does not make every B2B sale VAT-free. Qualifying intra-community goods supplies, reverse-charged services, domestic sales and exports have different conditions. Check customer status, establishment, movement/location and supporting records against the EU VAT guidance.

Automatic EU VAT Checker validates VAT status according to its configured policies, including ordinary-tax fallback or pending states; its module help explains the validation workflow.

Agree the exchange-rate basis and posting dates with the accountant. Keep original-currency amounts and provider conversion/settlement amounts separately. Match gross customer payments to fees, refunds, chargebacks and net deposits. Provider fees are an expense rather than a reduction that silently changes the sale.

Reconcile rounding at the defined line, tax-rate and document levels. On modern versions, inspect Round mode and Round type under Shop Parameters > General, and compare the export with the destination's calculations before changing settings. A small recurring difference needs a repeatable adjustment policy, not manual edits to already-issued documents.

Structured e-invoicing: format, channel and scope

A PDF can be an electronic invoice in the broad VAT sense. A structured mandate requires machine-readable data in the relevant format; an ordinary PDF is not enough. A hybrid format such as Factur-X or ZUGFeRD includes structured data, and its profile must meet the applicable rules.

PrestaShop core's PDF workflow is separate from XML generation, validation and transmission. Decide how your invoice data becomes the national format, how it is delivered, how rejections and corrections return to the shop, and how receipts are preserved.

Not every structured invoice requires a government platform. Germany allows direct transmission, including email. Other countries require a particular network or clearance system. Determine scope from establishment, participating fixed establishments, transaction type, B2B/B2C/B2G status and exceptions. Selling to a customer in a country does not alone make its domestic mandate apply to you.

Build an applicability sheet for your business

Validate seller and buyer identifiers, structured addresses, document IDs, line descriptions, currency, dates, tax categories, amounts and payment terms against the chosen schema and business rules. VIES validation is one input, not a substitute for national invoice validation.

A country module may generate the required file; a provider may handle conversion, transmission or both. Agree credentials, retries, rejection handling, service continuity and archival access. Outsourcing does not remove the issuer's responsibility for issuance, correction, reporting and preservation.

Follow a rejected or uncertain submission to its outcome

Track source issuance, file validation, transmission and the applicable platform or recipient result separately. A successful HTTP response or a provider's queued status is not evidence of every required acceptance step. Store the source document ID, provider reference, payload version and returned receipt or rejection together, with a person responsible for unresolved records.

For a rejected file, identify whether the fault is missing source data, a mapping error, a schema rule or transport authentication. Repair the responsible layer and use the supported resubmission or correction procedure. For a timeout with an unknown outcome, look up the existing submission before retrying. Do not create another invoice number merely to make a technical retry appear new.

Test inbound supplier invoices separately from outbound sales. Name the accounts-payable recipient, check how the structured document becomes readable and bookable, and retain its original data and processing outcome. Enabling the storefront's PDF generator does not provide this reception workflow.

European e-invoicing dates as of 26 October 2026

France also has separate e-reporting obligations that can cover transactions outside its domestic B2B e-invoice flow. Consumer sales therefore do not justify ignoring the reform.

ViDA was adopted on 11 March 2025. Cross-border B2B digital reporting starts on 1 July 2030, with relevant domestic-system alignment by 1 January 2035. See the European Commission timetable.

Recheck the authority's scope, exceptions, schema version and deadlines before implementation and whenever your business footprint changes.

Roll out the feed and reconcile it

1. Agree the document owner, chart of accounts, tax codes, recognition policy and required import layout.
2. Map stable source IDs to destination IDs. Include shop/source identity and document type in deduplication keys.
3. Test invoices, unpaid and partial payments, mixed rates, discounts, shipping, multiple currencies, partial/full refunds and credit documents.
4. Simulate a timeout after the destination has accepted a document. A retry must find the existing record rather than create a duplicate.
5. Log rejected records with a clear owner and retry policy. Keep an audit trail of corrections.
6. Run the new route for a full reporting period with shadow output or a separate test destination while the existing process stays authoritative. Reconcile invoices, credits, tax, payments and bank settlements before authorising live posting through the new route.

Automate only through an implemented, authenticated export/API task. Installing a scheduler does not automatically create an export endpoint. Native Webservice is request/response CRUD; use polling or an implemented server-side hook with authenticated delivery, retries and deduplication for event-driven integration.

Retain the manual recovery path and alert on missed runs. Choose frequency from reporting deadlines, transaction complexity and operational risk, rather than universal invoice-count bands.

Switch the workflow and hand it over

1. At the agreed switch, identify the last accepted batch or destination record and list pending submissions, rejected documents and refunds. Record a boundary that also captures invoices and credits created during the change; an order-number cutoff alone can miss later documents for earlier orders.
2. Pause overlapping delivery jobs and give the new route a controlled starting scope. Reconcile the opening batch against the approved control totals and check that documents already accepted by the destination are recognised.
3. Confirm that the intended customer document, archive copy and receiving-system reference agree. Check the first exception as well as the successful records, and prove that its owner receives the alert.
4. If reversal is needed, stop the new outbound route, preserve its acceptance log and reconcile what reached the destination before resuming the previous process. Restore configuration with a documented recovery scope; restoring an old database can discard documents and orders created since the switch.

What to ask your developer or agency

• Which installed versions, shop contexts and existing extensions were tested, and where are the sample documents and import results?
• Where is the agreed mapping, including historical addresses, tax classifications, currency, invoice-payment allocation and credit links?
• How does staff recover from a missed run, an uncertain timeout or a rejected document without posting it again?
• Who maintains the schema and provider connection, and who watches credential expiry, rejected submissions and regulatory changes?
• Where are the issued-document archive, acceptance logs, access permissions and cutover/reversal instructions, and can staff retrieve them without the original developer?

Questions owners ask

Can I keep sending my accountant a CSV after adding structured e-invoicing?

Yes, if the CSV remains the agreed ledger feed and the structured route performs the required legal delivery or reporting. Map both to the same authoritative document. Check whether the provider also posts to your accounts, so the CSV does not create another ledger entry for that document.

What if the accountant cannot tell whether a file was imported?

Treat the batch as having an unknown outcome. Check the destination's import log and document references before sending a replacement, and agree who approves recovery. Sending the same file under a new filename does not establish that it is safe to import again.

Must every customer enter business tax fields at checkout?

Base required fields on the customer and transaction types your adviser has identified. Test both consumer and business checkout paths. Collect required business identifiers before issuance, while allowing a supported consumer document to omit business-only fields where the applicable rules permit it.

A buyer asks for a company name or VAT number after issuance. Can I edit the address?

Have the accountant decide whether the change needs a formal correction or replacement under the applicable rules. Preserve the issued document and its history, then use that correction process. An address edit followed by a fresh PDF download can change the representation without recording why it changed.

What should I keep if I change e-invoicing providers?

Export the original structured documents, receipts, rejection history and source-to-provider mappings before access ends. Agree how outstanding submissions and later corrections to old invoices will be handled, and test retrieval from your retained archive before closing the old account.