Für Rumänien: CIUS-RO-Vorprüfung, SPV-Einreichung, normalisierter Status, signierte Antwort und Eingangs-Posteingang.
← Zurück zur API-Dokumentation
Die erste Rechnung in 6 Schritten
- Führen Sie POST /v1/invoices/{id}/efactura/validate aus. Der CIUS-RO-Preflight (Rumänien) sendet nichts an ANAF und zeigt Ihnen genau, was abgelehnt würde.
- Reichen Sie die Rechnung mit POST /v1/invoices/{id}/efactura/submit ein, immer mit einem Idempotency-Key. Sie erhalten eine submission_id und einen status.
- Fragen Sie GET /v1/efactura/submissions/{id} ab, bis accepted oder rejected erreicht ist.
- Erzwingen Sie mit POST /v1/efactura/submissions/{id}/refresh eine neue Abfrage bei der rumänischen ANAF – sie zählt gegen das Kontingent von 10 pro Minute.
- Laden Sie das Archiv mit der signierten Antwort der rumänischen ANAF über GET /v1/efactura/submissions/{id}/download herunter.
Alle Endpunkte
| Methode | Endpunkt | Scope | Idempotency-Key | Anfragen / Minute |
|---|---|---|---|---|
| GET | /invoices/{invoice_id}/xml UBL-/CIUS-RO-XML (Rumänien) herunterladen | invoices:read | — | 120 |
| POST | /invoices/{invoice_id}/efactura/validate CIUS-RO-Vorprüfung (Rumänien) — validieren ohne Versand | efactura:read | — | 120 |
| POST | /invoices/{invoice_id}/efactura/submit Rechnung an die ANAF (SPV, Rumänien) senden | efactura:submit | erforderlich | 10 |
| GET | /efactura/submissions ANAF-Übermittlungen (Rumänien) auflisten | efactura:read | — | 120 |
| GET | /efactura/submissions/{submission_id} Eine Übermittlung abrufen | efactura:read | — | 120 |
| POST | /efactura/submissions/{submission_id}/refresh Aktuellen Status bei der ANAF (Rumänien) abfragen | efactura:read | — | 10 |
| GET | /efactura/submissions/{submission_id}/download Archiv der signierten Antwort herunterladen | efactura:read | — | 120 |
| GET | /efactura/inbox Über den SPV (Rumänien) eingegangene Lieferantenrechnungen | efactura:read | — | 120 |
| GET | /efactura/inbox/{inbound_id} Eine eingegangene Rechnung abrufen | efactura:read | — | 120 |
| GET | /efactura/inbox/{inbound_id}/download Archiv der eingegangenen Rechnung herunterladen | efactura:read | — | 120 |
| POST | /efactura/inbox/sync Neue SPV-Nachrichten (ANAF, Rumänien) in den Posteingang abrufen | efactura:read | — | 10 |
Was die 4invoices-API ist
bash
# CIUS-RO preflight. Sends NOTHING to ANAF.
curl -sS -X POST "https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/validate?include_xml=true" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# → {"invoice_id":"inv_01J7ABC","valid":false,
# "errors":["buyer.county is required for RO buyers"],
# "xml_base64":"PD94bWwg..."}bash
curl -sS -X POST https://api.4invoices.net/v1/invoices/inv_01J7ABC/efactura/submit \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H 'Idempotency-Key: efactura-inv_01J7ABC-1'
# → {"submission_id":"sub_01J7XYZ","status":"queued"}python
import time, requests
BASE = "https://api.4invoices.net/v1"
TERMINAL = {"accepted", "rejected"}
H = {"Authorization": f"Bearer {token}"}
def wait_for_anaf(submission_id, timeout=900):
deadline = time.time() + timeout
delay = 15
while time.time() < deadline:
r = requests.get(f"{BASE}/efactura/submissions/{submission_id}", headers=H, timeout=30)
r.raise_for_status()
status = r.json()["status"]
if status in TERMINAL:
return r.json()
# /refresh asks ANAF directly and shares the 10/min submit bucket.
requests.post(f"{BASE}/efactura/submissions/{submission_id}/refresh", headers=H, timeout=30)
time.sleep(delay)
delay = min(delay * 2, 120)
raise TimeoutError(submission_id)bash
# Pull new SPV messages, then read the inbound supplier invoices.
curl -sS -X POST https://api.4invoices.net/v1/efactura/inbox/sync \
-H "Authorization: Bearer $ACCESS_TOKEN"
curl -sS "https://api.4invoices.net/v1/efactura/inbox?limit=50" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# ANAF allows roughly ONE message-list call per minute per CIF,
# daher zählt /inbox/sync auf das 10/Min-Submit-Kontingent. Per Cron ausführen, nicht pollen.https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json
Der ANAF-e-Factura-Weg (Rumänien)
Fehler
| Status | Typ | Code |
|---|---|---|
| 422 | invalid_request_error | cius_ro_incomplete |
Häufige Fehler
- Normalisierter Lebenszyklus: not_sent → validating → queued → sent → processing → accepted | rejected | error.
- accepted bedeutet rechtswirksam übermittelt. rejected bedeutet, dass das nationale System (in Rumänien die ANAF) die Rechnung abgelehnt hat: korrigieren und erneut einreichen. error ist ein Übertragungsfehler auf unserer Seite und kann gefahrlos erneut versucht werden.
- Die Einreichung ist unumkehrbar: Eine zweite Kopie derselben Rechnung lässt sich nicht aus dem nationalen E-Rechnungssystem zurückziehen. Deshalb ist der Idempotency-Key Pflicht.
- GET /v1/invoices/{id}/xml liefert Ihnen das UBL-/CIUS-RO-XML (das rumänische Profil) ganz ohne Einreichung – für Ihr eigenes Archiv oder eine Prüfung.
- Posteingang: POST /v1/efactura/inbox/sync holt neue Nachrichten ab, GET /v1/efactura/inbox listet sie auf, und /download ruft das Archiv jeder eingehenden Rechnung ab.
- Die e-Factura-Endpunkte funktionieren nur für rumänische Mandanten; andernfalls erhalten Sie ein 404.
Fragen und Antworten für Entwickler
Wie lange braucht ANAF (Rumänien), um eine Rechnung anzunehmen?
Das variiert, von Sekunden bis zu Stunden. Blockieren Sie den Verkauf nicht: Reichen Sie asynchron ein und behandeln Sie accepted und rejected als Ereignisse.
Kann ich das CIUS-RO-XML erhalten, ohne etwas an die rumänische ANAF zu senden?
Ja. GET /v1/invoices/{id}/xml erzeugt das Dokument ohne Einreichung, und /efactura/validate mit include_xml=true liefert es base64-kodiert zurück.
Wie oft kann ich inbox/sync ausführen?
Höchstens 10 Aufrufe pro Minute, in der Praxis lässt ANAF in Rumänien aber nur ungefähr einen Aufruf der Nachrichtenliste pro Minute und CIF zu. Führen Sie es per Cron alle paar Minuten aus.
Was tue ich, wenn der Status auf error bleibt?
error ist ein Übertragungs- oder Authentifizierungsfehler auf unserer Seite, ein erneuter Versuch ist also gefahrlos. Bleibt er bestehen, senden Sie die request_id an den Support.