Enter the issue date according to the relevant invoicing process and the due date according to the confirmed payment arrangement. They describe different facts: one concerns the document’s issue event, while the other concerns when payment is due. They can be the same day, but that should be a deliberate result rather than an unnoticed blank-form default.
The document identifiers and dates guide separates these fields from the supply date and service period. EInvoiceCreator currently requires issue and due dates and checks certain calendar rules. It does not determine contractual payment terms or establish the legal issue status of a document.
Establish the issue date from the actual process
Use the confirmed billing instruction and applicable requirements to establish the issue date. Do not change it merely to make an invoice appear newer, match a service period or fit an expected payment window. The current editor accepts a date value but cannot decide whether that value is appropriate for the transaction.
A draft may be opened on one day and reviewed or issued through an external process later. Those preparation actions do not automatically establish the same date for every purpose. Keep the source decision clear so another person can distinguish when data entry happened from the relevant issue event.
For a fictional supplier preparing work completed in September, a confirmed October issue date can be a different fact from the work period. If a particular rule requires supply information, preserve it separately rather than replacing the issue date with the first day of the service period.
Establish the due date from confirmed terms
Check the agreement, order and customer arrangement for the payment deadline. Terms can differ in how an interval is calculated, so do not assume every mention of “30 days” uses the same starting event or business-day convention. Resolve ambiguity with the appropriate contact or advice rather than treating a generic editor as a contract interpreter.
The current creator does not calculate payment terms automatically. You enter the due date that has been confirmed. A date that follows the issue date can pass the application’s order check while still being inconsistent with the actual arrangement.
A fictional invoice might have a confirmed issue date of 15 October and agreed due date of 29 October. That example illustrates separate entries, not a recommended payment term. The source arrangement, not the example’s two-week gap, determines the actual deadline.
Review the blank-form defaults
The blank workspace begins with date values that need review. Do not assume the due date was calculated from your business’s preferred terms or the customer’s order. The product does not know those terms merely because seller and buyer details were entered.
You can prepare the invoice with its confirmed dates in the creator, then inspect the header in the preview. Compare each date independently with the preparation records. A familiar current date can distract from a due date that was never changed from the starting value.
If reusing a saved draft, review both dates again. The draft may belong to an earlier transaction, and a structurally valid import does not establish that its dates apply now. Loading or importing does not turn the file into a newly issued invoice.
Understand the application’s date checks
The creator checks whether the entered issue and due values are real calendar dates in its supported representation. It also rejects a due date preceding the issue date. These are application rules for this ordinary preparation workflow, not a universal determination about every invoice scenario.
The earlier-due-date troubleshooting guide explains how to investigate that error without altering correct facts merely to obtain a pass. Check the source, field roles and any imported representation first. If the actual transaction requires a structure the current product cannot represent, use suitable supporting software.
A valid date check cannot confirm the payment agreement, supplier’s authority to bill or recipient’s acceptance. Keep those reviews separate. A passed result should be reported as application field checks, not as verification of the invoice’s legal or commercial validity.
Keep payment text consistent
Read any written payment terms and payment instructions beside the due date. If one says a different deadline or interval, resolve the contradiction before sharing. Do not assume that a recipient will ignore the conflicting text because the header has a clear date.
When a due date changes after review, identify the affected version and any necessary agreement or correction process. The current creator does not notify the customer, maintain issued-document history or update earlier downloads. Changing an open draft does not rewrite a PDF already attached elsewhere.
Check the actual output and hand-off
Inspect the date values in the printable document or selected application export. Browser display conventions can differ from the stored representation, so confirm the intended calendar days rather than relying on an ambiguous short date seen in another system.
Keep the evidence for the issue-date decision and payment deadline with the reviewed version. If a final structured format or external platform needs additional date fields, retain those requirements separately. The current printable, JSON and CSV outputs do not establish that every target profile’s date model has been implemented.
Accurate date preparation preserves the meaning of each event. It does not turn a starting value, a successful download or a valid calendar string into evidence that the relevant business decision was made.