The seller VAT identifier belongs to the supplier’s tax identity for the relevant transaction. The buyer VAT identifier belongs to the customer where that role is required. They are separate facts: entering one does not fill the other role, and a shared company name or group relationship does not make the values interchangeable.
Use the tax preparation workflow to collect and confirm each value separately. The current creator stores seller and buyer tax-identifier text in its application model. It does not determine which identifier is legally required, verify registrations or map every identifier scheme into a formal invoice standard.
Identify the parties before collecting numbers
Confirm which legal or commercial party supplied the goods or services and which party is being invoiced. A contact person’s employer, a branch address and a group’s central purchasing team can create ambiguity. Resolve the transaction roles before assigning identifiers.
Do not select a value merely because it appears first on a company website. A business may display several registration or tax numbers with different purposes. Preserve the label and source so the reviewer can establish which value is relevant to the particular invoice.
The buyer’s purchase-order number is not its VAT identifier. A seller’s company registration number is not automatically its VAT identifier either. Keep each role distinct in the preparation record, even if the current editor has fewer typed fields than the final destination requires.
Confirm the seller value
Use the supplier’s authoritative business records and the responsible tax review to identify the appropriate seller value. Check the name and address associated with the record. Resolve conflicts instead of combining parts from different entities into one apparently complete block.
If the seller operates through several entities or registrations, establish the relevant transaction context before choosing. The creator does not infer the correct registration from the country selector, address or currency. A plausible prefix is not evidence of the right party or role.
Retain the exact identifier as text where required. Leading characters and formatting can be meaningful. Do not strip elements merely to make the value look uniform without checking the relevant representation rules.
Confirm the buyer value independently
Ask the customer for the relevant billing entity and identifier where needed. A purchasing contact’s email address does not establish which entity is the customer. Use the confirmed invoicing instructions and resolve differences with the responsible contact.
Do not copy the seller’s value into the buyer field to satisfy a perceived required-field rule. That would represent the supplier as the customer. If the buyer value is missing or uncertain, record the issue and determine the appropriate requirement rather than inventing data.
The European Commission’s invoicing overview distinguishes seller and customer information within its scoped VAT discussion. Whether a customer’s VAT identifier is required depends on the relevant circumstances. Do not turn that scoped guidance into an assumption that every invoice everywhere requires the same buyer value.
Understand the scope of a registry check
Where VIES is relevant, it retrieves information from national VAT databases for its stated cross-border checking purpose. An unsuccessful result can have more than one explanation, so follow the official guidance rather than immediately declaring the business invalid.
Keep the query result, date and identifiers checked with the preparation record. A lookup does not establish every company fact or decide the treatment of the supply. The current creator does not perform VIES checks or verify ownership of a number entered in its fields.
Likewise, a matching value in a previous invoice is not a current registry result. Treat source records, customer confirmations and official checks as different kinds of evidence with different scopes. Preserve those distinctions during the final review.
Review treatment separately from identity
Knowing both identifiers does not automatically determine the tax category or rate. The transaction still needs the appropriate determination. Do not conclude reverse charge or exemption solely because two values appear to have the expected prefixes.
The guide to preparing reverse-charge information explains the additional handoff questions without claiming that the creator supports that formal treatment. Use the identifier record as one input to the responsible review, not as a shortcut around it.
Before export, inspect both party blocks and any repeated identifier text in notes. A copied draft can retain another customer’s value even after the name is changed. Search and compare the exact strings against the confirmed records, then create a fresh output after corrections.
The current printable document, application JSON and line-item CSV do not establish formal identifier mapping, tax correctness or recipient acceptance. Retain the party-role evidence and complete any required verification, standards validation and delivery in a workflow that genuinely implements those capabilities.
A practical review check
Before copying a customer’s identifier, compare the full legal entity name with the confirmed buyer record. Similar names within a group can be easy to confuse. Keep any explanation of a branch or group relationship outside the numeric field so the final mapper receives the identifier value and its role separately, rather than an improvised combined string.