When a customer supplies several references, label each by purpose before entering any of them. Identify the purchase order, internal buyer reference, project or contract code and any line-level reference the customer requires. Do not choose the longest number or combine every value into one string and assume the receiving system will work out the distinctions.
The buyer-information workflow treats references as separate business facts. A source document can contain several correct values that belong in different places. The practical task is to establish their roles and required representation, then recognise which parts the current editor can actually hold.
Create a reference inventory
For each value, record the customer’s label, exact text, source and intended use. A purchase order may identify the commercial order, while a department reference routes the invoice to an internal approver. A project code can describe the work without identifying either the order or the buyer entity.
Do not infer roles solely from appearance. A customer might use letters and numbers in every code, or an order reference might not begin with “PO”. Keep meaningful punctuation and leading zeros until the receiving instructions specify otherwise. An automatic spreadsheet conversion can change a reference that was intended to remain text.
For a fictional refurbishment invoice, the customer could provide order PO-813, project SITE-NORTH and department FACILITIES. The preparation sheet should preserve those three roles. A single notes paragraph containing all three may help a person read them without supplying the distinct fields required by a structured profile.
Ask where each reference belongs
Check the current invoicing instructions for document-level and line-level placement. If a requirement is unclear, ask the billing or procurement team which field it expects and whether the value applies to the whole invoice or only particular items. The customer should not have to infer the question from a screenshot of an unfamiliar editor.
The buyer-reference and purchase-order comparison explains one common distinction. Use that distinction to ask better questions, not to decide the role of an unexplained customer code without confirmation. Recipient terminology can be informal even when the target profile has precise field definitions.
If one invoice covers several orders or projects, ask whether the recipient accepts that grouping. The current preparation tool does not implement every multi-order structure. Do not create an unsupported representation merely because the totals can be added together.
Separate references from other identifiers
A customer tax identifier or business registration number is not a procurement reference. A payment reference is also different: it helps relate a later payment to the invoice rather than identifying the customer’s order or approver. Keep those roles separate even if a particular business reuses a value for more than one purpose.
Likewise, a network participant identifier or endpoint is not a buyer reference simply because it appears in supplier-onboarding instructions. It belongs to the delivery or structured-party requirements of the relevant workflow. Do not enter it in the general reference field unless the customer’s actual requirement establishes that role.
A label is therefore part of the preparation evidence. Keeping the value without its meaning can force the next person to repeat the customer inquiry or guess at the mapping.
Recognise the single-reference field limit
EInvoiceCreator currently holds one general buyer/purchase-order reference. It does not provide a complete set of typed order, project, contract and line references. A populated box can support a simple preparation record but cannot demonstrate that all recipient-specific fields have been mapped.
If the recipient needs several values in distinct fields, retain the labelled inventory and use supporting software for the final structure. Do not report that a note or combined string satisfies those fields. A human-readable explanation and a machine-readable mapping are different representations.
The application also does not check whether an order exists, belongs to the buyer or has enough remaining value for the charge. Those facts come from the agreement and customer records, not from the reference field accepting text.
Resolve conflicts and revisions
If the order supplies one value and a later message supplies another, ask whether the later value replaces the original or serves a different purpose. Two different codes may both be required rather than mutually exclusive. Record the clarification and affected invoice.
Do not silently update an already issued document or discard the old reference evidence. Follow the appropriate correction process where required. For a working draft, identify the reviewed version so an older download does not circulate with the superseded reference.
A common failure is correcting the visible reference while leaving the old value in a description or payment note. Read the final document for consistency, but do not automatically change every occurrence if the values have different confirmed roles.
Prepare a useful hand-off
Give the next operator the reference inventory, recipient instruction and any unresolved placement question. Include the intended format and version where confirmed. The current printable output and application JSON should be described according to their actual contents, not as a complete implementation of the recipient’s structured profile.
The inventory is successful when another person can identify what each value means and where it needs to go. That reduces avoidable ambiguity without pretending that a general reference box has become a procurement integration or an order-validation service.