How to Prepare Invoice Identifiers, Dates and Document Types

Prepare invoice identifiers, dates and document types as distinct facts. The invoice number identifies the document in your records, the dates describe different events or terms, and the document type identifies the business document being prepared. A familiar reference or a valid-looking date does not establish that those facts are correct for the transaction.

EInvoiceCreator currently prepares ordinary positive invoices. It requires an invoice number, issue date and due date, and checks certain input rules. It does not maintain a business-wide invoice register, verify number uniqueness, create credit notes or manage the legal status of issued documents. Use this guide to prepare the supported information while keeping wider requirements explicit.

Allocate a document reference from your records

Choose the invoice number using the process established for your business and the applicable requirements. Do not treat a form’s starting value as an available number. Another invoice might already use that reference in a spreadsheet, accounting package or document prepared by someone else.

The invoice-numbering preparation guide explains how to maintain an understandable pattern and check it against a register. A pattern can help operators work consistently, but its appearance alone does not establish uniqueness or legal compliance. An editor cannot know about records it never receives.

Keep the invoice number separate from the customer’s order, internal buyer reference and payment reference. A business can deliberately reuse a value in more than one role, but the roles remain distinct. Do not overwrite the document identity with an order number merely because that is the most visible code in the customer instruction.

Record what each date means

An issue date identifies the document’s issue event in the relevant workflow. A due date expresses when payment is due. A supply date or service period describes the underlying goods or work. These facts can coincide, but they should not be collapsed into one date by default.

The issue-date and due-date guide focuses on the payment-related distinction. Confirm the dates from the agreement, billing process and relevant records instead of assuming that a blank form’s initial values are the right answer. The current product does not establish contractual payment terms automatically.

Where a supply date or service period is needed, preserve it separately. The current creator has no complete dedicated structured supply-date or service-period model. A readable note may explain the period, but it is not a substitute for required elements in a recipient’s final specification.

Use a consistent date representation

Enter dates through the provided controls and inspect the preview for the intended calendar day. When sharing preparation information between systems, use an unambiguous representation and retain the meaning of the field. A string such as 04/05 can be interpreted differently across regional conventions.

The current validation checks whether the issue and due values are real calendar dates in its supported representation. It also rejects a due date preceding the issue date. Those are application rules, not a determination that every legally possible invoice scenario fits this editor. If correct source facts cannot be represented, use suitable supporting software rather than altering them to obtain a pass.

Do not replace a historic supply date with today’s date because a new draft opens today. Likewise, do not infer a service period from when you happened to download a file. The source event and the preparation action are different facts.

Establish the document type before entering amounts

Determine whether the task concerns an ordinary invoice, a correction, a credit note, an advance-payment document or another supported type in the relevant process. The correct type can influence references, signs, calculations and validation. A changed heading alone does not implement those differences.

The current creator accepts non-negative prices and positive quantities for ordinary invoice preparation. It does not create credit notes or a full prepayment and reconciliation structure. Do not simulate an unsupported type by changing prices, hiding adjustments in descriptions or relabelling the output file.

For a fictional returned-goods transaction, a new ordinary positive invoice is not automatically the right representation of the correction. Establish the applicable process and use software that supports the necessary type and links to the original document. The editor cannot make that legal or accounting decision for you.

Keep document identity separate from procurement references

Record the customer’s order, routing or contract values with their own labels. The reference-role comparison shows why an invoice number, order number and payment reference answer different questions even when a small business uses similar text for several purposes.

For example, the fictional invoice “INV-2026-084” could relate to the customer’s “PO-602” and ask the payer to quote a particular payment reference. Combining the three values into one number field may make later reconciliation harder. Keep their intended relationships clear in your preparation records and any external mapping.

The current model provides one general buyer reference and separate payment reference text. It does not implement every typed order, contract and preceding-document reference in recognised standards. Preserve extra requirements for supporting software instead of claiming that any text field supplies the necessary structure.

Review changes according to document status

A working draft can be revised before the appropriate issuance step. An already issued invoice can require a particular correction process. Do not assume that editing a downloaded JSON file or changing a PDF creates a valid replacement while preserving the original record.

The issued-invoice correction preparation guide explains what to clarify before acting. Keep the original reference and evidence, identify the affected facts and obtain appropriate advice where required. The current product has no issued-document ledger or authoritative status history to resolve those questions.

A changed invoice number can also leave stale values elsewhere in the document. Review payment references, notes and descriptions rather than changing only the prominent header. A passed field check does not discover every relationship between those text values.

Check a complete preparation example

Suppose a fictional consultant is preparing an ordinary invoice for work performed during September. The allocated invoice number comes from its register, the issue date comes from the applicable billing process and the due date comes from the confirmed payment terms. The service period remains a separate fact, even if all preparation happens in October.

In that example, the source could identify work from 8 to 12 September, a confirmed issue date of 15 October and an agreed due date of 29 October. The two-week payment interval is illustrative, not a recommended term. Keep the September service period separately rather than overwriting the issue date to make the work period visible.

Enter the supported values and review them against the source records. If the final customer requires a structured period or preceding-document reference not in the current model, retain that requirement for an external generator. Do not discard the information because the preview has no dedicated box for it.

You can prepare the confirmed identifiers and dates in the creator when the ordinary invoice workflow fits the task. Run field checks, then inspect the actual output and selected version. The printable invoice, application JSON and line-items CSV do not establish standards conformance or successful delivery.

Keep the result traceable

Retain the allocation record, relevant date evidence, document-type decision and any correction instruction with the reviewed files. A useful hand-off identifies what was prepared and what still requires an external system. It should not report a unique-number check, legal issuance event or formal validation that the product did not perform.

Clear document identity makes later questions easier to resolve. The practical objective is a record whose number, dates and type describe the intended transaction and process, without letting a convenient default or editable file stand in for the business decision.