Check an invoice date against the calendar and the source record. A date can be invalid because the stated day does not exist, or valid but wrong because it identifies a different event. EInvoiceCreator checks calendar validity for its issue and due fields; it cannot establish that a valid day is the appropriate date for the transaction.
Use the identifier and date workflow to confirm each field’s role first. A calendar check is useful only after you know whether the value represents issue, payment deadline or another event. Do not replace correct facts merely to obtain a clean validation result.
Check the complete day, month and year
Review all three components rather than the part that looks unfamiliar. Months have different lengths, and February depends on the year. A source entry saying 31 April is not a real calendar day; a date such as 29 February needs a year that actually supports it.
For an illustrative comparison, 29 February 2028 is a real day, while 29 February 2026 is not. These examples test calendar mechanics, not which day should be used on a particular invoice. If a source record contains an impossible date, ask for clarification rather than choosing the nearest date by guesswork.
Also check the year after copying an older draft. A date can remain valid while belonging to the previous billing period. The form will not know that an otherwise valid year is inconsistent with your agreement or records.
Distinguish display from stored value
A browser date control may present the day according to local conventions while storing a standard date value for the application. Inspect the intended day and field label rather than assuming that the visible order of short numeric components matches another system’s display.
The current model uses year-month-day date strings for its issue and due values. Validation checks the supported shape and whether the calendar day survives date parsing and comparison without changing. It is not a universal parser for every written date format a customer might send.
The ambiguous-date-format guide explains why a value such as 04/05 needs clarification across different conventions. A string that one person reads as 4 May may be read differently elsewhere. Preserve an unambiguous source representation before entering the final value.
Be careful with pasted and imported information
When copying from a spreadsheet, email or document, establish what the source cell or text represents. A spreadsheet display can hide a different underlying value, while a short text date can omit the year. Do not infer missing components simply because the current month or year seems likely.
EInvoiceCreator imports only its own supported editable JSON structure, not arbitrary spreadsheet files or PDF extraction results. A compatible draft can still contain invalid or outdated values that need review. Importing the structure does not verify the business event represented by the date.
If external software creates the preparation data, check that it supplies the date-only values the model expects rather than a timestamp or an informal phrase. Do not remove parts of a timestamp without understanding whether that changes the intended calendar day.
Keep timestamps and date-only events distinct
A timestamp records a moment with additional time information, and timezone interpretation can affect which calendar day is shown. A date-only invoice field expresses a calendar date in its intended role. Converting between them needs a deliberate interpretation of the source, not a casual truncation performed because the form wants fewer characters.
For a fictional preparation record, an email arrival time is evidence of when a message arrived, not automatically the invoice’s issue date. Likewise, a file’s download timestamp does not establish a supply date or payment deadline. Use the confirmed business source for the field.
The application does not reconcile timestamps from a customer portal or provide an issuance-time audit trail. Keep those external records separately where they matter to the process.
Understand the limits of a valid-calendar result
After the day is valid, review its relationship to the other fields and the source agreement. The creator also checks that the due date does not precede issue, but it does not confirm that the resulting interval matches the agreed payment terms. A valid pair can still be commercially wrong.
If the actual transaction needs a date relationship or document type that the current editor cannot represent, use appropriate supporting software. Do not change a historic fact merely because a simpler preparation tool accepts another value.
Verify the final representation
Read the dates in the preview and the actual exported file. Confirm that each label still matches the intended role and that a copied note does not show a contradictory value. Review loaded drafts and earlier downloads independently; they do not update automatically when the open form changes.
When a date error appears, follow the error link to the affected issue or due field. Compare its value with the confirmed source, re-enter the intended date and run the checks again. Review the preview after the correction, because changing an input is not the same as inspecting the finished result.
If the source record itself was corrected, retain that clarification with the preparation evidence. Do not silently replace a historic fact in an already issued document; establish the appropriate correction process before treating the revised draft as a final version.