How to Number Invoices

An invoice number does one job: it lets two people looking at two different pieces of paper agree on which document they mean. Every choice about scheme, prefix and padding is in service of that job, and most of the ways numbering goes wrong are ways that job quietly stops being done.

Why the number matters

When a payment lands in your account with the reference “inv 214”, the number is what turns a bank line into a settled invoice. When a client's accounts department queries a charge six weeks later, the number is the first thing they quote, and if two of your documents answer to it, the conversation gets expensive. If you ever have to show a third party what you billed and when, the numbers are the index into that record.

There is also a compliance reason. Many tax authorities expect invoice numbers to run in a sequence with no gaps, precisely so the completeness of the set can be checked — an inspector who can see 101 through 140 with nothing missing knows the numbered series is complete. How strictly this is required, whether a voided number may simply be dropped, and how long you must retain the record all vary by country and sometimes by state. This page is general explanation, not tax or legal advice; before you settle on a scheme you will be living with for years, it is worth ten minutes with your own tax authority's guidance.

Four common schemes

• Plain sequential — 1, 2, 3, or padded as 0001, 0002. Easiest to audit, because a gap is visible at a glance. Its drawback is that the number is a public counter of how many invoices you have ever issued.
• Year-prefixed — 2026-001. The number tells you which year's records to open, and the counter resets each year, so it never grows unwieldy. The cost is that 001 recurs every year, so the year must always travel with it; never file or quote the tail on its own.
• Per-client prefixed — ACME-014. Convenient if you file by client and useful when a client asks for a history of their own invoices. But you now maintain one sequence per client rather than one overall, which makes a gap-free check harder to demonstrate and easier to get wrong when a new client arrives mid-year.
• Date-based — INV-20260812. Sorts correctly by default and needs no counter at all, which is why this site uses it as the fallback. It collides the moment you issue two invoices on one day, so it needs a suffix: INV-20260812-2.

Gaps and reused numbers

A gap is ambiguous. If 104 is missing, nobody reading your records — including you, in two years — can distinguish “never issued” from “issued and never recorded.” When an invoice is canceled, the usual practice is to keep the number and mark it void, or to offset it with a credit note, rather than reissue the number to something else. Which of those your jurisdiction expects is one of the things that genuinely varies.

A reused number is worse than a gap, because it fails silently. Two documents answering to INV-0042 means a payment can be allocated to the wrong one, a client who paid the first appears to have paid the second, and neither party can prove which is which from the number alone. If you discover a duplicate, a common fix is to reissue one of them under a fresh number and tell the client the old number is superseded — though jurisdictions that require a credit note for a cancellation may require one here too.

Do not encode more than you mean to

The number is printed on a document you hand to someone else, so treat it as public. An invoice reading INV-0003 tells the recipient you have issued three invoices in your life, which is information you may not want in the room during a rate conversation. The fix is not to start your counter at 1000 to look established — that is a small lie you then have to keep — but to pick a scheme that carries no headcount. Year-prefixed and date-based numbers both do this honestly. For the same reason, keep internal codes out: project margins, client rankings, and lead-source tags do not belong in a field the client reads.

Keep your own register

This tool stores nothing between visits, so it cannot number your documents sequentially. Leave the number field blank and it generates a date-based default — INV- for an invoice, RCT- for a receipt, QTE- for a quote — type one and yours is used instead. The default is date-only, with no collision suffix: two invoices built blank on the same date get the same number. It will not warn you about that, or any other duplicate, because it has never seen your other invoices.

That is a limitation of a tool with no account, not a feature; it is listed among the deliberate omissions on the methodology page, and the reasoning behind the no-account design is on the about page. So the register is yours to keep. A spreadsheet with five columns — number, date, client, amount, paid — is enough, and it is the thing you will actually reach for when someone asks which invoice a payment settled. Fill in the next number before you open the invoice generator, not after, so the register leads and the document follows. The number is one of the fields covered in what to put on an invoice.

What the generator does with the number

The engine treats the number as text. It trims the spaces around whatever you typed, and if nothing is left it builds the date-based default described above; it does not check the format, count anything, or compare the number with any other document. On a fictional invoice from Harbor Lane Joinery to Fenwick & Daughters, dated 12 August 2026, a number typed as “ 2026-014 ” with a space either side prints as 2026-014. Typed as three spaces, it prints as INV-20260812, because a field of spaces is blank once trimmed. Left empty, it prints as INV-20260812. All three figures were produced by the engine when this page was built.

The default is built from the document kind and the issue date, which is why it carries no count. A second blank invoice built the same day, this one to Quill Street Café for 2.5 hours of counter repair, is numbered INV-20260812 — the same string — and the shelving job built as a receipt is RCT-20260812, as a quote QTE-20260812. Move the issue date one day on and the number moves with it: INV-20260813. Nothing in that series is a counter; it is the calendar.

The number is also not arithmetic. The invoice to Fenwick & Daughters totals $640.00 with the number left blank and $640.00 with it typed, because the number is never read by the part of the engine that computes money. On the PDF it prints with the issue date, which is written out as 12 August 2026 rather than as the eight digits inside the default, so that a date like 08/12 cannot be read two ways. The downloaded file is named from the document kind, the number and the client's name, so the number is also what you will see in a folder of saved PDFs.

One job, three numbers

A register is easier to see with a job in it. Harbor Lane Joinery quotes Fenwick & Daughters for the oak shelving at 640.00 and a site survey at 90.00, with sales tax added on top at an example rate of 8%. Built as a quote numbered QTE-2026-031, dated 20 July 2026 and valid until 19 August 2026, the engine computes a subtotal of $730.00, tax of $58.40 and a bottom line of $788.40 labelled “Quote total”. A quote has no amount-paid field, so nothing is subtracted and no balance is printed; the figure is a price.

The job is accepted and the invoice goes out numbered 2026-015 — a number from the register, not the default — dated 12 August 2026, due 11 September 2026, with a 200.00 deposit already received entered in the amount-paid field. The engine records a subtotal of $730.00, Sales tax (8%) of $58.40, a total of $788.40, an amount paid of $200.00 subtracted from that total, and a bottom line of $588.40 labelled “Balance due”. Which of those figures a given PDF design prints as its own row, and in what order, is the design's choice; the figures themselves are the engine's. With nothing entered as paid, the amount paid is zero and the balance due is the same figure as the total.

Enter more than is owed and the floor applies. The same invoice with 800.00 recorded as paid records an amount paid of $800.00 against a total of $788.40 and a balance due of $0.00, never a negative figure. The engine does not know whether the extra was a mistake or a tip, and it prints no refund line; the document records only that nothing further is owed.

When the remaining $588.40 arrives, the receipt is a third document with a third number, and it confirms that payment rather than the whole job — the deposit was already recorded on the invoice as the amount paid. Built as a receipt numbered RCT-2026-009, dated and paid on 4 September 2026, carrying a single line, “Balance of invoice 2026-015”, at $588.40 with no tax line of its own, and with “Bank transfer, ref 2026-015” in the paid-by field, it prints $588.40 under “Amount paid” — to the cent, the balance the invoice left due. The receipt form has no amount-paid field, and the engine passes that field to the money calculation for invoices only; even when this page's build passes the full $588.40 as an amount paid, buildDocument discards it for a receipt, the receipt's internal amount-paid figure stays at $0.00, the printed bottom line is the total, and no balance due appears anywhere on the document. The invoice number lives in the line description and the paid-by text because the engine has no field that links one document to another. The receipts, quotes and the bottom-line label guide sets out why the three documents end on different words.

Three documents, three lines in the register: QTE-2026-031 on 20 July 2026, 2026-015 on 12 August 2026, RCT-2026-009 on 4 September 2026. The engine produced each one from a blank form, kept none of them, and would have given all three the date default had the number field been left empty. The thread between them is the text you typed and the register that holds all three.

Voids, credit notes and the engine

The practice described above — keep a canceled number and mark it void, or offset it with a credit note — is paperwork the generator does not do for you. It builds 3 kinds of document — invoice, receipt and quote — and a credit note is not one of them. Nor can an invoice be made to carry a negative amount: a line described as “Credit against 2026-014” with a unit price of −120.00 is rejected with “Unit price cannot be negative.”, and the same line with a quantity of −1 is rejected with “Quantity cannot be negative.”. Every line amount is zero or more, so every subtotal is too.

What the engine will build is a document that nets to zero. A 100% discount on the 640.00 shelving line produces a discount of $640.00 and a total of $0.00; a flat discount of 700.00 against the same 640.00 of lines is capped at the subtotal, giving $640.00 off and the same $0.00 total, because a discount can reduce a document to zero and never below it. A zero total is not a void marker; the word has to be written. The notes field takes up to 600 characters, enough for a line such as “Supersedes 2026-014, which was issued in error.”, which runs to 47; one character over the limit and the document is refused with “Notes are limited to 600 characters.”.

What the generator does and does not do here

It does: accept any text as a number, trim it, fall back to a date-based default when it is blank, print it on the PDF with the written-out issue date, and put it in the filename. It computes every figure on the document in whole cents, rounding once at the line — the arithmetic set out in how invoice totals are computed — and none of that arithmetic reads the number.

It does not: number documents sequentially across sessions, store what you issued, warn about a duplicate, check that a number fits a scheme, or link a receipt to the invoice it settles. It applies no rule about gaps, voids, credit notes or retention periods, because those are the things the top of this page says vary by country; the methodology page lists sequential numbering among the deliberate omissions, alongside per-jurisdiction tax rules and tax-number validation. Nothing on this page is tax or legal advice.

The one check it does make is on the date the default is built from. The issue date must be a real calendar date — a fictional invoice dated 2026-02-30 is refused with “Choose a valid document date.” — and the second date cannot precede it: due 1 August 2026 on an invoice dated 12 August 2026, the engine answers “The second date cannot be before the document date.”. A document that fails either check is not built at all, so a default number is never derived from a date that does not exist.

Related guides

The guides index lists everything on this site. Closest to this page: how invoice totals are computed walks the money engine line by line; inclusive vs. exclusive tax arithmetic shows why tax inside a price is found by division rather than subtraction; receipts, quotes and the bottom-line label covers the words each document ends on. Payment terms covers the due date that sits beside the number, and invoice vs. receipt vs. quote which document to issue.

Questions

Every figure, label and message above was computed by the engine when this page was built, from fictional documents, so the page cannot disagree with the tool. Nothing you enter leaves your browser; the methodology page sets out the arithmetic and the limits in full.