Kunden und ANAF-Registerabfrage (Rumänien)

Ein auf tax_id dedupliziertes Anlegen oder Aktualisieren plus ANAF-Registerabfrage für rumänische Unternehmen, damit die e-Factura nicht abgewiesen wird.

← Zurück zur API-Dokumentation

Die erste Rechnung in 6 Schritten

POST /v1/clients legt einen Kunden an oder aktualisiert ihn, dedupliziert anhand von tax_id und, falls diese fehlt, anhand des normalisierten Namens.
GET /v1/clients listet Kunden mit limit, offset und der Freitextsuche q.
GET /v1/lookup/company/{tax_id} prüft eine rumänische CUI gegen das ANAF-Register und liefert die amtlichen Daten.
Befüllen Sie buyer vorab mit dem Ergebnis der Abfrage, damit die e-Factura nicht wegen eines veralteten Namens oder einer veralteten Adresse abgelehnt wird.

Alle Endpunkte

Methode	Endpunkt	Scope	Idempotency-Key	Anfragen / Minute
GET	/clients Kunden auflisten	clients:read	—	120
POST	/clients Kunden anlegen oder aktualisieren	clients:write	—	30
GET	/lookup/company/{tax_id} Eine rumänische CUI im ANAF-Register prüfen	clients:read	—	120

Was die 4invoices-API ist

bash
# Dedupliziert nach tax_id, ersatzweise nach dem normalisierten Namen:
# Erneutes Senden desselben Kunden AKTUALISIERT ihn, statt ein Duplikat anzulegen.
curl -sS -X POST https://api.4invoices.net/v1/clients \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Exemplu Comert SRL",
    "tax_id": "RO12345678",
    "email": "[email protected]",
    "country": "RO",
    "county": "Cluj",
    "city": "Cluj-Napoca",
    "address": "Str. Fabricii 12",
    "iban": "RO49AAAA1B31007593840000"
  }'

bash
curl -sS https://api.4invoices.net/v1/lookup/company/RO12345678 \
  -H "Authorization: Bearer $ACCESS_TOKEN"

# Offizielle Daten aus dem ANAF-Register (Rumänien) — damit "buyer" vorausgefüllt wird, damit
# die e-Factura nicht wegen eines veralteten Namens oder einer alten Adresse abgelehnt wird.

https://api.4invoices.net/v1 · https://api.4invoices.net/v1/openapi.json

Häufige Fehler

Für die Ausstellung brauchen Sie keinen gespeicherten Kunden: Das buyer-Objekt kann direkt in POST /invoices mitgesendet werden.
Bei rumänischen Käufern muss county der tatsächliche Kreis sein; für Bukarest tragen Sie den Sektor in city ein.
tax_id wird mit oder ohne Länderpräfix akzeptiert (RO12345678 oder 12345678).
Wird derselbe Kunde erneut gesendet, aktualisiert das den Datensatz, sodass ein wiederholter Import keine Duplikate erzeugt.

Fragen und Antworten für Entwickler

Welchen Scope braucht die Abfrage im rumänischen ANAF-Register?

clients:read. Das Schreiben von Kunden erfordert clients:write.

Kann ich Tausende von Kunden aus einem Altsystem importieren?

Ja, aber beachten Sie das Schreibkontingent von 30 pro Minute. Importieren Sie in Batches mit Backoff bei 429.

Was, wenn die CUI nicht im Register steht?

Die Abfrage liefert 404 not_found. Sie können trotzdem mit Ihren eigenen Daten ausstellen, riskieren aber bei der Einreichung eine Ablehnung (in Rumänien nach CIUS-RO).

Siehe auch