Sending invoices
While using E-INVOICE DE, a failed outgoing e-invoice can be reported in three places, depending on where it failed. Check them in this order:
- the API response
- the
TRANSACTION::INVOICERecord - the
E_INVOICE::TRANSMISSIONRecord
Received invoices are reported differently. See Receiving invoices at the end.
A TRANSACTION::INVOICE in state COMPLETED does not by itself mean the invoice was sent. Always check its logs too. Log entries with "severity": "ERROR" mean the invoice was not processed. WARNING entries are informational only.
Step 1: Check the API response
If the request doesn't match the API schema, for example a field with the wrong format or an empty value, it's rejected with HTTP 400 (E_BAD_REQUEST). The message names the field. No Record is created. Fix the request and send it again.
Example message:
"message": "request validation failed: Error at \"/content/operation\": ... Error at \"/document/references/buyer\": doesn't match schema due to: minimum string length is 1"
Step 2: Check the TRANSACTION::INVOICE Record
If the request is accepted (HTTP 200), the invoice content is checked against the rules of the chosen format. If a rule is not met, the Record still shows COMPLETED, but content.logs contains an ERROR entry and content.used_in is missing. The invoice was not generated or sent.
{
"content": {
"type": "TRANSACTION::INVOICE",
"state": "COMPLETED",
"mode": "FINISHED",
"logs": [
{
"message": "invalid gobl invoice: ordering is required (BR-DE-15)",
"severity": "ERROR"
}
]
}
}
Step 3: Check the E_INVOICE::TRANSMISSION Record
If there is no ERROR log, retrieve the transmission Record using content.used_in.id:
GET /records/{used_in.id}
-
COMPLETED: the e-invoice was handed over for delivery. For email, there is no confirmation that it reached the recipient's inbox, and later bounces are not reported. -
FAILED: the e-invoice could not be generated or delivered, and it did not reach the buyer. The reason is incontent.logs.
Common error messages
| Message | What to do |
|---|---|
ordering is required (BR-DE-15) |
XRechnung requires document.references.buyer (1–32 characters). ZUGFeRD doesn't. |
business recipient identification is not a valid VAT identification |
Use identification.type: VAT for BUSINESS recipients. |
receiver does not support document type |
The Peppol recipient can't receive XRechnung. Send to them by email instead. |
How to send a failed invoice again
An invoice that failed in step 2 or 3 was not issued and did not reach the buyer. Don't create a credit note (CORRECTION) for it. Send it again instead:
- Fix the cause shown in the
ERRORlog, for example add the missing field or correct the recipient's email address. Change nothing else. - Create a new
INTENTION::TRANSACTION. - Create a new
TRANSACTION::INVOICEwith the corrected payload and a new idempotency key. Keep the same invoice number, and if you setdocument.issued_at, keep its original value.
Warning: When sending a failed invoice again, always keep its original invoice number. A new number would turn the resend into a second, separate invoice. A credit note (CORRECTION) is only for an invoice that reached the buyer and whose content is wrong.
Receiving invoices
Incoming invoices are received over Peppol as Peppol BIS Billing 3.0 (see Receiving invoices for more details). Other document types, including XRechnung, are rejected by the Peppol network before they reach fiskaly, so no Record is created for them.
Each received invoice is stored as an E_INVOICE::RECEPTION Record in state COMPLETED. This confirms receipt, not that the content is correct: problems in a received invoice are not flagged on the Record. You can retrieve the XML of each received invoice for your own processing with:
GET /records/{reception_record_id}?compliance-artifact
There's no webhook for received invoices yet. Call listRecords regularly, filtered for E_INVOICE::RECEPTION, and keep track of the Records you have already processed.
For more on Record states and logs, see How to check the status of an e-invoice?.