En Italia, fiskaly admite el envío de facturas electrónicas B2B y B2C, y la recepción de facturas electrónicas B2B. Actualmente admitimos la Factura estándar (Fattura, TD01) y la Nota de crédito (Nota di credito, TD04). El tipo de documento se deriva de la operación de la Unified API y no se establece directamente. Las facturas de anticipo (TD02) y las facturas diferidas (TD24, TD25) no se emiten actualmente. El soporte para la Factura simplificada (Fattura semplificata, TD07) llegará próximamente.
La facturación electrónica es obligatoria y está regulada por la Agenzia delle Entrate (Agencia Tributaria). Todas las facturas B2B deben intercambiarse a través del SDI (Sistema di Interscambio — Sistema de Intercambio) en el formato XML FatturaPA (factura electrónica) y son obligatorias por ley desde enero de 2019. Las facturas también deben conservarse a largo plazo mediante archivado certificado (conservazione a norma).
Esta página cubre los requisitos específicos para Italia que complementan la Guía de integración general paso a paso para dar de alta un Taxpayer en la facturación electrónica.
fiskaly gestiona ambas direcciones del intercambio con el SDI, y las dos funcionan de forma diferente:
Envío — B2B y B2C
fiskaly genera la FatturaPA y la envía al SDI, que la valida y la reenvía al destinatario de forma asíncrona. No se requiere registro en la red. Los destinatarios empresa y los consumidores requieren campos distintos.
Recepción — solo B2B
Opcional, y se habilita por Taxpayer. Requiere un registro único para recibir las facturas de tus proveedores.
Además del intercambio en ambas direcciones, fiskaly archiva automáticamente cada factura que envías y recibes. Esto supone la conservación certificada a largo plazo (conservazione a norma) durante los 10 años exigidos por ley, sin ninguna configuración por tu parte.
Si ya tienes una integración de SIGN IT, no empiezas desde cero — amplías tu Taxpayer existente con los datos de registro adicionales y pones en servicio un System E_INVOICE_SERVICE. Consulta E-INVOICE IT para clientes de SIGN IT para ver todos los pasos.
Requisitos previos
Sección titulada «Requisitos previos»Estos requisitos se aplican a cualquier Taxpayer que des de alta para la facturación electrónica en Italia, ya sea que envíes, recibas o hagas ambas cosas. Asegúrate de tener disponible la siguiente información del Taxpayer antes de continuar.
E-INVOICE IT admite actualmente Taxpayers de tipo COMPANY. Dar de alta un Taxpayer INDIVIDUAL — un autónomo o empresario individual que emite con su propio codice fiscale en lugar de un NIF de empresa — llegará próximamente.
Datos de registro específicos para Italia — enviados en content.fiscalization.registration:
company_id— Numero Registro Imprese (número del Registro Mercantil)office— código de provincia de la Camera di Commercio que emitió el número REA, p. ej.MI,RMentry— número REA (6 o 7 dígitos)legal_form— forma jurídica de la entidad (p. ej.LIMITED_LIABILITY_COMPANY,JOINT_STOCK_COMPANY)capital— capital social registrado en EUR (p. ej."10000.00")shareholder_status—SOLE_SHAREHOLDERoMULTIPLE_SHAREHOLDERSliquidation_status—IN_LIQUIDATIONoNOT_IN_LIQUIDATIONtax_regime— opcional,ORDINARY(predeterminado) oFLAT_RATE_SCHEME(Regime Forfettario)
Campos estándar del Taxpayer — parte del propio Taxpayer (compartidos con SIGN IT si lo utiliza):
content.name— denominación legal registrada de la empresa o del individuocontent.address— dirección legal registradacontent.address.region— Provincia (código de provincia, p. ej.MI,RM); obligatorio en el Taxpayer y validado al poner en servicio
Para la facturación electrónica en Italia, content.fiscalization.registration y content.address.region (Provincia) son campos obligatorios en el Taxpayer. Se validan al poner en servicio el System E_INVOICE_SERVICE — la puesta en servicio falla si faltan. Asegúrate de que ambos campos estén establecidos o actualizados en el Taxpayer de antemano.
Envío de facturas electrónicas: requisitos del destinatario
Sección titulada «Envío de facturas electrónicas: requisitos del destinatario»Para enviar una factura electrónica, indica su destinatario y sus datos de enrutamiento directamente en el Record de la factura. Cuando crees la factura (TRANSACTION::INVOICE) con createRecord, añade el destinatario a su array recipients. Los campos que debes rellenar dependen de a quién facturas:
Destinatarios empresa (B2B)
Se enrutan mediante el código de destinatario SDI, o por PEC si no tienen buzón SDI.
Destinatarios consumidores (B2C)
Los residentes en Italia se identifican por el codice fiscale; los consumidores en el extranjero, por un identificador extranjero.
Todo destinatario lleva invoicing.type = SDI. Lo que cambia entre los tres casos es la identificación, el código de destinatario y si interviene o no una PEC:
| Empresa | Consumidor en Italia | Consumidor en el extranjero | |
|---|---|---|---|
type | BUSINESS | CONSUMER | CONSUMER |
identification | VAT — validado | TAX — codice fiscale, validado | cualquier tipo; sin validar |
invoicing.destination_code | el código de 7 caracteres del destinatario, o "0000000", o "XXXXXXX" | "0000000" | "XXXXXXX" |
invoicing.pec | obligatoria con "0000000" | opcional | no se utiliza |
address.region | obligatoria cuando la dirección está en Italia | obligatoria | no obligatoria |
name | nombre de la empresa | gender, forename, surname | gender, forename, surname |
- El código de 7 caracteres que te haya facilitado el destinatario (p. ej.
ABC1234): solo letras mayúsculas y dígitos. "0000000": el destinatario no tiene buzón SDI, como todos los consumidores y las empresas que reciben por PEC."XXXXXXX": el destinatario está en el extranjero.
Destinatarios empresa (B2B)
Sección titulada «Destinatarios empresa (B2B)»Cada destinatario empresa es de tipo BUSINESS con el bloque invoicing cumplimentado, como explica la integración general paso a paso. Además de los datos estándar que requiere toda factura electrónica (nombre del destinatario, dirección, identificación fiscal, líneas de factura, etc.), Italia añade los campos de enrutamiento SDI indicados arriba.
Los valores que toman destination_code y pec dependen del destinatario:
| Escenario | destination_code | pec |
|---|---|---|
| El destinatario tiene un buzón SDI registrado | su código de 7 caracteres (p. ej. ABC1234) | opcional |
| El destinatario no está registrado en el SDI | "0000000" | obligatorio |
| El destinatario está fuera de Italia | "XXXXXXX" | no se utiliza |
Una pec es una dirección de Posta Elettronica Certificata, el correo electrónico certificado de Italia. El SDI comprueba el dominio, por lo que un buzón ordinario se rechaza.
"0000000" significa entrega por PEC, y por eso la pec es obligatoria en ese caso para un destinatario empresa.
recipients[].address.region (la Provincia del destinatario) no está marcada como obligatoria en el esquema compartido de la Unified API, pero Italia la exige siempre que la dirección esté en Italia. No se comprueba al crear el registro: createRecord responde correctamente y la transmisión falla más tarde, llevando toda la cadena a FAILED. Indíquela desde el principio en lugar de descubrirlo de forma asíncrona.
Destinatarios consumidores (B2C)
Sección titulada «Destinatarios consumidores (B2C)»Cuando tu cliente es un particular y no una empresa, establece recipients[].type en CONSUMER. La factura circula por el SDI como documento FatturaPA (TD01), igual que una factura B2B.
Los consumidores no tienen buzón SDI, así que el enrutamiento funciona de otra manera. Cómo identifique al consumidor depende de si reside en Italia:
- Residente en Italia — se identifica por su codice fiscale y se enruta con el código de destinatario
"0000000". - Fuera de Italia — no existe codice fiscale, por lo que un identificador extranjero ocupa su lugar y la factura se enruta con
"XXXXXXX".
Además de los campos de la tabla anterior, un destinatario consumidor lleva siempre name.gender, name.forename y name.surname, junto con su dirección.
Consumidores residentes en Italia
Sección titulada «Consumidores residentes en Italia»Envía el codice fiscale como identificación de tipo TAX (16 caracteres), el domicilio de residencia incluida la region (Provincia) y el código de destinatario "0000000". Puede añadirse una pec, pero no es obligatoria.
Para un consumidor residente en Italia la identificación es obligatoria, debe ser de tipo TAX y el codice fiscale se comprueba al crear el registro: si falta o tiene un formato incorrecto, la solicitud se rechaza ahí y no se crea ninguna factura. El SDI lo valida de nuevo contra el registro tributario, por lo que un código bien formado pero desconocido se rechaza en esa fase.
Consumidores fuera de Italia
Sección titulada «Consumidores fuera de Italia»Un consumidor que no reside en Italia no tiene codice fiscale, así que envía en su lugar un identificador extranjero, normalmente un número fiscal o de IVA extranjero.
| Campo | Valor |
|---|---|
recipients[].identification | obligatoria; VAT, TAX, PASSPORT, DOCUMENT u OTHER, según el identificador del que disponga |
recipients[].address.country | el país del consumidor como código ISO 3166-1 alfa-2 |
recipients[].address.code | "00000": FatturaPA solo acepta un código postal de 5 dígitos |
recipients[].invoicing.destination_code | "XXXXXXX" |
El identificador viaja al SDI como IdCodice; ni fiskaly ni el SDI comprueban su validez en cuanto el país de la dirección no es Italia. La region no es obligatoria para una dirección no italiana.
"XXXXXXX" indica al SDI que se solicita el despacho pero que la entrega a través del sistema de intercambio no procede: el SDI no tiene ningún canal para llegar a un destinatario en el extranjero. Envía al consumidor su copia de la factura (PDF o equivalente) por separado, fuera del SDI.
gender lo exige la Unified API, no el SDI: la factura FatturaPA no incluye ese campo. Envía DIVERSE cuando no tengas el dato.
Para un consumidor residente en Italia, el SDI deposita la factura original en su área reservada en el portal de la AdE (Fatture e Corrispettivi).
Cuando el cliente necesita una factura en lugar de un documento commerciale
Sección titulada «Cuando el cliente necesita una factura en lugar de un documento commerciale»Italia declara los dos documentos por canales separados —el documento commerciale por los corrispettivi, la factura por el SDI— y nada los vincula automáticamente.
Recoge la petición antes de cerrar la venta. Cuando el cliente te indique que necesita una fattura, emite una TRANSACTION::INVOICE en lugar de una TRANSACTION::RECEIPT. Es el flujo que fiskaly admite de principio a fin hoy, tanto si el cliente lo pide antes como durante la venta.
Estamos construyendo un camino compatible que vincule entre sí un documento commerciale fiscalizado y una factura electrónica, de modo que una misma operación tenga una sola factura y un solo rastro de auditoría. Hasta que esté disponible, recoge la petición de factura antes de cerrar la transacción.
Gestión de las respuestas del SDI
Sección titulada «Gestión de las respuestas del SDI»A diferencia de una llamada de API síncrona, el resultado del SDI es asíncrono. Tras crear la factura (TRANSACTION::INVOICE) con createRecord, consulta periódicamente el Record E_INVOICE::TRANSMISSION para saber si el SDI la ha aceptado. No existe ningún webhook.
Los resultados del SDI suelen llegar en pocos minutos. Sin embargo, la especificación del SDI permite hasta 48 horas.
Los tres Records alcanzan su estado final de forma conjunta:
| Record | Estado final |
|---|---|
E_INVOICE::TRANSMISSION | COMPLETED o FAILED, mode=FINISHED |
TRANSACTION::INVOICE | COMPLETED o FAILED, mode=FINISHED |
INTENTION::TRANSACTION | COMPLETED o FAILED, mode=FINISHED |
En caso de fallo, el motivo de rechazo del SDI está disponible en logs[].message en los tres Records. Para más detalles, consulta How to check the status of an e-invoice en nuestra página de Soporte.
Leer el resultado
Sección titulada «Leer el resultado»state te indica en qué punto está una factura y logs[] te indica por qué. Léelos juntos y actúa según lo que encuentres:
| Qué ves | Qué significa | Qué hacer |
|---|---|---|
4xx de createRecord, ningún Record creado | El payload se rechazó. No se creó nada y no se envió nada. | Corrige el payload y reinténtalo en el mismo INTENTION::TRANSACTION. |
state=ACCEPTED | Todavía en curso. | Consulta el Record E_INVOICE::TRANSMISSION. Los resultados suelen llegar en cuestión de minutos. |
state=FAILED | Finalizada, y la factura no es legalmente válida. O se detuvo camino al SDI o el SDI la rechazó con NS. | Lee logs[].message para conocer el motivo, corrige los datos e inicia una nueva cadena — consulta Fallos y reenvío. |
state=COMPLETED con una entrada ERROR en logs[] | Algo salió mal por el camino sin detener la factura. | Lee logs[].message antes de dar la factura por enviada. |
state=COMPLETED, sin entradas ERROR | El SDI aceptó la factura. | Nada más. |
Cada entrada de logs[] es un ERROR o un WARNING. Un WARNING es informativo y nunca bloquea una factura — recibes uno cuando algo de tu payload se ajustó o no cuadraba, por ejemplo si enviaste varios pagos pendientes y solo se usó el primero, o si los totales de IVA de tu payload difieren de los totales calculados a partir de las líneas de la factura.
No significa que el destinatario la haya recibido. El SDI notifica como éxito tanto la entrega (RC) como la no entrega (MC, que sigue siendo legalmente válida), y la API no distingue entre ambos casos.
Dónde se manifiestan los fallos de validación
Sección titulada «Dónde se manifiestan los fallos de validación»No todo rechazo parece un rechazo. Los datos de la factura se comprueban en tres puntos distintos, y cada uno falla de una forma diferente:
| Dónde falla | Ejemplo | Qué ves |
|---|---|---|
| Restricciones de esquema | identification.number fuera de AlphaNumerical28; document.number fuera de ^[0-9A-Z_/\-\.]{1,20}$ | 400 de createRecord. No se crea nada. |
| Validación de campo | Un codice fiscale con formato incorrecto o dígito de control erróneo | createRecord funciona. El Record se cierra en COMPLETED / FINISHED, pero content.used_in está ausente y no se transmite nada. El motivo aparece únicamente como entrada de content.logs con severidad ERROR. |
| Aguas abajo | Un recipients[].address.region ausente | createRecord funciona y la cadena pasa después a FAILED. |
La fila central es la que sorprende a los integradores: un Record COMPLETED / FINISHED sin factura detrás es idéntico a uno correcto si lees state y te detienes ahí. Lee siempre content.logs en busca de entradas ERROR y comprueba que content.used_in está presente antes de dar una factura por emitida.
Fallos y reenvío
Sección titulada «Fallos y reenvío»Si el SDI devuelve NS (Notifica di Scarto), la factura es legalmente inexistente:
- Lee
logs[].messageen cualquiera de los tres Records para obtener el motivo de rechazo del SDI - Crea una nueva
INTENTION::TRANSACTIONy una nuevaTRANSACTION::INVOICEcon los datos corregidos - El mismo
document.numberpuede reutilizarse dentro de los 5 días posteriores al rechazoNS - La cadena fallida permanece
FAILEDde forma permanente — se conserva con fines de auditoría
Cada reenvío inicia una nueva cadena de transacción — UAPI la trata como un envío completamente nuevo.
Recepción de facturas electrónicas
Sección titulada «Recepción de facturas electrónicas»Un System E_INVOICE_SERVICE puede tanto enviar como recibir facturas electrónicas. La recepción es opcional — un Taxpayer que solo envía puede omitir esta sección.
Intervienen dos cosas separadas e independientes:
- Disponibilidad para recibir — fiskaly la configura automáticamente cuando pones en servicio el System.
- Registro del código de destinatario SDI (manual, realizado por ti) — en tu portal de la Agenzia delle Entrate (AdE), establece el código de destinatario SDI de fiskaly
JKKZDGRcomo el destino SDI de tu empresa, de modo que el SDI enrute tus facturas entrantes a fiskaly.
La respuesta de la puesta en servicio muestra compliance.state como TRANSMISSION_ONLY. Luego pasa a TRANSMISSION_RECEPTION automáticamente una vez que se completa el registro del Taxpayer — lo cual normalmente ocurre, independientemente de si ha realizado el registro en la AdE o de si tiene previsto recibir.
TRANSMISSION_RECEPTION significa que el System puede recibir, pero no que las facturas entrantes se entreguen realmente al Taxpayer. Esa entrega requiere el registro en la AdE: mientras este no se complete, el Taxpayer no recibe ninguna factura, aunque el System esté listo. Puedes completar el registro en la AdE en cualquier momento — por ejemplo, para habilitar la recepción en un Taxpayer que anteriormente estaba configurado solo para enviar.
Llama a retrieveSystem en cualquier momento para leer el compliance.state actual, que refleja únicamente la disponibilidad — no el registro en la AdE:
TRANSMISSION_RECEPTION— fiskaly ha configurado el System para recibir.TRANSMISSION_ONLY— esa configuración no se ha completado.
Si retrieveSystem sigue devolviendo compliance.state = TRANSMISSION_ONLY tras la puesta en servicio, el registro del Taxpayer no se completó. Trátalo como una transición bloqueada y ponte en contacto con el soporte de fiskaly en dev-support@fiskaly.com con el VAT ID del Taxpayer para que podamos investigar.
No hay nada adicional que configurar para el enrutamiento: fiskaly asocia automáticamente cada factura entrante al Taxpayer correcto mediante su tax ID — razón por la cual cada tax ID debe pertenecer a un único Taxpayer registrado. No necesitas configurar ni almacenar un código de enrutamiento aparte.
Cuando llega una factura
Sección titulada «Cuando llega una factura»Cuando se te envía una factura a través del SDI, fiskaly la recibe automáticamente:
- la entrega entrante se procesa automáticamente por nuestra parte
- se crea un Record de recepción para la factura
- el XML firmado, el PDF y los metadatos se almacenan asociados al Record
- las entregas duplicadas se deduplican
En la práctica, la primera factura que te llega de esta forma es también tu confirmación de que la recepción está configurada correctamente.
Recuperar las facturas recibidas
Sección titulada «Recuperar las facturas recibidas»Cada factura dirigida a tu Taxpayer se recibe, valida y almacena automáticamente como Record — no existe ningún webhook, por lo que debes consultar la API para detectar las nuevas:
- Llama a
listRecordsy filtra porE_INVOICE::RECEPTION. - Para cada Record nuevo, llama a
retrieveRecordconcompliance-artifactpara 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 lleve un registro de los que ya ha procesado.
Si estás integrando E-INVOICE IT sin SIGN IT, ponte en contacto con el soporte de fiskaly en dev-support@fiskaly.com — te guiaremos en la configuración del Taxpayer para tu caso específico.
Archivado
Sección titulada «Archivado»La ley italiana exige que las facturas electrónicas se conserven a largo plazo mediante archivado digital certificado (conservazione a norma): deben conservarse durante al menos 10 años y almacenarse de modo que permanezcan inmutables, auténticas y fácilmente recuperables, con firmas digitales y sellos de tiempo (marca temporale). Conservar tu propia copia del XML no es suficiente — fiskaly se encarga de ello por ti.
Para Italia, el archivado es automático y siempre está activo: cada factura que envías y cada factura que recibes a través del SDI se conserva legalmente, sin configuración adicional ni llamada a la API por tu parte. Solo depende del tax ID italiano del Taxpayer, que ya forma parte del alta. Cada factura conservada obtiene un recibo de conservación como prueba de la conservazione a norma. La conservación se basa en eventos y suele completarse en segundos; el propio recibo puede tardar hasta unos seis minutos en emitirse, tras lo cual fiskaly lo adjunta automáticamente — no se requiere nada por tu parte.
Recupera los artefactos de una factura electrónica desde su Record con retrieveRecord, seleccionando el artefacto mediante un parámetro de consulta:
compliance-artifact— el documento legalmente vinculante. Para Italia, el XML FatturaPA validado por el SDI.archive-artifact— el recibo de conservación que atestigua la conservación legal (conservazione a norma), devuelto como XML firmado.
Elegir el formato de la respuesta
Sección titulada «Elegir el formato de la respuesta»Ambos artefactos tienen en cuenta la cabecera de petición Accept, que determina la forma de la respuesta:
Accept | Qué obtienes |
|---|---|
application/xml | El artefacto en sí: el XML FatturaPA o el XML del recibo de conservación. |
application/json | El Record en JSON, con el artefacto codificado en Base64 en el campo content habitual. |
El RecordResponse de la especificación solo declara application/json, por lo que la variante XML no aparece en la referencia. Aun así está soportada, y es la que usa la colección de Postman.
Cuándo están disponibles los artefactos
Sección titulada «Cuándo están disponibles los artefactos»compliance-artifact y archive-artifact no existen durante toda la vida de un Record. Ninguno se produce al crear el Record: ambos se escriben una vez que la transmisión se completa, es decir, una vez que el SDI ha respondido, algo que la especificación del SDI permite que tarde hasta 48 horas. Ambos quedan fijados en el mismo momento, porque el paso de archivado se ejecuta antes de que cambie el estado del Record.
De ahí sale una regla basada únicamente en el estado, sin nada que cronometrar:
| Estado del Record | Qué indica sobre los artefactos |
|---|---|
state: ACCEPTED, mode: PROCESSING | No es terminal. Los artefactos pueden faltar todavía, y que falten significa aún no: siguen en camino. |
state: COMPLETED / FAILED / REJECTED, mode: FINISHED | Terminal. Lo que haya es todo lo que va a haber; un artefacto ausente ya no aparecerá. |
Pedir un artefacto que todavía no existe devuelve 200 con el Record sin más: ningún error y ninguna señal de «aún no está listo». Decide a partir del state y el mode del Record si un artefacto ausente significa aún no o nunca, y no a partir de la respuesta a la petición del artefacto.
El recibo de conservación pertenece al Record E_INVOICE::TRANSMISSION y no a la TRANSACTION::INVOICE. Toma content.used_in.id del Record de la factura y, a continuación:
GET /records/{transmissionId}?archive-artifactEl recibo se devuelve codificado en Base64 en content.compliance.archive.data. Las facturas que envías y las que recibes tienen cada una su propio recibo. Mientras el artefacto no esté disponible, el campo está ausente de la respuesta en lugar de presente y vacío.
file-artifact devuelve el sobre firmado del Record tal como se envió: un envoltorio genérico que se usa para todos los tipos de Record, fijado en el momento de crear el Record y sin relación con la generación de la FatturaPA. Es XML bien formado, pero no es la FatturaPA y no debe registrarse como la factura. Para la FatturaPA, usa compliance-artifact.
Ni el recibo de conservación ni file-artifact son una representación de la factura. Para obtener una versión legible por personas, descarga el paquete de archivos de la transmisión — un ZIP con el XML FatturaPA, el mismo documento en PDF y un JSON de metadatos — desde su propio endpoint:
GET /files/{transmissionId}.zipEn el entorno de test el archivado se ejecuta de principio a fin, pero el resultado no tiene validez legal — es solo para pruebas de integración. Únicamente las facturas procesadas en live se certifican como legalmente conservadas.
Impuesto de timbre (imposta di bollo)
Sección titulada «Impuesto de timbre (imposta di bollo)»La legislación italiana exige un impuesto de timbre (imposta di bollo) de 2,00 € en las facturas cuyas líneas exentas de IVA superen en conjunto los 77,47 €. fiskaly lo aplica automáticamente: cuando el total de las líneas exentas de IVA correspondientes supera ese umbral, el impuesto de timbre se añade a la FatturaPA transmitida.
No existe ningún campo para el impuesto de timbre ni en la solicitud ni en la respuesta: no hay nada que establecer al crear la factura y no se devuelve nada en el Record. El único lugar donde aparece el valor aplicado es el elemento DatiBollo del XML FatturaPA, que puedes leer desde el documento transmitido:
GET /records/{transmissionId}?compliance-artifactEl XML llega codificado en Base64, así que descodifícalo antes de buscar DatiBollo.
Espera dos avisos de descuadre en los totales
Sección titulada «Espera dos avisos de descuadre en los totales»Los 2,00 € se añaden después de calcular los totales de la factura, de modo que en toda factura que supera el umbral los totales transmitidos son 2,00 € más altos que los que enviaste. El Record registra esa diferencia como dos entradas WARNING en content.logs, por ejemplo:
provided '100.00000000', calculated '102.00'Es lo esperado, y es la señal de que se aplicó el impuesto de timbre. Sigue enviando tus totales sin el impuesto: no existe ninguna carga útil que incluya el impuesto de timbre y a la vez evite los avisos. Trata estas dos entradas WARNING como informativas y no hagas fallar tu integración por ellas.
Así funciona hoy. El tratamiento del impuesto de timbre en los totales se está rehaciendo (META-5229), y después estos avisos dejarán de emitirse.
Abonar una factura emitida fuera de fiskaly
Sección titulada «Abonar una factura emitida fuera de fiskaly»En Italia el tipo de documento es el identificador de tipo FatturaPA: una CORRECTION se transmite como TD04 (Nota di credito) y una INVOICE como TD01 (Fattura). Como el tipo se deriva de la operación, una factura que fiskaly no transmitió no puede abonarse: emitir una TD01 que referencie la factura anterior incrementa el importe adeudado en lugar de cancelarlo. Consulta Nota de crédito para la regla general.
Para casos puntuales, el SdI concede acceso al portal a todos los comerciantes, donde puede emitirse una nota de crédito manualmente. Esto no escala y no es un patrón de integración: trátalo como alternativa de migración y mantén disponible el sistema de facturación electrónica anterior hasta que todo lo emitido en él esté liquidado o abonado.