Ask a customer for the accepted invoice format, the required profile and version, the billing entity, mandatory references and the delivery route. Request a written instruction or current onboarding document where one exists. “Send an e-invoice” is not enough information to choose an exporter, because it does not identify the data structure or how the recipient expects to receive it.

Start with the customer’s accounts-payable or procurement contact. A project manager may know that a purchase order is required without knowing the technical profile used by the receiving system. A concise question sent to the right team is usually more effective than preparing a polished file and asking why it was rejected afterwards.

Ask about the file first

Use a direct question: “Which invoice format and profile can your system accept for this transaction?” Let the recipient name the requirement. Avoid offering a PDF as the default if the customer has already asked for structured data. Also avoid assuming that an answer containing the word XML identifies a complete specification.

If the customer supplies a named format, ask which version applies and whether its system adds recipient-specific requirements. Record the title and date of the supplied specification. A sample can illustrate field placement, but a historic sample may use an old profile or contain data that should not be copied into a new document.

The European Commission distinguishes the semantic invoice model from the syntax carrying that information. In practical preparation, this means you should retain both the requested business meaning and the required file representation. You do not need to master the technical standard before asking the customer to identify it, but you do need an answer specific enough for your software provider to assess.

Separate delivery from document structure

Next ask: “Where and how should the invoice be delivered?” The answer might identify an email inbox, a procurement portal or a network-based route. Those instructions do not replace the format requirement. Uploading an ordinary PDF to a portal does not turn it into a structured invoice, and generating an XML file does not itself deliver it.

Where a network endpoint or participant identifier is required, ask for the complete value and its scheme. Do not substitute the billing email or company registration number without confirmation. Keep technical delivery instructions apart from contact information so a later operator does not mistake one for the other.

Also establish who handles delivery failures. Ask whether the system produces an upload acknowledgement, a document-validation report or a business rejection message, and which contact can interpret it. These responses describe different stages. A successful upload can coexist with a later rejection because an order reference or business value is incorrect.

Confirm the business fields

Ask for the exact buyer entity and address, the purchase order or buyer reference, and any required project, contract or department information. Explain that you want to place each reference in the correct field, rather than hiding everything in a notes paragraph. A system may be unable to match a reference that is visible to a person but absent from its expected structured location.

If several reference numbers appear in the onboarding pack, ask which one is the order number and which routes the invoice internally. Preserve the labels supplied by the customer. Do not collapse them into a single unexplained string because your first editor has only one reference box.

Check whether the invoice concerns a particular period, delivery or accepted milestone. This is a request for factual billing instructions, not permission to alter agreed prices or tax treatment. Those matters should be reconciled with the contract and appropriate advice separately.

Use a short, answerable request

For a fictional equipment buyer, a useful request could say: “We are preparing the invoice for order PO-482. Please confirm the billing entity, accepted invoice format and version, required buyer reference, and submission route. If there is a current supplier-invoicing instruction, please send the relevant document.” This gives the customer enough context to respond without requiring a long technical conversation.

When the response arrives, write a compact requirement record: requirement, source, date confirmed and unresolved question. If the format is clear but a delivery credential is missing, leave delivery unresolved. If the recipient changes its instructions, retain the new instruction and identify which invoice it affects.

The complete first-invoice preparation workflow can then use that record as its starting point. For the distinction between preparing information and checking a final file, see the separate creation, validation and delivery stages. This prevents a customer’s request from being interpreted as a capability your current tool already has.

Compare the answer with available output

EInvoiceCreator currently offers printable output, application JSON and line-items CSV. It does not generate recognised standards-based XML or route invoices through a network. If the customer requires those functions, use supporting software for the final standard-specific work rather than renaming one of the current downloads.

If the customer’s immediate need is a readable invoice or a reviewed source dataset, you can start the invoice preparation in the browser-based creator. Enter only confirmed instructions and review the preview. Keep the recipient’s requirement record with the working files, so the person responsible for the next stage can see exactly what remains to be generated, validated or delivered.