Avoid copying the wrong customer by confirming the buyer entity before entering or reusing any related details, then reviewing the complete buyer block and references before export. A familiar name or contact can hide a different group company, old billing address or previous customer’s identifier. A field checker can accept all of those values without knowing that they belong to the wrong transaction.
The buyer-information workflow establishes the customer record from confirmed sources. The additional control here is preventing carry-over when the preparer practises with an example, reuses a draft or copies data between working documents.
Start with the current transaction
Identify the accepted order or agreement and the actual entity to invoice. Use the current billing instruction rather than assuming that the last customer or last group company remains the right one. Keep the transaction reference visible in your preparation records while entering data.
For a fictional agency, two customers might both be called “Northfield” informally while their full entities and addresses differ. A name recognised from an email conversation is not enough to select the right record. Confirm the full buyer and its relationship to the approved work.
If the customer changes the billed entity, resolve that request separately. It can affect references, identifiers and other transaction questions. Do not use the change as a reason to copy another company’s complete block without checking whether those facts apply.
Choose blank or reuse deliberately
A blank start can reduce carry-over risk when every detail is different. A reused draft can save entry work only if you systematically review its retained values. Do not assume that a document has been reset because the main heading or invoice number changed.
The current creator saves one draft in the current browser profile when requested. It does not provide a verified multi-customer address book or account-based invoice history. Loading the saved draft can restore whichever customer was stored, not necessarily the customer you are now working on.
After loading or importing, read the buyer block before editing line items. An application-compatible JSON file can contain valid structure and outdated or unrelated customer data. The import process recalculates supported amounts but does not authenticate the buyer record.
Replace the complete buyer record
Check name, address, country, tax identifier and contact email together. A buyer name is often the most visible value, while an old email or identifier is less noticeable. Removing the old name alone does not remove the other customer’s information from the record.
Review the general buyer reference, payment reference, line descriptions and notes for customer-specific values. A previous order number or project name can remain outside the buyer block. Do not automatically overwrite all references with one new value, because their actual roles may differ.
The multiple-reference preparation guide explains why order, routing and project codes should stay labelled. Prevention means replacing the right facts with confirmed values, not simply finding and replacing a customer name across unrelated fields.
Compare with an independent source
Read the completed buyer block against the current order or confirmed billing instruction. Checking the form against another file copied from the same wrong draft may repeat the original error. Use the source that actually established the buyer for this transaction.
For a fictional training invoice, confirm that the legal buyer, service description and approved order belong together. A contact who attended the workshop may work for a different group entity from the one that purchased it. The identity check should resolve that relationship before the document is shared.
If another person reviews the invoice, give them the relevant source context and identify the buyer question explicitly. A general request to check the arithmetic can leave customer identity unreviewed even when several people looked at the document.
Check the actual file before sharing
The open browser draft and an earlier download can contain different customers. Editing the form does not rewrite a previously downloaded PDF, JSON or CSV. Confirm the file you select for attachment or hand-off, not merely the document currently visible on screen.
Inspect the available output according to its contents. Application JSON can contain full party details, while line-items CSV is narrower and can still carry invoice references and item descriptions. Both can disclose private business information if sent to the wrong person.
The current creator does not email or transmit invoices. Any sharing happens through an external process, which needs its own destination check. A successful local export is not evidence that the intended customer received the right file.
Respond appropriately if an error is discovered
Stop using the incorrect working copy and establish which files or records contain the wrong information. Correct the preparation record from confirmed sources. If a document was already issued or shared, follow the appropriate correction and information-handling process rather than silently editing a local draft and assuming the issue is resolved.
You can prepare and review the confirmed buyer details in the creator once the identity is clear. Run application field checks, then repeat the source comparison and output-selection check. The software can help structure and display the data, but the business remains responsible for choosing the right customer’s facts.
A consistent identity check is valuable precisely because many wrong-customer values look perfectly valid in isolation. The aim is to confirm that the buyer, supply, references and chosen file all belong to the same intended transaction.