ออก XRechnung ที่เป็นไปตามข้อกำหนด

Open the priced bill and work out what this interim actually bills: the positions finished on site in this period, measured rather than estimated, and the amount that falls on them.

เหตุผล: An interim invoice is a payment on account for work genuinely done. A position billed ahead of the Leistungsstand is the one the client's surveyor strikes out, and the rest of the invoice waits while that single line is argued.

On the receivable side of the Invoices tab, raise the interim invoice with its number, invoice date, due date and one line per block of work it bills, and pick the client from the contacts rather than typing a name into a free text field.

เหตุผล: The electronic invoice is built from this record and nothing else, so a line missing here is a line missing in the XML. Picking the linked contact is what lets the buyer address be read instead of retyped on every invoice you send that client.

Open the client contact the invoice bills and fill in the buyer party the standard wants: legal name, street, postcode, town and the two-letter country code. The electronic invoice reads the buyer from here, not from the invoice.

เหตุผล: An invoice whose buyer has no postal address is rejected outright, and for XRechnung the town and the postcode are each a fatal finding of their own. Filling them once on the contact fixes every invoice you will ever send that client.

Under Settings, E-invoice, set your own side once: legal name and address, VAT identifier or tax number, a named contact with telephone and email, the IBAN the client pays into, and the payment terms you invoice on.

เหตุผล: XRechnung asks for more than the European standard does, and the named seller contact with a phone number and an email is exactly where it goes further. Set it here and it is right on every invoice afterwards, instead of being chased once a month.

Open the electronic invoice dialog on that invoice, pick the XRechnung profile, and read what comes back. Blocking findings quote the rule identifier that will reject you, BR-DE-15 for a missing Leitweg-ID among them. Fix each one and run it again.

เหตุผล: This is the same rule set the receiving portal runs, quoted in the same words. Reading BR-DE-15 here costs you a minute. Reading it in a rejection notice three weeks later costs you the whole payment period and a second run at the invoice.

The download only unlocks once the check is clean. Take the XML: that file is the invoice. A hybrid PDF carrying the same data inside it is there for readers who want a page to look at, and it is not what the receiver parses.

เหตุผล: A public buyer's system reads the XML and ignores whatever you attached for human eyes. Sending a PDF and calling it an electronic invoice is the most common way a small firm finds out what the mandate actually asked for.

Log the send: the registration you issued under, the document itself, and the transmission id the portal or the access point gave back. The Leitweg-ID it was routed on is what the record keeps.

เหตุผล: Germany routes an invoice rather than clearing it, so no authority stamps yours. The transmission id is the only proof you sent it on the day you say you did, and it is what you quote when the client's accounts department cannot find it.