Resending an invoice changed the displayed due date

Preserve the original and the resend as separate events

Before anyone edits anything, capture the invoice as the buyer first received it and the copy the resend produced: issue date, displayed due date, amounts and the time of each send. Once a record is overwritten, the comparison that settles this question becomes impossible, and the argument about which date was real has no evidence left.

Keep the two sends as distinct events with distinct references rather than treating the resend as a refresh of the same object. The original send is the record of what terms entered the commercial relationship. The resend is a record of what the system generated later. Whether the second should override the first is the decision; it cannot be presumed by the act of resending.

Name the term basis before blaming the resend

A displayed due date is computed from a term basis, and the basis is where the investigation starts. On Shopify B2B, payment terms can be assigned to company locations and to draft orders, and the documented options include net periods, due on fulfillment, and fixed dates on drafts. Those options are platform-specific, but the structure is general: the date on the invoice is an output, and the configured term is the input.

One hypothesis to test is that the installed invoicing tool regenerated the copy from current configuration or state rather than from the original issue state; for example, if that tool counts a net period from send time or reacts to a fulfillment trigger, the displayed date could move. The cited Shopify pages do not document that a resend recomputes a due date, and resending does not always reset anything. Keep other causes open — a manual edit, an integration, or a configuration change — and let the comparison of the two snapshots against the configured basis in your own system identify which case you have.

Work out which record changed and which did not

Separate the stored terms from the displayed document. If the stored term record still matches the original agreement and only the rendered copy drifted, the correction is to the document and to any status that read from it. If the stored record itself changed, find out what changed it — an edit, a regeneration, an integration — and when. Shopify's draft-invoice documentation notes that drafts can be reviewed before sending; a resent copy deserves the same review before it reaches the buyer.

The same documentation observes that adding an item after invoice creation does not automatically recalculate shipping rates, which is a useful caution about regeneration generally: what a system rebuilds is not necessarily complete or consistent with the earlier version. And its warning against marking an order paid before payment is received applies here too — a tidy-looking resent invoice is not evidence about what was paid or what was agreed.

Correct the customer-facing record and the overdue status together

Once the right date is established, correct both places the wrong one may have traveled: the document the buyer sees and any internal status that consumed the displayed date. An automated overdue flag or reminder sequence that fired off the wrong date needs to be paused and corrected, not left running while the invoice itself is fixed. One wrong date, two consequences, both owned.

Send the buyer a single clear message naming the date they should use and, where helpful, acknowledging the earlier discrepancy. If the original terms genuinely govern, say so. If the terms were legitimately re-agreed at some point, record that re-agreement as its own event with its own authorization rather than letting a resend imply it. Do not backdate a corrected invoice to make the history look consistent.

Conflicting records go to a named owner

When the two snapshots and the stored record cannot be reconciled — the original terms are missing, the resend history is unclear, or the buyer disputes which date they accepted — name the decision owner who resolves the operational record and document what they decided and why. A dispute about what is legally owed, about late fees or about collection is not settled by this worksheet; route it to qualified review with both snapshots preserved.

If the underlying problem is that your invoicing flow regenerates terms unpredictably, a Prism consultation can review that storefront question; describe the website, the research-only products and the non-sensitive sequence of sends, and confirm scope, responsibilities, fees and terms before work begins. Keep customer payment details and identity documents out of the worksheet and the inquiry.

Invoice resend comparison sheet

Use one sheet per affected invoice. Capture both versions before any edit, decide from the configured term basis, and correct the display and the status together. Leave findings blank where a record no longer exists, and keep customer payment details out of the sheet.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.