Create an XRechnung: from a confirmed order to a checked invoice

An XRechnung should shorten the journey to an invoice your customer can process. If the office has to retype order details, search emails for references and handle rejections without linking them to the original transaction, that benefit is lost. Useful invoicing software connects existing business information, checking and the actual handover to the recipient.

For your company, the important question extends beyond whether a file can be generated. Can a real order become an accurate invoice, addressed correctly and prepared for a traceable submission with manageable effort? For public and commercial customers, a sound process helps avoid unnecessary queries that occupy your office again and delay further handling.

webRichtung Core connects quotations, orders and invoices and generates XRechnung and Factur-X with built-in validators. The capabilities are described on the Core module page. Assess them with a real invoicing case from your business: which information already exists, what needs adding and how does the team respond to a validation message?

Begin with the confirmed order

Choose an ordinary order whose services and billing your team understands. An exceptional case containing several unresolved changes is a poor first example. It would mix data problems, business decisions and software operation at the same time. Once the normal case works, add the variants that actually matter to your company.

First check the relationship between the customer, the order and the invoice recipient. The person commissioning the work is not necessarily the destination for the invoice. Your office should recognise that distinction from the transaction. An email address used in the latest personal conversation is not automatically a confirmed invoicing channel.

The service scope, quantity actually delivered and agreed prices form the basis. If anything changed after the quotation, resolve that change before preparing the invoice. A technically correct dataset does not automatically make an unapproved line billable. The practical benefit comes from reusing confirmed information, rather than reproducing unresolved assumptions more quickly.

Identify who can supply missing details. Sales may know the purchase order, the delivery team may know what was completed, and the office may hold the billing address. A short question to the right colleague costs less than an incorrect submission followed by a search. The order should therefore also make the route to clarification understandable.

Explore Core and assess the journey from an order to XRechnung

Establish recipient details before generating the file

Obtain the required buyer reference and submission route from the order documents or the responsible invoicing contact. For public-sector recipients in Germany, the Leitweg-ID often has an important routing role. Use the recipient’s actual instruction instead of copying a reference from an earlier invoice without checking that it applies.

The importance of order-specific information is illustrated by the Bundesnetzagentur’s invoicing guidance. It directs suppliers to the order or responsible department for the Leitweg-ID and explains the significance of a supplied purchase order reference. This is an example of a recipient’s requirements, rather than a universal field guide for all your customers.

For commercial customers, establish the reference they need for internal allocation as well. Do not automatically apply the public-authority procedure to every company. A useful invoicing process preserves differences between recipients. Your team should distinguish a customer-level detail from information supplied specifically for this purchase order.

Copy references accurately. A populated reference can still be wrong, which is easy to miss because a completed field looks finished. Compare it with the confirmed source. The task is correct allocation, rather than simply placing some value in every box. A brief comparison can prevent a later conversation about an invoice the customer cannot assign.

Understand what validation actually does

XRechnung defines structured invoice information in an XML dataset. The official XStandards Einkauf explanation also distinguishes machine-checkable conformity from the appropriate business use of information. A readable view supports review, while the structured invoice consists of the underlying data. Understanding that distinction helps the office look beyond an attractive document preview.

This creates a useful division of work. Software validation should expose technical and rule-related problems. Your team checks the customer, the service and the confirmed amounts. A successful validation result matters, but it does not establish that the invoiced work was actually ordered and delivered in the way described.

Treat an error message as a pointer to a concrete correction. Which information is affected, where does it originate and who can confirm it reliably? Where possible, correct the underlying invoice or order record. Changing an extra copy alone can leave the original source unchanged, so that the next export recreates the same problem.

Validate again after a relevant change. An earlier report belongs to the file as it existed then. If you subsequently change quantity or recipient reference, examine the new version. This keeps the relationship between the invoice and the result understandable. You need a clear connection between version and check, rather than a complicated documentation system of your own.

Example: two confirmed lines become a draft invoice

Our entirely hypothetical case involves a service business with two agreed services. The first line contains four units at €200 each, and the second contains two units at €100. These are fictional calculation amounts, not webRichtung prices. For this example, the responsible person confirms that those quantities were delivered and can be invoiced.

The first line is four times €200, giving €800. The second is two times €100, giving €200. Together they make €1,000 before the tax amount supplied for this example. We assume that the appropriate person has already determined a tax amount of €190 for this invoice. The resulting total is €1,190. This does not determine the tax treatment of your own services.

Before generation, the office checks the customer, invoice recipient, service descriptions and confirmed references. The test case initially lacks the purchase order reference requested by the recipient. Comparing the draft with the order reveals the gap. The office asks the responsible person and adds the confirmed reference rather than inventing a value simply to continue.

The draft now uses the clarified information. Someone familiar with the order compares its two lines with the delivered work. They review it from the customer’s perspective: are the units understandable, is the service identifiable and do the amounts add up? The business content is therefore checked before the technical output is treated as ready.

Take the draft through checking and submission preparation

Next, generate the structured invoice and apply the built-in check to that exact version. This example describes a process, not the outcome of an actual Core session performed here. For your software decision, have the same sequence demonstrated with a suitable test invoice and examine the messages that appear.

Suppose validation reports a missing required detail. The office identifies the information and obtains its confirmed value from the responsible source. It then generates the invoice again and repeats the check. This loop has a limited, concrete purpose: the reported cause must be corrected in the new version before that file is used for submission.

After the machine check passes, compare the result with the approved invoice calculation. In the example, €800, €200, €1,000, €190 and €1,190 must still agree. Check the recipient and reference too. A technical correction must not accidentally change another business detail. Review the actual final result, rather than looking only at the earlier error message.

Then prepare the agreed submission route. File generation and delivery are different steps. An XRechnung capability does not automatically include every possible transport channel. Your team must know which file goes to which recipient through which confirmed route. Use the appropriate test procedure during evaluation so a fictional invoice is not accidentally submitted as a real payment demand.

Handle responses according to their cause

A response may still arrive after generation. Distinguish transmission problems, formal data issues and substantive questions about the order. Treating all of them as one “invoice rejected” state can trigger the wrong work. For example, the office may edit service descriptions when the real problem is an incorrect recipient reference.

For transmission trouble, inspect the actual submission route and file concerned. For a data message, locate the specified information in the invoice record. For a question about service scope, involve the person responsible for the order. This distinction determines who can help and what information is needed for the next useful action.

In the example, the recipient might ask which part of the purchase order the second line relates to. The amounts remain arithmetically correct. Your team compares the agreed service with its presentation and answers from the order. Whether an explanation is enough or a corrected invoice is needed depends on the actual case and your established invoicing procedure.

Avoid rushing into a second submission without an understandable link to the first. When a correction is made, the team should identify the version now in use and why it changed. Handling an invoice already issued belongs to your agreed process. This article promises neither automatic customer acceptance nor a particular payment time following technical validation.

Choose software using the complete invoice case

A useful demonstration begins with your own confirmed information and ends with understandable submission preparation. Observe which details require re-entry and which remain available from the order. Repeated typing is particularly costly when the same information is required for every invoice. The connected transaction should reduce work at those recurring points.

Also test a normal change, such as a quantity adjustment confirmed before invoicing. Can the team understand the new version, check it again and select it clearly for submission? A demonstration without any correction shows only part of everyday work. Handling a realistic change belongs in the decision about whether the software fits your business.

Record the office work involved: obtaining details, checking the order, reviewing the draft, resolving a message and preparing submission. This is your own observation, not a claimed automatic Core analysis. It shows where your business loses time. If purchase orders are mostly incomplete, improvement starts before anyone clicks the export button.

Compare relevant cases within your own business without creating an unnecessarily large test programme. An ordinary invoice and one meaningful variant can show whether the initial use fits. If a new problem appears, add a targeted check. The objective remains an invoice process the team can handle, rather than the longest possible list of enabled features.

Start with a manageable order-to-invoice process

Prepare a confirmed order, the correct recipient, required references and a person available for questions. Agree who checks the content and who checks submission readiness. In a small team, one person may do both. The distinction still helps avoid mistaking a technical success for a transaction that has been completely handled.

On the Core page, explore the connection between quotation, order and invoice, along with XRechnung and built-in validators. Create access through the existing start route. Use your prepared case as the basis: the desired result is a clear invoice whose data, checks and next handover step your office can explain. That is how software can shorten the journey to a usable customer invoice.

Explore Core and prepare your first XRechnung workflow