How one invoice moves | eurinvoice docs

In plain words

This page follows one invoice from the client's ERP to the list of failed invoices. What matters to the business: when an invoice is wrong, the answer names the field in the client's export and says who fixes it, before anything is sent. In the hosted sandbox the last step has no country connection yet.

One invoice, from the ERP's export to the care list. The yellow slip is the answer that names the field in the client's export. The dashed box is the rail. The hosted sandbox has none configured yet.

The invoice leaves the client's ERP as an ERP export (Business Central or SAP Business One), canonical JSON or a finished XML file.
It arrives through POST /invoices, POST /invoices/xml or a file in the drop directory.
The canonical model checks the structure. A failure names the field.
The route's own validators run: KoSIT for Germany, Schematron for Peppol, France and Romania, the FA(3) schema for Poland. The answer is 202 with an id, or 422 with a catalogue code that names the field, says who acts and gives a fix hint.
A passing invoice waits in a queue. KSeF, Peppol, France and Germany share the fast lane. ANAF has a slow lane of its own.
A route with a rail credential sends the invoice. Germany has no rail: its invoice ends at ready and the partner delivers the file. A route with no credential, as on the hosted sandbox today, sends nothing.
Each result becomes a status event, kept in order. See statuses.
A permanent rejection lands on the care list. Transient failures are retried, and reach it only when the retries run out.

Note

A finished XML file takes a shortcut. It gets a safety check and the route's validators (step 4), but no canonical check or mapping, and joins the queue at step 5.

POST /validate runs steps 3 and 4 only. It stores nothing, sends nothing and always answers 200 with a report. See dry run.