When a Seller Identifier Needs an Identifier Scheme

A seller identifier needs an identifier scheme when the target specification requires context describing how that value is issued or interpreted. The value identifies something within a system; the scheme identifies the relevant identification system. Copying the value alone can lose information a receiving application needs to understand it correctly.

Ask for the complete identifier instruction, including its role and any required scheme. The seller-information preparation workflow keeps tax, registration and delivery information separate. A scheme is not an optional label to guess from a number’s appearance, and one scheme does not automatically apply to every identifier belonging to the same business.

Distinguish the identifier’s role

A supplier can have a tax identifier, legal-registration identifier, customer-assigned supplier reference and electronic address. These roles can require different representations. The same-looking string in two places does not establish that it has the same meaning in both.

Before asking about a scheme, identify the field the recipient or target profile requires. A registration identifier answers a different question from an address used in electronic delivery. Do not assign a scheme associated with one role to a different field simply because the syntax accepts a text value.

For a fictional supplier, an onboarding document might provide a participant identifier and a separate supplier account code. Keep both labelled. The account code used by one customer’s procurement system should not automatically become a national business identifier or network endpoint.

Read the complete target instruction

Check the relevant specification and version for the specific field. Determine whether a scheme is required, what allowed values or code list applies and how the identifier itself should be represented. A profile can constrain a broader format, so a generic example may not answer the recipient-specific question.

OpenPeppol’s published seller electronic-address element, for example, documents both the address value and scheme information for that field. It illustrates why a complete endpoint record involves more than copying an email-like string. That does not make the current creator a Peppol implementation or establish a universal rule for every other identifier field.

Retain the source of the instruction and the version it refers to. If a customer supplies an old example or an unexplained code, seek clarification rather than substituting a value from a different profile. The final mapper should not have to infer which identification system you intended.

Preserve the value and scheme separately

In your preparation sheet, use distinct labels for identifier role, value, scheme and confirming source. Preserve meaningful prefixes and leading zeros unless the actual instruction specifies another representation. Spreadsheet formatting can alter a numeric-looking string, so compare the retained value with the source after copying.

Do not paste the scheme into the identifier value unless the target representation explicitly calls for that combined form. Equally, do not remove a required scheme prefix from an onboarding instruction without understanding how the destination expects it. Interpretation belongs to the specification, not to a preference for shorter text.

The tax-ID and registration-number comparison helps keep these records distinct. Knowing that a value belongs to the seller does not establish that it belongs in every seller-identifier field.

Recognise the current model’s limit

EInvoiceCreator has a general seller tax-ID field, with no separate complete scheme metadata or standard-specific endpoint structure. It records the supplied application text but does not implement the target profile’s identifier mapping. A screenshot of the number in the seller block is not evidence that a typed structured identifier has been produced.

Do not work around that limit by placing an endpoint in the email field or appending several scheme/value pairs to the business name. Such entries can make the data harder to interpret and may create a misleading readable document. Keep the additional information for software that supports the final structure.

The application’s field checks also do not verify the identifier against a registry or network. A non-empty or well-formed value can still be unregistered, associated with another entity or unsuitable for the target role.

Review a downstream mapping hand-off

Suppose a fictional customer requests a structured supplier identifier under a named scheme. The preparer should supply the confirmed supplier identity, the identifier’s exact value, the scheme, the field’s intended role and the recipient’s instruction. If any component is missing, mark that question for resolution rather than inventing a plausible code.

The mapper then needs to place the information in the correct structure and run the relevant checks. Passing one code-list check would not by itself verify that the value belongs to the intended seller. Keep syntax, registration and business-identity questions distinguishable.

Keep the preparation evidence usable

Record which values have been confirmed and what an external check actually established. If the recipient changes its profile or onboarding instruction, recheck the scheme requirements rather than blindly reusing an older identifier record.

Identifier schemes matter because they preserve meaning across systems. The practical objective is not to collect more codes, but to give the final receiving process enough unambiguous information to interpret the seller identifier in the role it was intended to serve.