Invoice Date vs Supply Date in Structured Invoice Data

The invoice date and supply date describe different events. The invoice date concerns the document’s issue event in the relevant process, while a supply date concerns the goods or services underlying the charge. They can coincide, but copying one into the other without checking can lose information the recipient or applicable rules require.

The identifier and date workflow keeps each date role separate. EInvoiceCreator currently provides issue and due dates, not a complete dedicated supply-date or service-period model. A readable date in a note does not prove that the corresponding structured field has been generated for an external profile.

Establish the underlying event

Use the order, delivery evidence, accepted milestone or service record to identify the relevant supply timing. Do not infer it solely from the day the document was prepared or downloaded. The commercial and legal significance of the event depends on the transaction and applicable rules, which the editor cannot determine.

For a fictional goods invoice, the preparation records could show delivery on 6 October and a separately confirmed issue event on 15 October. Those two dates are not interchangeable simply because both relate to the same charge. Keep the source evidence for each.

For services, a period may be more informative than a single date. A month of maintenance, a series of sessions or a completed milestone can require distinct explanation. Do not compress every arrangement into the issue date because the initial form has fewer date fields than the final recipient process.

Check applicable requirements without generalising

The European Commission’s overview of full VAT invoices identifies transaction or payment-date information where relevant within its scope. That does not mean a generic creator can determine the correct legal timing for every business. National provisions, transaction facts and the intended document type still require appropriate checking.

If the supply timing affects a tax decision, seek suitable advice with the relevant facts. Do not change a source date to obtain a preferred tax period or payment outcome. The application does not provide tax-point analysis or legal issuance advice.

Where a recipient specification requires a dedicated supply date or period, retain the exact requirement and version. A field named “date” in one application is not automatically a substitute for every business term with a date value.

Keep issue, supply and due information separate

The issue date identifies one document-related event, while the due date expresses the confirmed payment deadline. Neither automatically establishes when the goods or services were supplied. Keep the three roles labelled in the preparation sheet before entering anything into the editor.

A fictional service completed in September may be billed through an October process with a later agreed payment deadline. That example illustrates distinct facts, not permission to choose any issue date or payment term. Confirm each value according to the actual agreement and applicable requirements.

If a customer gives an ambiguous instruction such as “use the September date”, ask which role it means. It could concern the service period, an order date or a requested document field. Guessing can make a technically valid date represent the wrong event.

Record periods without losing their boundaries

For ongoing or multi-day work, preserve start and end dates and explain which work they cover. The service-period preparation guide addresses that range in more detail. A month label can help a human reader, but a structured recipient may require specific dates in specified elements.

Check whether different lines concern different periods. An invoice-wide note stating one period can mislead if only some items relate to it. Preserve the line relationships for a supporting mapper rather than assuming one global date can describe all work.

Do not use the due date box to store a service-period end merely because it is another available date input. That mislabels the information and can contradict the payment instructions. A missing model feature should remain a clear requirement for the next stage.

Use the current creator honestly

Enter the confirmed issue and due dates in their intended fields. Where a readable explanation of the supply period is appropriate, a description or note can help a person understand the invoice. State the remaining structured requirement separately when the final recipient needs dedicated elements.

The current application JSON preserves its own fields, while printable output provides a human-readable document. Neither establishes an EN 16931, XRechnung or other verified mapping of supply timing. A successful local export should not be described as proof that all date requirements are satisfied.

The application checks calendar validity for its issue and due fields and rejects a due date preceding issue. It does not check the legal relationship between issue and supply events or confirm the evidence behind a service period.

Review the actual document and next task

Read the date labels and any period descriptions together. Compare them with the source records and customer instructions. Ensure a note does not contradict a line description or imply that a payment deadline is the supply date.

If supporting software is needed, hand over the confirmed date roles, values, period relationships and relevant specification. Clear preparation keeps the information available without disguising the current model’s limit. The result is a coherent source record for later mapping and review, not a determination that the transaction’s timing has been legally validated.