What to Ask When a Customer Requests an XML Invoice

When a customer asks for an XML invoice, ask which invoice specification, syntax, profile and version its system accepts. XML is a message technology, not a complete invoice requirement. Sending an arbitrary file with an xml extension can leave the customer unable to process it.

Use the format-selection workflow to record the answer before final preparation. The current creator does not export standards XML. Its application JSON and printable output cannot be relabelled as the requested format without a genuine mapping implementation.

Identify the receiving system

Ask which team or platform will process the document. A purchasing contact may request XML without knowing the technical details, so obtain the instruction from the responsible receiving team or its published specification. Keep that source identifiable.

Confirm the actual billing entity and destination. A customer group may operate several systems or legal entities. A format accepted by one location is not automatically the correct instruction for another, even when the companies share a brand.

Do not use an unrelated sample as the requirement. A sample can illustrate one successful case but may omit conditional data needed for your transaction. Ask for the accompanying specification and any receiver-specific instructions rather than reverse-engineering policy from one file.

Ask for the named document combination

Record the syntax family and required version, together with the profile or national specification. UBL and CII have different structures. A profile can constrain fields, codes and calculations within the broader syntax.

Ask whether the receiver expects an invoice, credit note or another supported document type. Changing a heading does not create a different formal message. The current app supports ordinary positive invoice preparation and does not implement credit-note mapping.

The Commission’s syntax guidance explains that bindings target specific syntax versions. Do not assume the newest general release is the accepted combination. Record exact names and versions instead of “XML latest”, which cannot identify the tested requirement later.

Collect mandatory and conditional facts

Ask for required identifiers, references, addresses, tax information and payment data. Identify which requirements depend on the transaction. A simple sample may not include exemption explanations, special references or other conditional fields.

Compare the requirements with the source model before entering a long invoice. The creator lacks some typed fields a formal profile may need. Preserve those facts separately so a final mapper receives confirmed values rather than guesses extracted from notes.

Do not invent values to satisfy a mandatory field. If an endpoint or buyer reference is missing, obtain it from the appropriate source. A plausible-looking placeholder can pass a shape check while routing or identifying the document incorrectly.

Confirm validation expectations

Ask which specification and validator configuration the receiver uses or recommends. Distinguish XML well-formedness, schema validation and business-rule checks. A file opening successfully in a browser does not establish the complete required validation.

Record what evidence the final provider will return and which file version it covers. A report for an earlier revision cannot be assumed to cover later changes. Include receiver-specific checks where required, without treating every local rule as universal.

Use the profile-requirement review when the instruction names a broad format but leaves the actual restrictions unclear. Resolve that ambiguity before choosing software or promising the customer a supported output.

Confirm the delivery route

Ask whether the customer expects portal upload, an agreed transfer method or an implemented network service. Record recipient identifiers and any authorisation or access process separately from the document fields. A billing email and a technical endpoint are different roles.

Identify who submits the final file and who monitors the result. The current creator has no government or Peppol submission integration. A local download is an export event, not a submission receipt or customer acceptance.

If a readable copy is also requested, ask how it should relate to the processing document. Avoid delivering conflicting representations. A PDF for human review should not silently disagree with the structured values sent to the platform.

Test before relying on the workflow

Use fictional data containing the actual kinds of lines, references and tax situations the invoice needs. Inspect the output and validation evidence from software that genuinely implements the specified combination. A one-line demonstration is not proof of every conditional scenario.

You can prepare supported source details locally, then retain any model gaps for the final software provider. The creator’s role remains preparation, field checking and current application exports. Do not describe that draft as a completed XML invoice.

Keep the confirmed instruction, tested combination and assigned delivery responsibility with the final record. The useful result of asking these questions is a concrete requirement that can be implemented and checked, rather than a vague request that encourages unsupported claims about any file containing angle brackets.

For a concise customer enquiry, list the proposed syntax/profile combination and ask the receiving team to correct or confirm it. Include separate questions for required buyer identifiers and submission route. A written answer is easier to review than an assumption reconstructed later from a general request for XML.