If the due date precedes the issue date, compare both values with the source records before editing them. They may be swapped, copied from an older draft or interpreted under different date conventions. The current EInvoiceCreator rejects that ordering, but the error does not establish which source fact should change or determine the legal validity of every possible transaction.
The identifier and date workflow separates the meaning of each field from application validation. Treat the message as a prompt to investigate the entered data and the tool’s scope, not as permission to choose arbitrary dates until the export succeeds.
Check whether the fields were swapped
Read the issue and due labels and compare each with the confirmed preparation sheet. A later payment deadline entered as the issue date and an earlier issue value entered as due can create the error even when both dates are individually real calendar days.
For a fictional invoice with a confirmed issue date of 15 October and agreed due date of 29 October, swapping the entries would make due precede issue. Correcting the swap restores the confirmed facts. It is not the same as changing the payment arrangement or choosing a new legal issue event.
The issue-date and due-date explanation helps where the roles themselves are unclear. Resolve those meanings before comparing intervals or assuming that the latest date belongs in a particular field.
Check for old draft values
A reused or imported draft can retain a due date from an earlier transaction while the issue date is updated. Review both dates after loading rather than assuming that the application calculated a new deadline. The current creator does not interpret your payment terms and update the due date automatically.
Check the year as well as the day and month. An old year can create a substantial ordering difference while the date still looks familiar. A well-formed imported value can be wrong for the current invoice without being an invalid calendar date.
Saving on this device is explicit and stores one draft. Loading that saved copy can restore old values even if another open version had already been corrected. Identify the working version before making a change so that you do not repair one copy and later export another.
Check the source date convention
If dates came from a spreadsheet, email or external process, establish how the source represents day and month. A short value can be interpreted differently across conventions. Do not compare an assumed interpretation with another field’s confirmed representation and conclude that the business records are inconsistent.
The current model uses year-month-day values for the supported date fields. It does not import arbitrary spreadsheet formats or parse every informal date phrase. A compatible editable JSON file still needs its values reviewed for meaning and currency to the transaction.
A timestamp is also different from a date-only event. Do not truncate an external timestamp or use the download day as the issue date without establishing the intended calendar event. The editor cannot reconstruct the source system’s time interpretation for you.
Compare the payment agreement
If the entries match the source, review what the due date represents. It may have been copied from a reminder, an earlier document or another payment record rather than the agreement for this invoice. Ask the appropriate business contact to clarify a contradiction instead of resolving it by guesswork.
Do not assume every real-world scenario can be represented by the current ordinary invoice form. A historic, correction or other specialised process can need different document structures and rules. The application is not an authority deciding whether the underlying arrangement is permissible.
If the correct facts genuinely fall outside the accepted model, preserve them and use suitable supporting software or advice. Moving the due date forward solely to bypass the error changes the record; it does not implement the missing workflow.
Preserve incomplete work while resolving the question
You can keep an editable draft while a date question remains unresolved. The current draft-download function preserves supported application data without requiring a passed final field check. Treat that file as working information, not as a validated invoice ready for the customer.
Record which date needs clarification and the source of the conflicting value. This lets another reviewer answer the real question without re-entering the whole invoice or assuming that the amount and parties are also unresolved. Keep private draft files appropriately protected.
The final JSON, CSV and print/export actions require the application’s checks to pass. Do not use a screenshot or renamed draft file to imply that an unsupported date relationship has been validated under a recognised standard.
Recheck the corrected document
After a confirmed correction, run the field checks again and read both dates in the preview. Review written payment terms, notes and the actual output for contradictory values. Earlier downloads do not change when the open draft changes.
Keep the clarification with the reviewed version where needed. A useful resolution establishes the correct facts and an appropriate tool for representing them. It does not treat a passed local date-order check as proof of legal validity, tax treatment or recipient acceptance.