What the Purchase Order Number Generator does
This generator designs a purchase order numbering scheme and produces the numbers from it. A pattern is a plain string with tokens in braces - PO-{YYYY}-{SEQ:5} gives PO-2026-00042 - and everything outside a token is copied through exactly as written. Prefixes, department and supplier codes, calendar or financial year parts, zero-padded sequences and an optional check character are all available.
It is deterministic: the same pattern and the same starting number always produce the same list, so a run can be repeated and reconciled. Nothing is reserved anywhere, so the page checks the run for duplicates, checks it against numbers you have already issued, and warns when the sequence is about to outgrow its padding - the three ways numbering schemes actually break.
How to use it
- Build the pattern, either by typing it or by clicking the token buttons.
{SEQ:5}pads the sequence to five digits;{FY}uses the financial year start month you set. - Fill in the prefix, department and supplier codes your pattern uses, and set the date the numbers should carry.
- Choose a check character if you want one: Luhn mod 10 over the digits, ISO 7064 MOD 11,2 over the digits, or MOD 37,2 over letters and digits.
- Set the starting number, how many to generate and the step, then paste any numbers already issued so clashes are caught.
- Copy the list or download the CSV, and record the next sequence number shown under the first one.
Reading the results
The headline shows the first number and the last, plus the next sequence to use. Write that last figure down: nothing here remembers it for you.
A duplicate inside the run means the pattern does not contain enough of the sequence to stay unique - usually a missing {SEQ}.
A clash means the number already appears in the list you pasted. Move the start past the highest number issued rather than skipping the clash.
"The sequence outgrows its padding" matters because PO-999 and PO-1000 no longer sort as text. Widen the padding before the run, not during it.
Worked example: a monthly scheme with a Luhn check digit
The pattern PO{YY}{MM}{SEQ:4}{CHK} with the check set to Luhn mod 10, a date in September 2026 and a starting sequence of 1 produces PO26090001 plus a check digit.
The check digit is computed over the digits only - 26090001 - by doubling every second digit from the right, subtracting 9 from any result above 9, summing, and taking whatever makes the total a multiple of 10. For 26090001 the doubled-and-reduced digits are 2, 0, 0, 0, 9, 0, 3, 2, which sum to 16, so the check digit is 4 and the first number is PO260900014.
The classic worked example of the same algorithm is 7992739871, whose check digit is 3: the Luhn total of 79927398713 is 70, a multiple of ten. The engine's generated digits are tested against the site's independent checksum engine, so the two always agree.
Generating twenty numbers from that pattern gives PO260900014 through PO260900204, all unique, with the next sequence reported as 21.
Formulas and scoring rules
- Zero padding
{SEQ:n} pads the sequence with leading zeros to n digitsA sequence longer than n is not truncated - it simply gets longer, which is why the run is checked for overflow.- Financial year
FY = year when month >= start month, otherwise year - 1With an April start, February 2026 is FY2025.- Luhn check digit (ISO/IEC 7812)
digit = (10 - sum mod 10) mod 10Doubling every second digit from the right and subtracting 9 from results above 9.- ISO 7064 MOD 11,2
p = 0; for each digit d: p = ((p + d) x 2) mod 11; check = (12 - p) mod 11A check of 10 is written X. Worked by hand for 0794 the check is 0.- ISO 7064 MOD 37,2
as above with modulus 37 over 0-9 and A-Z; check = (38 - p) mod 37A check of 36 is written *. Separators are ignored.
Designing a scheme that still works in five years
Three rules cover nearly everything. Put the sequence last or nearly last, so the numbers sort sensibly as text. Pad it wide enough that it never grows - five digits costs nothing and lasts to 99,999. And decide up front whether the sequence resets each year, because a reset means the year part is doing real work and must never be dropped from the pattern.
Avoid encoding anything that changes. Department codes get reorganised, supplier codes get merged, and a purchase order number is forever: it appears on the goods receipt, the invoice, the payment and the audit trail. A number that describes the world of 2026 is a small permanent lie by 2031.
What a check character does and does not prove
A check character catches most single-digit typos and most transpositions of adjacent digits. Over digits alone, Luhn is the familiar choice and ISO 7064 MOD 11,2 is stronger; over letters and digits, MOD 37,2 covers a code like ACME/FAC/2026/0042 as a whole.
What it cannot do is prove that a number was ever issued, that it refers to a real order, or that the goods exist. It is a typing check on the way into a system, not an authorisation. Anyone treating a valid check digit as approval has built a control that does nothing.
Limitations: what the result does not prove
- Nothing is reserved or registered. The generator has no memory between visits; your purchasing system, or a person with a notebook, remains the source of truth for the last number used.
- Clash detection only sees the numbers you paste in. It cannot know what colleagues have issued.
- A check character is a typing check, not a validation of the order, the supplier or the authority to buy.
- At most 5,000 numbers can be generated at a time, to keep the table usable and the tab responsive.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- ISO/IEC 7812-1 - Identification cards: numbering system (Luhn check digit)
- ISO/IEC 7064 - Check character systems
Frequently asked questions
What should a purchase order number look like?
Short, sortable and permanent: a fixed prefix, a year if sequences reset annually, and a zero-padded sequence at the end - PO-2026-00042 is a good default. Avoid encoding anything that can be reorganised later, such as department or supplier codes, unless you are willing to live with them for the life of the archive.
Should purchase order numbers restart each year?
Either works, but be consistent. If they restart, the year part of the pattern is load-bearing and must never be omitted, because the sequence alone is no longer unique. If they run continuously, pad the sequence generously - a scheme that reaches five digits in year three will be six digits by year six.
Why add a check digit to a PO number?
Because people retype these numbers into other systems. A check digit catches most single-digit errors and most swapped pairs at the point of entry, before a payment is matched to the wrong order. It says nothing about whether the order is genuine.
What is the difference between Luhn and ISO 7064?
Luhn (ISO/IEC 7812) is the familiar mod-10 scheme used on payment cards and is easy to compute by hand. ISO 7064 MOD 11,2 catches strictly more errors but occasionally produces an X, and MOD 37,2 works over letters and digits so it can protect a whole alphanumeric reference rather than just its digits.
Can I generate numbers for a financial year that does not start in January?
Yes. Set the financial year start month and use {FY} or {FYY} in the pattern. With an April start, an invoice dated February 2026 carries FY2025, which is what most finance systems expect.
Does the generator remember which numbers I have used?
No, deliberately. It has no storage and no server, so there is nothing to go stale or to leak. Paste the numbers already issued into the box and it will tell you about clashes; keeping the register itself is your purchasing system's job.
Are the generated numbers random?
No. They are entirely deterministic - the same pattern, date and starting number always produce the same list. That is what makes a run repeatable and reconcilable; a random number would be impossible to audit.
Last reviewed by the A2Z.Tools team against the sources listed above.
