When a customer changes billing details, establish what changed, who confirmed it and which transactions it affects before editing the invoice. A new email, address correction, department code and replacement buyer entity are different changes. Updating one field without reviewing the related information can leave the draft internally inconsistent.
The buyer-information workflow establishes the original confirmed record. This article concerns changes to that record and the evidence needed to make them safely. The current creator stores editable preparation data; it does not decide contractual identity, authenticate a customer instruction or maintain issued-invoice correction status.
Identify the type of change
Ask the customer to state the changed value and its role. A new correspondence email may not change the billing entity or delivery endpoint. A new office address may not replace the address relevant to an earlier transaction. A different company name can represent more than a display correction.
Write down whether the instruction applies to future invoices, an open draft or a document already issued. Do not interpret an email announcing a general update as automatic permission to rewrite all historic invoices. Where a correction process is needed, use the appropriate procedure and supporting software.
For a fictional supplier, a customer’s new accounts-payable inbox might be straightforward to record as a contact update. A request to charge another group company needs separate clarification of the buyer relationship, references and affected supply. The same edit screen can accept both changes while knowing nothing about their different consequences.
Confirm the source and authority
Use the customer’s established billing or procurement channel to confirm a material change. An unexpected message from a new address should not become its own proof that the destination is legitimate. The application cannot assess whether a sender is authorised to redirect private invoice data.
Ask for an updated instruction or other suitable confirmation, especially where the change conflicts with the order. Retain the source and date with the preparation records. A later reviewer should be able to see why the value changed without reconstructing a scattered conversation.
If the response is partial, keep the unresolved facts separate. Confirming an address does not confirm a new tax identifier or network endpoint. Do not mark the entire buyer record “checked” when only one component was addressed.
Review dependent values
After an entity or address change, review buyer identifiers, country, order and routing references, contact information and output instructions. Some may remain correct, but that should be established rather than assumed. A related company’s identifier should not stay beneath a different buyer name because it was already in the draft.
A change to the customer identity may also require review of the transaction’s tax treatment through appropriate advice. The current creator cannot determine that treatment from the new name, country or identifier. Do not use a successful field check as evidence that the wider consequences were assessed.
The tax-identifier and electronic-address distinction helps keep those dependent fields separate. Updating one does not automatically update or verify the other.
Update one controlled draft
Identify the working version to change and compare the current entries with the confirming instruction. Replace the affected values deliberately, then read the complete buyer block and reference fields. Look for old values left in notes or line descriptions where they might now contradict the revised record.
EInvoiceCreator explicitly saves one draft in the current browser profile when requested. There is no autosave or historical customer master record. Loading an older saved draft can restore previous buyer details, so repeat the relevant review after loading or importing a file.
An editable JSON import accepts the application’s supported structure, not proof that the customer information is current. The application recalculates supported amounts but does not compare the buyer record against a verified address book.
Inspect the actual export and delivery instruction
An existing download does not change when the open draft changes. If you edit the buyer address after producing a PDF, inspect and produce the appropriate reviewed output rather than attaching the earlier file by accident. Keep draft and reviewed filenames distinguishable.
Confirm whether the delivery instruction also changed. A communication email, portal route and network endpoint can have different update processes. The current product has no transmission integration, so any actual sending or platform submission remains part of an external workflow.
If the recipient now requires a format the application cannot generate, retain the prepared data and arrange appropriate supporting mapping and validation. Printable output, application JSON and line-items CSV do not become a new standard because the buyer changed its instructions.
Preserve a useful change record
Record the confirmed change, source, affected document or period and remaining action. Keep any issued-document correction evidence separate from an editable preparation file. The creator should not be represented as a full accounting history or an authority deciding whether a past invoice can be replaced.
A good change review prevents both stale data and unjustified rewriting. It establishes which buyer facts are confirmed now, what they mean for this transaction and which downstream steps still need completion. That is a more reliable result than treating the newest message as a universal replacement for every previous record.