E-INVOICE IT für SIGN IT-Kunden

Dieser Leitfaden richtet sich an Kunden, die bereits über eine funktionierende SIGN IT-Integration verfügen und die italienische B2B-E-Rechnungsstellung (E-INVOICE IT) ergänzen möchten. Beide Produkte basieren auf derselben Unified API und teilen sich dieselbe Taxpayer- und Location-Struktur — es sind nur wenige Ergänzungen erforderlich.

Was Ihre SIGN IT-Integration bereits abdeckt

Vor dem Start wird davon ausgegangen, dass Ihre Integration Folgendes umfasst:

Einen Taxpayer, der mit italienischen Fiskalisierungsdaten erstellt wurde (fiscalization.type=IT, tax_id_number, vat_id_number, credentials)
Den in Betrieb genommenen Taxpayer (state=COMMISSIONED, mode=OPERATIVE)
Ein FISCAL_DEVICE System, das auf der Location des Taxpayers in Betrieb genommen wurde
Einen INTENTION::TRANSACTION → TRANSACTION::RECEIPT Ablauf für fiskalische Belege

Nichts davon muss geändert werden. Die folgenden Schritte ergänzen E-INVOICE IT zum bestehenden Setup.

Schritt 1 — Taxpayer-Onboarding-Daten erweitern

Zwei Ergänzungen am Taxpayer sind erforderlich, die SIGN IT allein nicht benötigt:

address.region — der italienische Provincia-Code (z. B. MI, RM) ist für die SDI-Übermittlung obligatorisch. Falls er noch nicht am Taxpayer gesetzt ist, fügen Sie ihn über updateTaxpayer hinzu.
fiscalization.registration — ein neuer Block mit Daten aus dem Registro delle Imprese / REA. Erforderliche Felder: company_id, office, entry, legal_form, capital, shareholder_status, liquidation_status. tax_regime ist optional (Standardwert ORDINARY). Dieser Block ist auf API-Ebene optional, wird aber vom SDI für registrierte Unternehmen verlangt und sollte beim Onboarding bereitgestellt werden.

Beispiel: PATCH /taxpayers/{taxpayer_id}

{
  "content": {
    "address": {
      "region": "MI"
    },
    "fiscalization": {
      "type": "IT",
      "registration": {
        "company_id": "MI12345678901234567",
        "office": "MI",
        "entry": "1234567",
        "legal_form": "LIMITED_LIABILITY_COMPANY",
        "capital": "10000.00",
        "shareholder_status": "MULTIPLE_SHAREHOLDERS",
        "liquidation_status": "NOT_IN_LIQUIDATION"
      }
    }
  }
}

💡address.region bereits vorhanden?

Wenn Ihre SIGN IT-Integration die vollständige Adresse des Taxpayers einschließlich region bereits erfasst, ist hier keine Änderung nötig — fügen Sie lediglich den registration-Block hinzu.

Schritt 2 — Ein zusätzliches System in Betrieb nehmen

Verwenden Sie createSystem, um ein E_INVOICE_SERVICE System auf der Location des Taxpayers zu erstellen, und nehmen Sie es anschließend über updateSystem in Betrieb.

📘Note

Pro Taxpayer wird nur ein E_INVOICE_SERVICE System benötigt, das mit der HEAD_OFFICE Location verknüpft ist — diese wird bei der Erstellung des Taxpayers automatisch angelegt. Dies ist getrennt von den FISCAL_DEVICE Systemen für die Belegfiskalisierung, die mit einzelnen BRANCH Locations verknüpft sind und in beliebiger Anzahl daneben bestehen können.

Schritt 3 — Den Rechnungs-Transaktionsablauf hinzufügen

SIGN IT verwendet TRANSACTION::RECEIPT. E-INVOICE IT verwendet einen anderen Transaktionstyp im selben INTENTION::TRANSACTION Container:

B2B-Rechnung → erstellen Sie eine TRANSACTION::INVOICE, verknüpft mit dem E_INVOICE_SERVICE System
Gutschrift → erstellen Sie eine TRANSACTION::CORRECTION mit data.type=INVOICE, die über record.id auf die ursprüngliche Rechnung verweist

📘Nur B2B

Es werden ausschließlich BUSINESS-Empfänger unterstützt. Der Empfänger muss einen invoicing-Block vom Typ SDI mit einem gültigen destination_code haben. B2C-Rechnungen sind derzeit nicht im Umfang enthalten.

Umgang mit SDI-Antworten

Asynchrones Ergebnis

Anders als bei Beleg-Abläufen erfolgt das SDI-Ergebnis asynchron. Nach dem Erstellen der TRANSACTION::INVOICE fragen Sie den E_INVOICE::TRANSMISSION Record ab oder warten auf Aktualisierungen.

💡Tip

SDI-Ergebnisse treffen in der Regel innerhalb weniger Minuten ein. Die SDI-Spezifikation lässt jedoch bis zu 48 Stunden zu.

Alle drei Records erreichen ihren Endzustand gemeinsam:

Record	Endzustand
`E_INVOICE::TRANSMISSION`	`COMPLETED` oder `FAILED`, `mode=FINISHED`
`TRANSACTION::INVOICE`	`COMPLETED` oder `FAILED`, `mode=FINISHED`
`INTENTION::TRANSACTION`	`COMPLETED` oder `FAILED`, `mode=FINISHED`

Im Fehlerfall ist der SDI-Ablehnungsgrund im Feld logs[].message aller drei Records verfügbar.

📘Note

Das Compliance-Artefakt für die italienische E-Rechnungsstellung ist das FatturaPA-XML, das über den E_INVOICE::TRANSMISSION Record zugänglich ist.

Weitere Details finden Sie unter How to check the status of an e-invoice auf unserer Support-Seite.

Fehlerstufen

Fehler können in drei verschiedenen Phasen auftreten, jeweils mit unterschiedlichem Verhalten:

Phase	Wann	Verhalten
UAPI-Validierung (synchron)	Ungültiges Payload	`4xx` wird sofort zurückgegeben — es wird kein Record erstellt. Korrigieren Sie das Payload und versuchen Sie es erneut mit demselben `INTENTION::TRANSACTION`.
Invopop-Validierung (asynchron)	Invopop lehnt ab, bevor das SDI erreicht wird	Die gesamte Kette erreicht `state=FAILED` — für einen erneuten Versuch ist eine neue Kette erforderlich.
SDI-Ablehnung (asynchron)	SDI gibt `NS` zurück	Die gesamte Kette erreicht `state=FAILED` — für einen erneuten Versuch ist eine neue Kette erforderlich.

Fehler und erneute Übermittlung

Wenn das SDI NS (Notifica di Scarto) zurückgibt, ist die Rechnung rechtlich nicht existent:

Lesen Sie logs[].message an einem der drei Records, um den SDI-Ablehnungsgrund zu erhalten
Erstellen Sie eine neue INTENTION::TRANSACTION und eine neue TRANSACTION::INVOICE mit den korrigierten Daten
Dieselbe document.number darf innerhalb von 5 Tagen nach der NS-Ablehnung erneut verwendet werden
Die fehlgeschlagene Kette bleibt dauerhaft FAILED — sie wird zu Prüfzwecken aufbewahrt

⚠️Kein automatischer erneuter Versuch

Jede erneute Übermittlung startet eine neue Transaktionskette — UAPI behandelt sie als völlig neue Übermittlung.

Was unverändert bleibt

Folgendes bleibt vollständig unberührt:

Der Inbetriebnahme-Ablauf des Taxpayers und die Fisconline-Anmeldedaten
Alle FISCAL_DEVICE Systeme und BRANCH Locations
Ihr bestehender INTENTION::TRANSACTION → TRANSACTION::RECEIPT Beleg-Ablauf

Was this page helpful?