Section navigation

Alemania — E-INVOICE DE (Unified API)

En Alemania, fiskaly admite el envío y la recepción de facturas electrónicas B2B. La facturación electrónica está regulada por el Ministerio Federal de Finanzas (BMF — Bundesministerium der Finanzen). Todas las facturas electrónicas deben cumplir con la EN 16931, que se satisface mediante formatos como XRechnung, ZUGFeRD o Peppol BIS 3.0 Billing, y deben archivarse durante 8 años en un formato electrónico conforme (§14b UStG).

fiskaly genera facturas electrónicas conformes con la EN 16931 y las entrega a través de uno de dos canales. El canal se elige por factura en el destinatario (recipients[].invoicing): por correo electrónico — como ZUGFeRD o XRechnung — o a través de la red PEPPOL, como XRechnung.

Las dos direcciones se configuran de forma distinta:

📤

Envío — B2B

Dos canales de entrega, elegidos por factura en el destinatario: por correo electrónico como ZUGFeRD o XRechnung, o a través de la red PEPPOL como XRechnung. El correo electrónico no requiere ningún registro en la red.

📥

Recepción — B2B

Solo a través de PEPPOL, por lo que requiere el registro opcional en PEPPOL y un Proof of Ownership verificado. Un Taxpayer que solo envía por correo electrónico no puede recibir. Actualmente no se reciben las XRechnung entrantes.

Esta página cubre los requisitos específicos de Alemania que complementan la Integración general paso a paso. Asegúrate de tener a mano la siguiente información del contribuyente antes de continuar:

vat_id_number — Número de identificación fiscal a efectos del IVA (Umsatzsteuer-ID)
credentials.tax_number — Número fiscal en formato ELSTER (Steuernummer)
name — Nombre legal registrado y nombre comercial de la empresa o de la persona física
address — Domicilio social registrado de la empresa o de la persona física

📘El número de IVA es necesario para la puesta en servicio

Un System E_INVOICE_SERVICE alemán no puede ponerse en servicio si el Taxpayer no tiene un vat_id_number válido. La Steuernummer indicada en credentials.tax_number no basta: las facturas electrónicas alemanas exigen una identidad fiscal en forma de número de IVA, así que los dos campos no son intercambiables aquí. Sin él, la puesta en servicio falla con 422 Unprocessable Content.

Envío de facturas electrónicas: requisitos del destinatario

Para enviar una factura electrónica, indicas el destinatario y cómo debe llegarle el documento directamente en el registro de la factura. Cuando creas la factura (TRANSACTION::INVOICE) con createRecord, añades el destinatario a su array recipients.

Como explica la Integración general paso a paso, cada destinatario debe ser de tipo BUSINESS y tener el bloque invoicing completado. Además de los datos estándar de toda factura electrónica (nombre, dirección e identificación fiscal del destinatario, líneas de factura, etc.), en Alemania se añade el canal de entrega en el propio destinatario:

recipients[].type = BUSINESS
recipients[].identification.type = VAT — la factura electrónica alemana identifica al comprador por su número de IVA
recipients[].invoicing.type = EMAIL o PEPPOL — el canal de entrega
recipients[].invoicing.email — (solo EMAIL) la dirección de correo electrónico del destinatario
recipients[].invoicing.format — (solo EMAIL, opcional) el formato del documento
recipients[].invoicing.identifier — (solo PEPPOL) el PEPPOL Network Identifier del destinatario

`invoicing.type`	También obligatorio	Cómo lo entrega fiskaly
`EMAIL`	`invoicing.email`	Por correo electrónico a esa dirección, como ZUGFeRD o XRechnung según `invoicing.format`.
`PEPPOL`	`invoicing.identifier`	Al punto de acceso PEPPOL del destinatario, como XRechnung — consulte la limitación de XRechnung.

El canal se elige por factura, no de forma fija para cada destinatario — la misma empresa puede recibir una factura por correo electrónico y la siguiente a través de PEPPOL.

📘Importante

Sin el bloque invoicing, la factura electrónica se crea pero no se entrega al destinatario.

Registro en PEPPOL

En Alemania, el registro en la red PEPPOL es opcional: decides activarlo System por System.

Indícalo en el System E_INVOICE_SERVICE con createSystem:

{
  "content": {
    "type": "E_INVOICE_SERVICE",
    "location": { "id": "..." },
    "software": { "...": "..." },
    "registrations": [{ "type": "PEPPOL" }]
  }
}

O añádelo a un System existente con updateSystem:

{
  "content": {
    "registrations": [{ "type": "PEPPOL" }]
  }
}

Lo que se deriva de esa elección:

registrations omitido — el System solo envía por correo electrónico. No interviene ningún Proof of Ownership y el System pasa directamente al modo OPERATIVE.
registrations incluye PEPPOL — se requiere un Proof of Ownership. Al ponerlo en servicio, el state del System pasa a COMMISSIONED pero su mode pasa a DEGRADED, y el System incluye una entrada de registro que indica que falta el Proof of Ownership.

Para llevar el System al modo OPERATIVE, sube el Proof of Ownership como se describe en el paso 11 de la guía general de integración. La verificación tarda hasta 72 horas; cuando termina, el System cambia de estado automáticamente y la entrada de registro se elimina. El contenido que debe mostrar el documento se describe en la sección Proof of Ownership.

📘Añadir PEPPOL más tarde

Puedes añadir PEPPOL a un System que ya esté en servicio. Eso vuelve a ejecutar la comprobación del Proof of Ownership, así que un System que nunca haya aportado el documento regresa al modo DEGRADED hasta que lo haga.

Envío a través de PEPPOL

En el destinatario de tu solicitud createRecord, establece:

recipients[].invoicing.type = PEPPOL
recipients[].invoicing.identifier — el PEPPOL Network Identifier del destinatario

Antes de usarlo hacen falta dos cosas: tu System E_INVOICE_SERVICE debe estar registrado en la red PEPPOL (consulta Registro en PEPPOL) y debes disponer del PEPPOL Network Identifier del destinatario. Del esquema del identificador se encarga fiskaly.

Las facturas enviadas por esta vía se generan como XRechnung. recipients[].invoicing.format no interviene aquí: en este canal el formato no es seleccionable.

⚠️La mayoría de los destinatarios PEPPOL no pueden recibir XRechnung

PEPPOL registra a cada participante para los tipos de documento concretos que puede recibir, y XRechnung es un tipo de documento propio dentro de la red. El envío a un destinatario que no está registrado para XRechnung falla con receiver does not support document type.

Lo determinante aquí no es la conformidad: XRechnung sigue las reglas de Peppol BIS 3.0, pero eso no la hace entregable a un participante registrado únicamente para Peppol BIS Billing 3.0. Actualmente fiskaly no genera Peppol BIS Billing 3.0 para Alemania: recipients[].invoicing.format ofrece ZUGFERD_V2 y XRECHNUNG_V3, y se aplica solo al canal de correo electrónico.

Mientras no sepa que un destinatario está registrado para XRechnung, envíele las facturas por correo electrónico.

📘B2G aún no está disponible

El envío a organismos públicos alemanes (B2G) todavía no está disponible, por lo que no se puede utilizar el direccionamiento mediante Leitweg-ID.

Envío por correo electrónico: elegir el formato del documento

Cuando el canal es EMAIL, decides qué formato de documento genera fiskaly. Indícalo en el mismo destinatario de tu solicitud createRecord, mediante recipients[].invoicing.format:

Valor	Formato
`ZUGFERD_V2` (predeterminado)	ZUGFeRD — un documento híbrido: un PDF/A-3 legible por personas con el XML estructurado incrustado en su interior.
`XRECHNUNG_V3`	XRechnung — una factura XML puramente estructurada, sin capa PDF.

El campo es opcional: si lo omites, fiskaly genera ZUGFERD_V2. Ambos formatos cumplen con la EN 16931.

Recepción de facturas electrónicas

La recepción de facturas entrantes se realiza a través de PEPPOL, por lo que depende del mismo registro en PEPPOL que el envío por PEPPOL — incluido un Proof of Ownership verificado. Un Taxpayer que solo envía por correo electrónico no puede recibir.

Cuando registras un Taxpayer alemán en PEPPOL, fiskaly lo registra por defecto tanto para enviar como para recibir. Las facturas entrantes dirigidas al PEPPOL Identifier del System se asocian a ese System, y fiskaly crea para cada una un Record de tipo E_INVOICE::RECEPTION.

⚠️Las XRechnung entrantes no llegan a su Taxpayer

El registro para la recepción cubre Peppol BIS Billing 3.0, no XRechnung. Una factura dirigida a su Taxpayer como XRechnung es rechazada por la red antes de llegar a fiskaly, por lo que no se crea ningún Record de tipo E_INVOICE::RECEPTION. Es la misma limitación de tipos de documento registrados que se describe en Envío a través de PEPPOL.

Llama a retrieveSystem para leer compliance.state:

TRANSMISSION_RECEPTION — el System puede enviar y recibir.
TRANSMISSION_ONLY — el System solo puede enviar.

⚠️Si compliance.state se queda en TRANSMISSION_ONLY

Enviar y recibir es el comportamiento por defecto, pero fiskaly recurre a un registro de solo envío si el registro en PEPPOL informa de un conflicto — normalmente porque el PEPPOL Participant Identifier de tu Taxpayer ya está registrado con otro proveedor. El System sigue siendo utilizable para enviar. Si esperabas recibir, ponte en contacto con el equipo de soporte de fiskaly en dev-support@fiskaly.com indicando el número de IVA del Taxpayer.

Recuperación de facturas recibidas

Cada factura dirigida a tu Taxpayer se recibe y se almacena automáticamente como un Record — no hay webhook, así que consulta la API para detectar las nuevas:

Llama a listRecords y filtra por E_INVOICE::RECEPTION.
Para cada Record nuevo, llama a retrieveRecord con compliance-artifact para obtener el XML firmado.

listRecords devuelve los Records más recientes (limit es 10 por defecto, del más reciente al más antiguo), así que lleva la cuenta de los que ya has procesado.