Leitweg-ID vs Purchase Order Number: Keep the Roles Separate

A Leitweg-ID and purchase-order number serve different purposes. In the relevant public-sector workflow, the Leitweg-ID supports identifying and routing an invoice to the intended receiving context. An order number identifies procurement. Do not substitute one for the other because both appear in customer instructions.

The XRechnung preparation workflow collects each value with its role. The current creator has limited reference fields and no formal XRechnung mapping or transmission. A string placed in a general reference box does not implement every required relationship.

Confirm the recipient context

Ask whether the instruction comes from the actual public recipient or another receiving organisation. Follow its confirmed billing and technical requirements. Do not reuse an identifier from a sample or another authority simply because its format looks plausible.

KoSIT’s guidance distinguishes Leitweg-ID use in public-sector contexts from private-business buyer-reference choices. Do not demand a Leitweg-ID from every German customer merely because an XRechnung is requested.

Keep legal applicability separate from data preparation. The exact transaction and receiving workflow control which requirements apply. This comparison explains roles; it does not determine every supplier obligation across German public and private invoicing.

Preserve the routing value accurately

Obtain the identifier from the responsible source and retain exact characters. Do not construct it from an address or department name. A value passing a structural check would not establish that it belongs to the intended recipient.

Record the source, confirmation date and intended use. If more than one office or system is involved, clarify which instruction applies to this invoice. Shared branding is not enough to establish a common routing destination.

The related routing-detail collection process explains how to keep those facts in a handoff record. The final provider needs confirmed roles rather than an unexplained identifier copied into several fields.

Preserve the order reference independently

Use the purchase-order number provided for the actual supply where relevant. It may support matching the invoice to approved procurement, but that does not make it a substitute for a routing identifier.

Keep order-line references separate too if required. A document-level order number and a line relationship have different scopes. The current app does not implement every typed order-reference structure a formal target may need.

If no order exists or the value is unknown, resolve the requirement with the customer. Do not invent a plausible number or copy the routing value to make an order field appear complete. A technical placeholder can conceal a factual gap.

Check the target mapping

Ask the final software provider where each confirmed value is represented under the accepted specification and syntax. Do not infer the answer solely from a source field called reference. Similar labels can have different meanings.

A technical electronic endpoint is another role. In a particular arrangement, related identifiers may share characters, but that relationship must be confirmed. Putting the buyer reference into an email field does not create a network destination or route.

The creator’s application JSON preserves its own supported reference model. It is not a verified XRechnung binding. Preserve extra facts separately for suitable final software rather than hiding them in a description and assuming a parser will infer the roles.

Test with distinguishable values

Use a fictional routing value and a clearly different order reference in a controlled test. Trace each into the actual target role and inspect the required validation result. A test using the same sample string everywhere can hide an exchange.

Change the order reference in a second test and confirm the routing instruction remains unchanged. This checks independence of the mappings. Keep the input, output and configuration so the behaviour can be reproduced.

Do not send deliberately altered routing data to a live receiver as an experiment. Use fictional generation tests and an authorised test route where operational testing is required. Production destination facts need actual confirmation.

Review before delivery

Compare the final file with the customer’s confirmed instruction and source order. Check notes for stale values copied from earlier drafts. A corrected primary field does not rewrite every repeated reference.

After edits, generate and validate a fresh final version. Keep earlier downloads distinguishable. A report tied to an old file cannot establish the status of a later reference change.

The useful result is a clear record of routing, procurement and delivery roles with no invented substitutions. The current creator does not verify identifiers, submit XRechnung or guarantee recipient acceptance. Complete those requirements through an implemented final workflow and retain evidence for the checks and operational events actually performed.

A useful fictional mapping test assigns visibly different demonstration values to routing and order roles. Confirm both target locations, then update only the order reference and regenerate. Routing should remain tied to its original confirmed role. If both values change together, investigate whether the mapper populated several fields from one source box. Keep the test record and expected relationships separate from any real authority identifier. This checks semantic independence without risking live misrouting or inventing production values.

Retain both controlled test outputs.