Review customer invoicing instructions by separating what must appear in the invoice from how the document must be generated, checked and delivered. Identify the applicable version, transaction scope and contact for unresolved questions. A long onboarding pack can contain useful information without every paragraph applying to the invoice you are preparing.
The buyer-information workflow uses those instructions alongside the agreement and order. The goal is a clear requirement record that another operator can act on, not an indiscriminate copy of every code and paragraph into the invoice notes.
Confirm that the instruction applies
Check the customer entity, document date, business unit and type of supply covered by the instruction. A guide for another group company or a historic portal process may not apply to this transaction. If the customer sends a revised guide, identify which open invoices and future supplies it affects.
Distinguish final requirements from sample illustrations. An example supplier name, order number or endpoint is not a value to copy into your own invoice. A screenshot can show where a field appears without establishing the actual data required for your customer.
If the guide conflicts with the purchase order, ask the authorised billing or procurement team to resolve the difference. Do not simply choose the instruction that is easier to satisfy with your current editor. Retain the clarification with the affected transaction.
Extract the business-data requirements
Identify the confirmed buyer name and billing address, any required identifiers, the purchase order and routing references, and relevant supply or service-period information. Keep each value labelled by purpose. A department code should not replace the buyer entity or become an unexplained addition to the tax-ID field.
Note whether a requirement applies to the whole invoice or particular lines. Order-line references, delivery references and project codes can have different scopes. If the guide asks for several typed fields, a single general reference box does not automatically represent them all.
For a fictional customer, the guide might require the legal buyer, order PO-448, department routing value R-TEAM and a service period for consulting work. The preparation record should retain all four roles rather than merging them into the first available description field.
Extract format and validation requirements
Record the named format, relevant profile and accepted version. A requirement for “electronic” or “XML” output may need clarification if it does not identify the actual specification. A PDF attachment and a recognised structured invoice are not interchangeable merely because both can be downloaded.
Ask what validation the final file requires and how reports are handled. Application field checks, schema validation and profile-specific business rules address different layers. A guide referring to one does not necessarily establish that another has been completed.
EInvoiceCreator currently provides printable output, application JSON and line-items CSV. It does not generate or formally validate recognised e-invoice formats. If the guide requests one, mark final generation and validation as external tasks rather than describing the current download as the requested standard.
Extract delivery instructions separately
Identify the route, destination details, required access and person responsible for submission. An email address may handle queries while a portal or network receives the invoice. A participant identifier can need scheme information rather than being interchangeable with the customer’s tax number.
Check what an acknowledgement means in that process. A received upload, technical acceptance and business approval may be separate events. Do not promise the customer that exporting a local file completes a submission step the product does not implement.
If credentials or a platform account are needed, use the appropriate secure process. Do not place passwords, access tokens or private login information in the invoice notes or preparation article examples. Those are access-management details, not invoice content.
Build a short gap list
Compare the extracted requirements with the current model and available software. Mark each as represented, requires clarification or requires supporting software. A clear gap list prevents a preparer from improvising misleading workarounds late in the process.
The unsupported-reference workflow explains how to handle requirements that cannot be represented by the current editor. The right response may be to preserve the data and use another generator, not to invent a value or concatenate several fields until the document looks complete.
Keep legal or tax questions separate from format questions. A recipient guide can specify a useful field arrangement without determining the correct treatment of every transaction. Confirm applicable tax decisions through appropriate sources or advice where needed.
Review the final hand-off against the guide
Before sharing, compare the completed draft or external output with the requirement record. Check entity, addresses, reference roles, relevant periods, format and delivery tasks. Inspect the actual file selected rather than assuming that the last download contains the reviewed version.
Retain the source guide and any clarifications with the preparation evidence. If a rejection arrives, this record helps identify whether the problem concerns entered data, mapping, validation, delivery or a business disagreement.
The review is successful when the instructions have become concrete, assigned tasks with unresolved issues visible. It does not certify the creator or guarantee acceptance. It gives the next person enough information to complete the applicable workflow without guessing what the customer meant.