An invoice creator cannot confirm business-wide number uniqueness unless it has access to the relevant records and an allocation process covering them. A required number field can check that a value is present without knowing whether another operator used it in a spreadsheet or accounting package. The current EInvoiceCreator has no shared invoice register or number-reservation service.
Use your business’s reference-allocation records before treating a draft number as final. The identifier and date preparation workflow separates the document identity decision from entering the value. The field accepting the number is evidence of an accepted input, not evidence that the reference is unused.
Identify the records the application can see
The current browser workspace knows the open invoice and an explicitly saved local draft when you load it. It does not read other people’s documents, older downloads, another browser profile or accounting systems. Those records can all contain invoice numbers that matter to your business.
Saving a draft on this device does not create an account-based invoice history or a business-wide uniqueness index. Importing an editable JSON file also does not compare its reference against every other invoice. It brings supported application data into the current working document.
A uniqueness claim should therefore identify its scope. A check within one dataset is not automatically a check across every series, user, branch or historical record. Do not describe a local non-empty-field check as a universal duplicate-number search.
Recognise the simultaneous-entry problem
Imagine two fictional operators opening blank drafts on different devices. Both see an initial reference and both decide it appears available. Without a shared allocation process, each can prepare a document with that same number. Their calculations and required fields can all be correct while the business record contains a conflict.
The problem can also occur in two tabs or two files prepared by one person. Copying an old draft saves typing but can preserve its reference. Changing the customer and amounts does not automatically establish a new document identity.
The numbering-pattern guide explains why a readable convention needs controlled allocation. A prefix can organise references, but adding a prefix by itself does not prevent two people choosing the same next value.
Check the allocated value independently
Use the register or system appropriate to your business to identify the next authorised reference. Check the relevant series and existing records according to the applicable process. Do not assume that a filename search alone covers every invoice, particularly when downloads have been renamed or stored elsewhere.
Record the allocation so that another operator can see it. If references are reserved for drafts, define how those reservations are managed in your business process. The current creator neither reserves a number nor releases it when a tab closes.
Check meaningful characters and leading zeros when transferring the reference. A spreadsheet may store a numeric-looking value differently from a text field. Compare the entered number with the allocation record after copying rather than relying on visual familiarity.
Distinguish reuse from correction
Reopening an existing draft can legitimately preserve its number because it is the same working document. Starting an invoice for a different transaction with an old number is a different situation. Establish whether you are continuing the original preparation or creating a new document.
If a number conflict is discovered after a document has been issued, do not silently renumber files and pretend the original references never existed. Follow the applicable correction and recordkeeping process using suitable supporting software or advice. The current product does not maintain issued status or an authoritative change history.
Similarly, a corrected invoice or credit note can need a distinct document identity and a reference to an earlier document under the relevant requirements. Do not infer those rules from a blank form’s editable number box.
Keep other references in their roles
A customer purchase order can appear on several invoices, while an invoice number identifies a particular document. A project code can also relate to many supplies. Do not use the presence of a matching order or project as evidence that a repeated invoice number is acceptable.
A payment reference may deliberately repeat an invoice number in a simple process, but its entry does not establish number allocation. Review the relationship after any number change so that payment instructions do not retain an old or conflicting value.
The browser may also sanitise download filenames. The number inside a file and the filename are related but not identical records. Open the document and consult the allocation record instead of treating the latest downloaded filename as the sole evidence of identity.
Record the review result accurately
A useful preparation record identifies the number, relevant series, allocation source and reviewed document. If a duplicate search was performed in another system, describe the system and scope rather than attributing that check to the browser creator.
The current application can store and display the confirmed reference and check that required input is present. Its ordinary exports do not verify uniqueness or establish legal issuance. Keeping those limits explicit allows the tool to support a controlled process without pretending that a standalone editor has knowledge of the business records it never receives.