If the recipient does not specify a due date, check the agreement and your confirmed payment arrangement before entering one. An invoice instruction can omit a deadline because payment terms are documented elsewhere; it can also leave a genuine question unresolved. Do not assume a standard interval or copy the issue date simply to fill the current creator’s required due-date field.
The identifier and date workflow keeps source decisions separate from application requirements. EInvoiceCreator requires a due date for its current ordinary invoice export process, but that form rule does not establish which payment deadline is appropriate for every transaction.
Check the agreement before asking again
Review the accepted quotation, contract, purchase order and any relevant customer arrangement. Identify whether the payment term specifies a date, interval, starting event or another condition. Do not assume that a brief supplier-onboarding guide contains every commercial term that applies.
If the term uses an interval, establish how it is calculated under the actual agreement. Calendar days, business days and different starting events are not interchangeable. The application does not interpret the contract or calculate a legal deadline from an informal phrase.
For a fictional consultant, a customer guide might say how to submit an invoice without stating payment terms, while the accepted quotation contains the agreed arrangement. The preparer should reconcile those sources rather than choosing the form’s starting date as the answer.
Ask a focused clarification
If the deadline remains unclear, ask the appropriate customer contact or adviser which payment term applies to the transaction and how the due date should be established. Include the relevant order or agreement reference. A specific question is more useful than asking the customer to approve a draft whose date was guessed.
Distinguish “not shown in this guide” from “confirmed not applicable”. Silence does not establish either a particular deadline or permission to invent one. Record the response and source in the preparation sheet so the person entering the date can see what was confirmed.
The issue-date and due-date explanation helps if the confusion concerns field meaning. A service-period end, order date or document download date should not be repurposed as the payment deadline merely because it is available.
Keep uncertain information visibly unresolved
Mark the due-date question as pending while retaining the other confirmed invoice facts. You can continue preparing the ordinary line information, but do not present a provisional date as final merely because the preview looks more complete with every box filled.
The current creator can preserve an incomplete editable JSON draft and explicitly save one draft on the device. Those working copies are not validated final invoices. Later edits are not automatically saved, so deliberately preserve the version you intend to resume after receiving the answer.
Do not remove a relevant qualification from the preparation record when passing the draft to another person. A reviewer who sees only a complete-looking date may reasonably assume that somebody confirmed it. Keep the unresolved question attached to the working process, not hidden in a private memory.
Recognise the application’s limitation
The field checker requires a due date and rejects one preceding the issue date. These are the application’s accepted input rules. They do not provide legal advice on payment periods or establish that every recipient format requires the same field in the same circumstances.
If the correct workflow genuinely does not supply a due date that fits this model, use appropriate supporting software rather than inventing a deadline to bypass validation. The final format or process may express payment information differently under its own rules. Confirm that representation through the applicable specification and instructions.
EInvoiceCreator currently produces printable output, application JSON and line-items CSV. None is a verified implementation of every recognised format’s payment-term model. A date present in those outputs does not prove that an external recipient requirement has been met.
Review text and dates together
Once the deadline is confirmed, enter it and compare the written payment instructions. A header showing one date while notes describe another term can create avoidable confusion. Do not assume a reader will know which version you intended. Run the field checks again and follow any remaining date error back to the affected input. A clarified payment term can still be mistyped, and the form cannot correct the result automatically.
If a term changes after a document was issued, identify the appropriate agreement and correction process. The current creator does not notify the recipient, maintain issued-invoice status or automatically update earlier exports. A revised local draft is not evidence that the customer accepted a changed payment arrangement.
Keep evidence with the reviewed version
Record the confirmed term, source, calculation basis where relevant and the resulting date. Check the actual exported file selected for sharing rather than relying on the current browser view. An older download can still contain the earlier unresolved or provisional value.
The practical objective is a deadline grounded in the actual arrangement and represented by a suitable system. A required form field is a prompt to obtain that information, not a rule that creates the underlying payment agreement.