If a required customer reference cannot be represented by the current creator, preserve the exact value, its meaning and the recipient’s placement requirement, then use suitable supporting software or obtain an appropriate clarification. Do not invent a field mapping or report that free-text visibility fulfils a structured requirement.
The buyer-information preparation guide identifies the references before final output. A gap discovered at that stage is useful information. It tells you which part of the workflow needs a different implementation rather than forcing the transaction into an application model that cannot express it accurately.
Describe the missing representation precisely
Identify whether the problem is a missing field, missing identifier scheme, unsupported number of references or missing relationship between a reference and a line. These are different limitations. Saying that “the reference does not fit” may hide the actual question a software provider needs to answer.
For a fictional procurement invoice, a customer might require one order reference plus an order-line reference for every item. The current editor’s single general buyer reference does not establish those line relationships. Adding all the values to one paragraph preserves some human context but does not create a typed order-line mapping.
Keep the relevant instruction and specification version with the value. A sample from another customer is not sufficient evidence that a workaround is valid for this recipient. The final representation must be assessed against the actual requirements.
Distinguish an unknown value from an unsupported field
If the value is missing, ask the customer for it. If the value is known but the editor cannot represent its role, repeating the customer question may not solve the software gap. Record which situation applies so that the right person can act.
The missing-information request helps when the business fact is unresolved. A confirmed reference should not be changed or shortened merely because a different value would pass a form check. The application does not determine whether the customer’s order exists or whether another code is an acceptable substitute.
If a requirement genuinely does not apply, obtain the appropriate confirmation or consult the actual specification. Do not convert “we cannot enter this” into “the customer does not need it”. Technical inconvenience is not evidence of optionality.
Keep available fields honest
Use the general buyer reference for the role it can accurately describe in the preparation record. Do not put a tax identifier, endpoint or unrelated contract reference into that field simply to avoid leaving something unrepresented. Mislabelled data can create more confusion for the next mapper than a clear gap list.
A readable note may be appropriate to explain context to a human, but label the remaining structured requirement separately. A person seeing the value in the preview does not prove that the final recipient can process it automatically in the required field.
EInvoiceCreator’s application JSON preserves its own limited invoice model. It is not a universal container that automatically conforms to every standard because the values appear somewhere in the file. Its CSV is narrower still and does not contain the complete buyer record.
Ask about supported alternatives without assuming permission
The recipient may have an accepted alternative process or a simpler requirement for a particular situation. Ask the authorised team whether such an option applies, and keep its response with the preparation record. Do not assume that an informal contact can waive a legal or mandatory profile requirement.
For example, a customer might clarify that a project code is useful context rather than a required structured field. That is different from a requirement for a purchase order line in a specified XML element. The clarification should establish the actual role, not merely reassure the preparer that the document looks readable.
Where the requirement remains, choose software that implements it. Assess the format, profile, version, mapping and validation needed. A claim that a tool “exports XML” is not enough to establish that it can represent the missing reference correctly.
Preserve data for the next operator
Provide the confirmed buyer entity, relevant reference values, line relationships, requirement source and unresolved questions. Include the original order or other evidence through an appropriate channel when needed. Avoid sending unrelated personal or financial data merely to explain one missing field.
Keep the current draft distinguishable from the final output produced elsewhere. If supporting software adds the missing structure, review the resulting file and its relevant validation evidence. Do not assume the external mapping also corrected every commercial fact in the source data.
The current creator has no network submission or government-delivery integration. Even after a suitable final document is generated, delivery and recipient acceptance remain separate stages with their own requirements.
Record the limitation and outcome clearly
A useful record says what the current tool prepared, what it could not represent and how that requirement was completed or remains unresolved. Do not mark an invoice “fully validated” because the application accepted the fields it happened to contain.
Handling a model gap well protects the integrity of the data. It keeps facts and roles intact, avoids misleading shortcuts and gives the next stage a concrete requirement to implement. That is a better preparation outcome than a full-looking form whose required reference has lost its meaning.