Keep seller details consistent by treating the name, address, country, identifiers and contact information as one related record. When one value changes, review the others against the source that authorised the change. A draft can contain individually plausible fields that describe different businesses or different versions of the same business record.
The seller-information workflow establishes the original coherent record. Revision control preserves that coherence as new facts arrive. The current creator stores editable working data; it does not maintain a legal entity history or determine which changes can be made to an already issued invoice.
Distinguish the type of change
A corrected spelling, new correspondence address, formal name change and replacement supplier entity are not the same event. Identify what actually happened before changing fields. An instruction to “update the seller” is too vague if nobody has established whether the identifier should remain the same.
Ask for the confirming source, effective context and affected transactions. A new address may apply to future correspondence without rewriting an earlier supply’s source records. A change of supplier entity can raise wider contractual and tax questions that the editor cannot resolve.
For a fictional studio, replacing a short trading label with a confirmed formal name may clarify the existing supplier. Replacing that name with a related company’s name is a different change. Do not rely on the similarity of the two labels to decide whether the same identifiers remain appropriate.
Review dependencies instead of isolated fields
After a name change, compare the tax identifier, address and contact information. After an address change, compare country and any related business record. After a contact change, ensure the new email belongs to the intended supplier role rather than another entity using the same domain.
Payment instructions deserve their own trusted confirmation. A changed supplier block does not authenticate a new bank account, and a bank-change message does not establish a new legal seller. Keep the sources and approval responsibilities for those changes separate.
The conflicting seller-record workflow can help when two sources disagree. A revision should resolve the conflict through evidence rather than make the form look internally tidy while the underlying uncertainty remains.
Identify the working version
Give the preparation record a clear revision identifier or other method appropriate to your business. Record what changed, why and which invoice draft is affected. Do not rely only on the browser tab’s current appearance; a downloaded file or locally saved draft may contain an earlier version.
EInvoiceCreator’s Save on this device stores one draft when requested. It does not automatically save later edits or maintain a timeline of seller records. Loading a saved draft can therefore restore an old address or contact value that you had already corrected in the open document.
After loading or importing a draft, review the seller block again. An imported file can be structurally acceptable while containing outdated information. The application recalculates supported totals, but it does not check whether the business details remain current.
Keep reviewed exports distinguishable
A reviewed export should be identifiable separately from a working draft. If a seller value changes after review, inspect the affected document and produce the appropriate new version rather than assuming an earlier downloaded file has also changed. Browser downloads are independent files, not live views of the current form.
For a fictional invoice, an address corrected in the editor at noon will not update a PDF downloaded at eleven. Selecting the older PDF for an email can undo the benefit of the correction. Confirm the actual file attached or handed to the next operator.
Do not present an edited version as an unchanged issued original. Where correction rules apply, follow the appropriate process using supporting software. The current creator does not implement a full issued-invoice lifecycle, correction ledger or credit-note workflow.
Recheck representations and mappings
A readable seller block and an external structured representation must reflect the intended record. If a downstream mapper stores seller fields separately, changing the local draft does not necessarily update that external dataset. Include the revised information and its scope in the hand-off.
The current application JSON uses its own schema and does not establish standard-specific identifier or address mappings. A name change that fits the application field can still require review in the recipient profile. Keep additional registration, scheme and address-role information available where the final format needs it.
Do not assume that passing local field checks means all dependencies have been verified. Those checks can detect a missing name or invalid email shape, but cannot authenticate the change source or confirm that the identifier belongs to the revised seller.
Use a focused final consistency review
Read the seller name, address, country, tax identifier, email and payment instructions together. Compare them with the confirming records and any customer instructions. Look for a sample detail or old reference left behind after the main change.
A useful revision note identifies the specific facts confirmed and any remaining external task. It should not imply a professional certification or formal validation that did not occur. Consistency is maintained when the data, source and selected output all describe the intended supplier version, not merely when the form contains no empty required boxes.