billable.devInvoice Numbering for Freelancers: Pick a System
By Mark Fulton · 2026-08-18 · 11 min read
Use 2026-0001. Four digit year, a hyphen, then a four digit zero padded counter that increments by one for every invoice you issue, across every client, and is never reused for any reason. That is the whole spec. It sorts correctly in a file browser, it tells you at a glance which tax year an invoice belongs to, it survives you picking up a second and third client, and it satisfies the "unique and sequential" language that tax authorities use. If you have been putting this decision off, copy that format and stop thinking about it.
The rest of this post is the reasoning, the three alternatives and where each one breaks, and the edge cases that actually cost people time: voided invoices, the January reset question, and moving a year of ad hoc numbers onto a real system without rewriting history.
Does invoice numbering actually matter?
It matters in two places, and neither of them is aesthetics.
The first is retrieval under pressure. Every conversation about money references the number. The client's accounts payable team pays "invoice 2026-0014," your bank memo says 2026-0014, your follow up email subject line says it, and eighteen months later when someone asks which invoice covered the March migration work, the number is the key you search on. A number that is unique and ordered makes that lookup instant. A number that repeats, or that you invented on the spot, makes it a manual search through PDFs.
The second is the paperwork requirement. In the UK, government guidance on what an invoice must include puts "a unique identification number" at the top of the list, before your own name and address. In the EU, the European Commission's invoicing rules require a full VAT invoice to carry a unique sequential number identifying the invoice, which comes from Article 226 of the VAT Directive. In the United States the emphasis is different: IRS Publication 583, Starting a Business and Keeping Records, is explicit that "except in a few cases, the law does not require any specific kind of records," and asks instead that your system clearly show income and expenses and that you keep the supporting documents until the period of limitations runs out, generally three years for most returns.
So the requirement is jurisdictional, but the shape of the answer is not. Two of the three regimes above name uniqueness or sequence directly, and the third cares that your records reconcile. A single unbroken counter satisfies all of them without you having to know which rule you fall under.
The engineering framing that makes the rest of this easy: the invoice number is a primary key, not a description. Its only job is to identify one document unambiguously and forever. Client name, project, dates, purchase order references and currency are all fields on the invoice already. Every scheme that goes wrong goes wrong because someone tried to encode metadata into the key.
Which format should a freelancer use?
Four schemes are in common use. Here is what each does well and the specific way each one fails.
| Scheme | Example | Good at | Failure mode |
|---|---|---|---|
| Plain sequential | 0001, 0002 |
Simplest possible rule. Impossible to get wrong. Uniqueness is automatic. | Carries no era information. Come tax time you cannot tell where one year ends and the next begins without opening every file, and by year four you are reading 0312 with no idea when it was issued. |
| Year prefixed | 2026-0001 |
Sorts chronologically as text, groups by tax year, still one global counter. Reads as deliberate to a client. | You have to decide once whether the counter resets in January. That is it. If you never decide, you drift between the two and create ambiguity. |
| Client prefixed | ACME-0007 |
Groups a client's invoices together in a folder listing. Feels tidy when you have three clients. | Breaks the single sequence into parallel ones, so a gap in any series is invisible. Renaming or losing a client orphans a prefix. If your jurisdiction requires sequential numbering, each series has to be sequential on its own, which is more bookkeeping, not less. |
| Date based | 20260818-01 |
The issue date is legible from the filename alone. | Two invoices on one day force a suffix, so you end up maintaining a counter anyway. Reissuing a corrected invoice on a later date leaves the number contradicting the date field on the document. Long numbers get mistyped in payment memos. |
The year prefixed scheme wins because its one open question has a clear answer (below), and because it is the only one of the four where the number stays a pure identifier while still telling you something useful. Client and project codes belong in the body of the invoice, next to the other fields that decide whether it gets approved quickly, where a human reads them and where you can change them later without touching the key.
Two details on the format itself:
Zero pad to four digits. 2026-0007 sorts before 2026-0012 in every file browser and spreadsheet. 2026-7 does not. Four digits covers more invoices than a solo freelancer will issue in a year with room to spare.
Skip the INV- prefix unless you like it. It adds no information, since the document already says "Invoice" at the top in large type. It is harmless. It is just three more characters everyone has to type in a payment reference.
How do you handle voided or cancelled invoices?
The rule is one line: a number that has been issued is spent forever. You do not reuse it, you do not delete it, and you do not renumber the invoices after it to close the gap.
What you do instead depends on how far the invoice got.
Not yet sent. Mark the record void in whatever you use as a ledger, keep the file, and issue the next number for the corrected version. If you generated 2026-0011 and immediately noticed the rate was wrong, 2026-0011 stays void and the real invoice is 2026-0012. The whole cost of this is one line in a spreadsheet.
Sent, not yet paid. Tell the client the invoice is cancelled and replaced, then send the replacement under a new number that references the old one in its notes: "Replaces invoice 2026-0011, cancelled." Their accounts payable system may have already created a record, and a replacement with an explicit reference is far easier for them to process than a second document with the same number, which many systems will reject outright as a duplicate.
Sent and paid, or already in a filed return. Do not touch the original at all. Issue a credit note, which is a separate document with its own number, and then a fresh invoice for the correct amount if one is owed. In VAT jurisdictions this is not a preference, it is how corrections are meant to be recorded, and your accountant will thank you for it.
The reason for the "never reuse" rule is auditability. A gap in your sequence is a question, and a void record is the answer to that question, filed in advance. A reused number is a different situation entirely: two documents with one identifier, one of which is going to be the wrong one when someone pulls it up.
Should numbers reset each year?
Both policies are defensible. Pick one and write it down.
Reset annually with a year prefix. 2026-0001 through 2026-0043, then 2027-0001 on the first invoice of the new year. This is the default I would recommend. Uniqueness is preserved by the prefix, so nothing is at risk, and the count within each year is immediately useful: the last invoice of the year also tells you how many you issued. Grouping by tax year falls out for free when you hand a folder to an accountant.
Continuous forever. 2026-0001 up to 2026-0043, then 2027-0044. The prefix becomes decorative but the counter never restarts. This is slightly safer in one narrow sense, since the number alone is unique even if the prefix is dropped or mangled by some downstream system.
What you must not do is reset the counter without a prefix. Restarting at 0001 every January means you will have two invoices numbered 0001, then 0002, and so on, which breaks the one property the number exists to provide. If you already did this, the migration section below is for you.
One caution worth stating plainly: rules on numbering series vary by country, and some tax regimes have specific expectations about how series are structured, when they may restart, and how they must be documented. If you are VAT registered, or you invoice across borders, confirm your specific position with your own tax authority or an accountant before you settle the policy. This post is general information, not tax or legal advice.
How do you migrate an existing mess?
Assume the realistic starting point: eleven invoices with numbers like 1, 2, Invoice-3, march-invoice, 0004, and two different documents both called 5. Here is the migration, in order.
1. Do not renumber anything that has been sent. Those numbers exist in your clients' accounting systems, in bank memos, and possibly in a filed tax return. Rewriting them creates a mismatch between your records and theirs, which is the exact problem you are trying to escape. History is append only.
2. Draw the line at today. Your next invoice is 2026-0001 if you are resetting per year, or 2026-0012 if you would rather the counter continue from the eleven you have already issued. Both are fine. Continuing the count is marginally tidier if the old numbers were roughly sequential to begin with.
3. Write down the switch. One line in a notes file or at the top of your bookkeeping sheet: "Invoices before 2026-08-18 use the old ad hoc numbering. From 2026-08-18 the format is YYYY-NNNN, one counter, no reuse." That sentence is what you or your accountant reads in two years when the numbering looks inconsistent, and it costs thirty seconds now.
4. Reconcile the duplicates in your ledger only. For the two documents both numbered 5, add a disambiguating note in your own records ("5 (Acme, 12 June)" and "5 (Brightline, 3 July)") so you can tell them apart. Do not send corrected copies to clients who have already paid. The goal is that your records are unambiguous, not that the past is pretty.
5. Let the tool hold the counter from here. The single most common cause of numbering drift is a human trying to remember where the sequence got to while working from a duplicated file. Anything that increments automatically removes the failure. If you are setting up your billing process from scratch, the rest of the workflow is covered in how to invoice as a freelance developer.
That is the entire migration. It takes about ten minutes and no invoice changes hands.
FAQ
Can two invoices share a number?
No. This is the one rule with no exceptions. Two documents with the same identifier means every future reference to that number is ambiguous, including payment references, follow up emails, and anything an auditor pulls. It also breaks real systems: many accounts payable platforms reject a second invoice from the same supplier carrying a number they have already recorded, so a duplicate can stall a payment that had nothing wrong with it. If you discover a duplicate after the fact, leave both documents alone and disambiguate them in your own ledger.
Do invoice numbers have to be sequential for taxes?
It depends entirely on where you are, which is why "yes" and "no" are both wrong as general answers. In the EU, a full VAT invoice must carry a sequential number that uniquely identifies it, under Article 226 of the VAT Directive. UK guidance requires a unique identification number on every invoice, with additional requirements for VAT invoices. In the United States, the IRS does not prescribe an invoice number format at all and instead requires that your recordkeeping system clearly show income and expenses with supporting documents behind it. A single unbroken counter satisfies all three, which is the practical reason to use one even if your own jurisdiction is relaxed about it. Confirm your specific obligations with your tax authority or accountant.
What number should my first invoice be?
2026-0001, using the current year. The advice to start at 1000 so you look established is worth ignoring. Any client who cares is not making the deduction, any client who does make it is not deciding anything on it, and you have permanently added three meaningless digits to every payment reference you will ever send. Starting at one also has a small practical benefit: the counter is an honest count of the invoices you have issued this year.
Should client codes go in the invoice number?
No. Put the client name in the "billed to" block where it belongs and where a human actually reads it. Encoding the client into the key creates parallel sequences that hide gaps, and it locks you into a code you may need to change when a client rebrands, restructures, or gets acquired. If you want to find every invoice for one client, that is what search and a column in your records are for. The exception is genuinely separate businesses under one owner, where separate numbering series per business can make sense, since they file separately anyway.
Sources
- GOV.UK, Invoices: what they must include
- European Commission, VAT invoicing rules
- IRS, Publication 583, Starting a Business and Keeping Records
Ready to put the format into practice? Generate this invoice free at billable.dev. Set the format once and the counter increments in your browser from then on, so the sequence stays clean without you tracking it anywhere. There is no account and nothing leaves your machine. If you would rather start from a filled in layout, the free invoice template for developers shows the structure, and Pro ($4 a month billed as $24 every 6 months, or $79 once) keeps the saved history so next year's first invoice already knows what number it is.
This post is general information, not tax or legal advice. Invoice numbering requirements differ by country and by tax registration status. Check your own position with a qualified professional in your jurisdiction.