Invoice and Order Number Customization: Why Default Numbers Are Not Enough

Reviewed June 2026. Applies to PrestaShop 1.6, 1.7, 8 and 9. The config keys below are stable across those versions; menu labels shift slightly between releases, so confirm the exact path on your own install. Nothing here is legal or tax advice — your accountant and local rules decide what a compliant sequence looks like in your country.

Out of the box, PrestaShop hands every order a reference like "XKJHQWER" and starts invoices at number 1. For a test catalogue that is invisible. The day you take real orders it becomes a liability: a support agent who can't read an order number back over the phone, an accountant who can't tell which document is which, and a tax inspector who wants to know why invoice #4521 is followed by #4598 with nothing in between. This guide is specifically about the numbers — the order reference and the invoice/credit-slip sequence — what PrestaShop lets you change from the back office, where it stops, and how to get a numbering scheme that your accountant signs off on and your team can actually use.

It is a narrow topic on purpose. The format of the invoice PDF itself, the country-by-country legal rules for what an invoice must contain, and the move to structured e-invoicing are all separate problems with their own answers, linked at the end. Here we stay on the numbering.

What PrestaShop gives you natively — and what it doesn't

Two different numbering systems run side by side in PrestaShop, and merchants constantly confuse them.

The order reference is the customer-facing code generated the moment an order is placed. PrestaShop builds it in Order::generateReference() as a random uppercase alphanumeric string (the familiar "XKJHQWER" shape). It is not sequential, not configurable from the back office, and carries no meaning. It is what shows in the confirmation email, in Orders → Orders, and what a customer reads to you on the phone.

The invoice number is different: it is assigned only when an invoice is actually generated (when an order reaches a status flagged as invoice available), and it is a continuous sequence. You get a small amount of control over it under Orders → Invoices (PrestaShop 1.7 and later: Sell → Orders → Invoices):

That covers the basics, and for a single-country, single-shop store it may be all you need. The gaps appear the moment your setup is even slightly more demanding:

• The order reference stays random. Nothing in the native settings touches it. Your warehouse and support team are stuck reading "XKJHQWER" out loud.
• No zero-padding control. Invoice numbers run 1, 2, 3 … 999 with no way to force a fixed width like 00001 — so they don't sort or align cleanly in exports.
• Native credit slips have their own basic numbering and prefix, but limited custom formatting. PrestaShop generates credit slips as a separate document type with a separate counter and prefix, yet you get little control over their formatting, reset or series compared with a dedicated module. Some jurisdictions want credit notes in a clearly separate, self-describing series.
• Year is the only reset period. If your accountant uses monthly sequences, the native toggle can't do it.
• Per-shop differentiation is coarse. In a multistore you can vary the prefix per shop, but building a clean, market-specific scheme by hand is fiddly.

So what? Why the numbering actually matters

This is the part merchants underrate until something breaks. Three concrete payoffs:

Audit safety. EU rules require sequential, unique invoice numbering based on one or more series, and many tax authorities expect any gaps to be explainable and documented — a gap you can't explain is the kind of thing that turns a routine check into a real one. What counts as compliant varies by country, and that detail belongs in the legal guides, not here: see invoice customization: PDF templates and legal requirements for what each market wants on the document, and the EU e-commerce law overview for the wider obligations. The point for numbering is simply: a predictable, controlled sequence is what makes "no unexplained gaps" achievable in the first place.

Support speed. A customer reading "ORD-2026-00142" to your agent is a one-shot lookup. The same customer reading "XKJHQWER" mishears the K for a Q, drops a character, and you spend two minutes confirming spelling. Multiply by every support call.

Accounting that imports cleanly. Whether your bookkeeper uses Datev, Xero or a local package, they expect a consistent format and fixed-width numbers that sort correctly. Getting the format right before the first export is far cheaper than reconciling a mismatch later.

Designing a numbering scheme that holds up

Before you touch any setting, decide the scheme on paper. A good one is readable, self-dating, and fixed-width. A practical pattern:

• Prefix that names the document and market — RE for a German Rechnung, FA for a French facture, INV for a generic English invoice.
• Year (and month, if your accountant uses monthly series) — makes the document self-dating so it never needs cross-referencing to know when it was issued.
• Zero-padded counter — 00001 not 1, so everything aligns and sorts.
• A separate series for credit notes — use a separate credit-note counter unless your accountant or local rules approve a shared series; a credit note is its own document type, and a distinct series is usually clearer.

That yields formats like RE-2026-00001 or FV/00001/06/2026. The one rule that matters more than the exact shape: pick it once and don't change it mid-period. Changing format inside a fiscal year is what creates the confusing records and apparent "gaps" that auditors dislike. If you must change, do it at a year boundary and leave a written note for your accountant.

Getting full control: the module route

When the native settings run out — and for the order reference they run out immediately — two of our modules pick up the slack, each owning one of the two numbering systems.

Our Order Number module replaces the random order reference with a meaningful, sequential one. It works by overriding the core Order class, so the new reference flows everywhere the old one did — the back-office list, the customer's account, the confirmation email — with no theme edits. You build the format from tokens: {YYYY} for the year, {MM} for the month, {NNNNNN} for a zero-padded counter, even {PAYMENT} to fold in the payment method. So what does that buy you? A reference like ORD-2026-000142 that a customer reads back without errors and your warehouse can scan and search instantly — the single biggest day-to-day friction in handling orders, gone.

Our Invoice Number module does the same for the document side, going well past the native prefix-and-year toggle. You set a custom prefix, drop in the {YYYY} token, choose the counter width with {NNNN} or {NNNNNN}, switch the reset between yearly and monthly, and — the part the core can't do cleanly — run a separate, independently-formatted sequence for credit notes. So what? You hand your accountant exactly the format they asked for, in the exact width that imports without manual fixing, with credit notes in their own clearly-labelled series. The compliance posture (continuous, controlled, explainable) and the bookkeeping convenience come from the same setting.

For credit-note content rather than its number — proper tax breakdowns, original-invoice references, and accounting-grade formatting on the document itself — that's the job of Financial Revolution, which enhances the credit slips PrestaShop generates on refund. Numbering and document content are deliberately separate concerns; use the tool that matches the one you're fixing.

Multistore: one scheme per shop

If you run several shops — different brands, different countries, different channels — each should keep its own counter and its own prefix. Mixing them produces apparent gaps when you look at a single shop's books and makes it impossible to tell at a glance which shop issued a document. A clean layout:

Each shop increments and resets independently, and the market is legible from the prefix alone. The invoice settings are already context-aware in a PrestaShop multistore; the order-reference side is where a module earns its keep, because the native random reference has no per-shop concept at all.

Migrating from default numbers without creating duplicates

Switching a live store needs care — get the starting number wrong and you can collide with documents that already exist. The safe sequence:

1. Choose a transition date — prefer a fiscal year or quarter boundary; if you must change mid-period, document the change and keep the old and new series clearly traceable.
2. Set the next counter above your highest existing number — for invoices that's PS_INVOICE_START_NUMBER (or the module's start value); this guarantees no duplicates.
3. Leave old documents alone. Never retroactively renumber issued invoices — they keep their original numbers for the rest of their legal retention life. Only new documents take the new format.
4. Test the reset before you rely on it. If you configure an annual or monthly reset, prove it actually rolls over on a staging copy rather than discovering on 1 January that it didn't.
5. Write it down for your accountant — a one-line note of what changed and when removes any question about the "gap" at the changeover.

If you prefer to check or set these values directly, they all live in the ps_configuration table as plain key/value rows. Read them before you change anything in the back office so you know the current state:

-- Inspect the native invoice-numbering settings
SELECT name, value
FROM ps_configuration
WHERE name IN (
  'PS_INVOICE_PREFIX',
  'PS_INVOICE_USE_YEAR',
  'PS_INVOICE_RESET',
  'PS_INVOICE_START_NUMBER',
  'PS_DELIVERY_PREFIX',
  'PS_DELIVERY_NUMBER'
);

Some of these are per-language (the prefix in particular), so on a multi-language store the row may sit in ps_configuration_lang keyed by id_lang instead. The safest place to set them is still the back office, which writes the right row for the right shop and language context; treat the SQL above as a way to see the current state, and back up before any manual write. The next sequential invoice number itself is not stored as a single config row — PrestaShop derives it from the highest existing number in ps_order_invoice combined with the start value, which is exactly why setting the start number above your highest existing document (rather than renumbering anything) is the duplicate-proof move.

Common mistakes

• Changing format mid-year. The classic source of confused books and unexplained gaps. Move only at a period boundary.
• One series for invoices and credit notes. Some jurisdictions or accountants require or prefer a separate series — verify locally; even where a shared series is allowed, mixing them is a bookkeeping headache. Keep INV- and a distinct credit-note series.
• Leaving the counter unpadded. Mixed-width numbers sort wrong in spreadsheets and exports. Pad to a fixed width from day one.
• Forgetting the order reference exists. Merchants fix invoice numbers and leave orders on the random reference — then wonder why support calls are still slow. The two are separate systems; fix both.
• Not numbering delivery slips consistently. They carry fewer legal demands, but an erratic delivery-slip sequence still costs your warehouse team time.

Where numbering ends and the rest of compliance begins

Numbering is one slice of getting documents and tax right in PrestaShop. The neighbouring pieces, each with its own guide:

• What the invoice PDF must show and how to template it — invoice customization: PDF templates and legal requirements.
• Structured e-invoicing where it's mandatory (Italy's SDI, France's reform and more) — e-invoicing in Europe: which countries require it.
• Getting the VAT right across borders — VAT in the EU: OSS, IOSS and what your store must handle and the hands-on tax configuration in PrestaShop.
• How prices appear before checkout — price display rules in Europe.
• Refund handling end to end, of which the credit note is one step — returns and refunds: making the process painless.

Frequently asked questions

Can I make PrestaShop's order reference sequential without a module?

Not from the back office. The order reference comes from Order::generateReference(), which returns a random uppercase string, and there is no native setting that changes it. The only ways to make it sequential are to override the Order class yourself or to use a module that does — the invoice number is configurable natively, but the order reference is not.

Why does my invoice numbering have gaps?

Almost always because an order generated an invoice and was then cancelled or refunded, or because a status that you didn't expect to invoice had its "Invoice" flag set. The number was assigned and the document later voided, leaving a hole. In several EU countries a gap is acceptable only if you can explain it, so the practical fix is process, not deletion: keep the voided document, note why, and never renumber to "close" the gap. Whether gaps are tolerated at all depends on your jurisdiction — confirm with your accountant.

I'm migrating an existing store — what do I set the starting number to?

Set it to one above the highest invoice number you have already issued. PrestaShop derives the next number from existing documents plus the start value, so a start number above your current maximum guarantees no collision. Never lower the start number below an issued document, and never retroactively renumber old invoices — they keep their original numbers for their full legal retention period.

Should invoices and credit notes share one number series?

Usually no. A credit note is a distinct document type, and many accountants and some jurisdictions prefer or require a separate, self-describing series. PrestaShop gives credit slips their own basic counter; if you need an independently-formatted credit-note series with its own reset, that's where the Invoice Number module goes past the native toggle. Verify the local rule before sharing a series.

Does changing the invoice prefix renumber my old invoices?

No. The prefix and year tokens apply to documents generated after you change the setting; already-issued invoices keep the format they were created with, because PrestaShop stores the assigned number on each ps_order_invoice row. That's also why you should change format only at a period boundary — mixing two formats inside one fiscal year is what produces records auditors find confusing.

Document numbering is one of those settings nobody praises and everybody notices the day it's wrong. Decide the scheme once — readable prefix, self-dating, fixed width, credit notes on their own series — set it from the back office or with a module that fills the native gaps, then leave it alone. Done right, it quietly does its job through every audit, support call and year-end for as long as the store runs.