Los proveedores de TPV en Europa se enfrentan a dos obligaciones de cumplimiento a la vez. La fiscalización es terreno conocido: un país tras otro exige ya que cada transacción se firme en la caja de forma inalterable. La factura electrónica llega a toda velocidad. Italia exige facturas estructuradas desde 2019, Bélgica, Francia y Polonia se sumaron en 2026, y Alemania y España son las siguientes, en 2027.
Ante dos obligaciones, la mayoría de proveedores construye dos integraciones. La fiscalización se queda en el TPV, mientras que la factura electrónica pasa al back office, desconectada del cobro en el que se produjo la venta.
Sobre el papel funciona. En la práctica, una venta acaba en dos bases de datos, con dos pistas de auditoría que pueden no coincidir y, en el peor de los casos, el mismo IVA adeudado dos veces.
Así funciona cuando, en cambio, ambas pasan por el TPV, con una API, un proveedor y una pista de auditoría.
¿Qué pasa realmente cuando la factura vive en un segundo sistema?
"Desconectado" ya casi nunca significa papel y bolígrafo. Normalmente la herramienta de facturación electrónica está conectada al ERP, al software de contabilidad o a una capa de middleware intermedia. Cada transacción se exporta, se sincroniza o se vuelve a introducir y, en una diapositiva, parece un problema resuelto.
En realidad, varios sistemas comparten ahora la tarea de registrar una sola venta, y cada traspaso entre ellos es un punto en el que la verdad puede bifurcarse.
Sigamos una venta B2B a lo largo de esa cadena:
- La venta empieza en el TPV. Las líneas, los tipos de IVA, el pago y la firma fiscal se registran en el mostrador. Este es el registro jurídicamente vinculante.
- Los datos salen del TPV. Viajan por una exportación nocturna, una sincronización de middleware o una importación CSV, o alguien los vuelve a teclear a partir de un ticket. En cada paso, los códigos de IVA, las reglas de redondeo, los grupos de artículos y los descuentos se trasladan al modelo de otro sistema. Cada traslado es una traducción, no una copia.
- La factura se vuelve a crear. El segundo sistema genera la factura electrónica a partir de los datos que ha recibido, no de la venta en sí. Si se pierde una línea, se reasigna un código fiscal o se aplica un descuento en otro orden, la factura deja de coincidir con el registro fiscal.
- Las correcciones separan los sistemas. Imagina que se anula una venta en el TPV después de la sincronización, o que se emite un abono en el ERP sin tocar el TPV. Los dos sistemas ya no se pondrán de acuerdo sobre lo que se vendió, y nada en esta configuración los vuelve a alinear.
- El auditor ve dos versiones. El diario fiscal registra una versión de la venta y el archivo de facturas registra otra. Conciliarlas transacción a transacción, durante periodos de conservación de hasta diez años, corre a cargo del comerciante. Normalmente se entera en el peor momento posible: durante la auditoría.
Hay una consecuencia más grave que unos registros que no cuadran: la misma venta, gravada dos veces.
En los sistemas de IVA de la UE, el impuesto que figura en un documento emitido se debe, por lo general, a Hacienda. Si el TPV emite un ticket con IVA y un segundo sistema emite más tarde una factura completa por la misma venta, sin que ambos estén vinculados como una sola operación, el comerciante corre el riesgo de deber ese IVA dos veces hasta que se detecte y se corrija el duplicado. Alemania lo establece de forma explícita en el § 14c UStG: el IVA repercutido de forma incorrecta o adicional se debe, sin más. Lo que empieza como un hueco en el proceso termina como una deuda tributaria.
Nada de esto es un caso aislado. Es el día a día de la configuración con dos sistemas, y todas las herramientas de facturación electrónica de back office están construidas en torno a ella.
Por qué la factura debe estar donde se produce la venta
La alternativa integrada es sencilla. La misma capa en la nube que firma la transacción para la fiscalización emite también la factura electrónica, con los datos reales de la transacción en el momento de la venta.
Tres escenas cotidianas muestran la diferencia:
La cena de empresa. Un cliente paga una cena de equipo muy por encima del límite de la factura simplificada.
- Integrado: la factura electrónica se emite en la mesa o llega al correo del cliente segundos después. Se genera a partir de la transacción firmada y está vinculada al ticket, así que la deducción del gasto queda asegurada desde el primer día.
- Desconectado: semanas después, el cliente escribe un correo pidiendo la factura. Alguien reconstruye la cena en el software de contabilidad a partir de una foto del ticket. El restaurante ha emitido ahora dos documentos con IVA por una sola comida. Si no están vinculados como una sola operación, el restaurante podría deber ese IVA dos veces. Es un riesgo fiscal, no solo un problema de servicio.
El mostrador profesional. Un comprador profesional da su NIF-IVA en la caja de una tienda.
- Integrado: la caja que imprime el ticket emite también la factura electrónica, y el sistema de contabilidad de proveedores del comprador la procesa automáticamente.
- Desconectado: la venta llega al ERP con la exportación nocturna. Allí, un código fiscal reasignado y una regla de redondeo distinta generan una factura que ya no coincide al céntimo con el registro fiscal. Nadie se da cuenta hasta que un auditor compara los dos sistemas.
El check-out del hotel. Un huésped de empresa deja el hotel.
- Integrado: la recepción emite en el momento la factura electrónica de toda la estancia. El turista que va detrás en la cola recibe simplemente un ticket. Es el mismo flujo, con una sola pregunta.
- Desconectado: el sistema de gestión hotelera sincroniza la cuenta con finanzas durante la noche. A la mañana siguiente, finanzas ajusta la tarifa de empresa, así que la factura que por fin se envía ya no coincide con los registros de recepción.
En todos los casos, los datos nacen en el TPV. Llevar la factura a un segundo sistema significa reconstruir esos datos en otro sitio, con todo lo que falla cuando una sincronización, un mapeo o una persona reconstruye los datos en lugar de reutilizarlos.
Integrado o desconectado: la comparación
| Criterio | Integrado (en el TPV a través de la nube) | Desconectado (configuración de back office) |
|---|---|---|
| Precisión de los datos | Factura generada a partir de la transacción real: mismas líneas, mismo desglose de IVA, un único sistema de referencia | Traducida al modelo de datos de otro sistema y las traducciones se desvían: códigos fiscales, redondeo y estructura de líneas dejan de coincidir poco a poco con el registro fiscal |
| Pista de auditoría | Firma fiscal, ticket y factura XML vinculados en un solo sistema y archivados conforme a la normativa | Dos pistas de auditoría en dos bases de datos que hay que conciliar transacción a transacción |
| Riesgo de doble IVA | Una cadena de documentos vinculada por venta: ticket y factura hacen referencia a la misma operación | Ticket más una factura posterior no vinculada por la misma venta: el IVA que figura dos veces puede deberse dos veces (en Alemania, § 14c UStG) hasta que se corrija |
| Deducción del IVA del comprador | Factura electrónica conforme en la caja o segundos después | El comprador persigue la factura durante semanas y a menudo nunca llega |
| Carga para el personal | Una pregunta en la caja, sin un segundo paso que recordar | Detectar el caso B2B, anotar los datos en papel y pasarlos al back office |
| Preparación para la comunicación de datos en tiempo real | La capa en la nube ya está en el flujo de la transacción: la comunicación de datos se añade sin tocar el TPV | No puede comunicar los datos en el momento de la transacción por diseño; habrá que reconstruirla cuando llegue la obligación de comunicar |
| Escalado a varios mercados | Una integración cubre XRechnung, ZUGFeRD, Factur-X, FatturaPA, Peppol y otros regímenes | Los formatos y canales de cada país se gestionan por separado en cada herramienta de back office |
Una API, un proveedor: lo que ahorra la consolidación
En el fondo, la fiscalización y la factura electrónica resuelven el mismo tipo de problema. Ambas toman una transacción, la convierten en un formato exigido por ley, la transmiten y la conservan durante años de forma auditable.
Si las gestionas como dos sistemas separados, duplicas cada capa:
- dos modelos de datos que mantener sincronizados
- dos configuraciones de autenticación y estructuras organizativas
- dos pistas de auditoría que conciliar
- dos proveedores y colas de soporte que coordinar
- dos conjuntos de cambios normativos que seguir en cada país
En el modelo integrado, la factura electrónica funciona sobre lo que ya tienes para la fiscalización: los mismos datos de transacción, la autenticación, la estructura organizativa, el diario inalterable, el archivo y el contrato de soporte. Dos obligaciones, una integración. Añadir la segunda obligación cuesta mucho menos, y añadir el siguiente país, también.
Llega ViDA, y acerca el cumplimiento a la venta
La razón de más peso para acertar con esta arquitectura es lo que viene después. El paquete europeo VAT in the Digital Age (ViDA) hace obligatorios los requisitos de comunicación digital de datos para las operaciones transfronterizas a partir de 2030, y los Estados miembros añaden encima sus propios regímenes nacionales en tiempo real.
La dirección es clara: la comunicación de datos se acerca cada vez más a la transacción. Una herramienta de back office que recibe los datos días después de la venta solo puede seguir el ritmo acortando su sincronización, y cada sincronización es otro punto en el que los dos registros pueden separarse. Cuando el plazo de comunicación se reduzca, la configuración desconectada no necesitará una actualización. Habrá que reconstruirla.
Una capa en la nube integrada ya está en el flujo de la transacción. Hoy firma la transacción y, mañana, añadir un paso de comunicación de datos amplía ese mismo flujo sin volver a tocar la integración del TPV. Es la misma apuesta de arquitectura que decidió la última ola de cumplimiento: la fiscalización en la nube desplazó al hardware precisamente porque una plataforma remota y versionada absorbe los cambios normativos en nombre de cada caja conectada.
Dónde sigue teniendo sentido el modelo desconectado
Hoy la factura electrónica integrada no es una obligación legal, y el modelo desconectado sigue teniendo sentido en algunos casos:
- Los tickets pequeños siguen siendo sencillos. Por debajo del límite de la factura simplificada (250 € en Alemania), basta con un ticket. Pero las ventas por encima de ese límite son justo las transacciones B2B que conllevan riesgo en auditorías y de doble IVA.
- Los plazos son escalonados. En varios mercados, emitir facturas electrónicas desde el TPV seguirá siendo opcional durante uno o dos años. Pero construir la integración lleva tiempo, y los proveedores que empiecen ahora no tendrán que hacerlo con prisas en el último año.
El modelo desconectado es legal, pero sale caro de formas que no aparecen en la lista de precios: trabajo de conciliación, fricción en las auditorías, riesgo de doble IVA, compradores frustrados, desarrollo duplicado y una reconstrucción cuando la comunicación de datos se acerque a la venta antes de 2030.
Puntos clave
- Una sola venta B2B en el TPV puede estar sujeta tanto a la fiscalización como a la factura electrónica, así que repartirlas en dos sistemas crea dos registros de una misma transacción.
- Si un ticket y una factura separada no están vinculados como una sola operación, el mismo IVA puede deberse dos veces. En Alemania, lo establece el § 14c UStG.
- Gestionar ambas obligaciones con una sola API permite compartir autenticación, pista de auditoría y archivo, así que añadir el siguiente país cuesta menos.
- ViDA acerca la comunicación del IVA a la transacción de aquí a 2030. Una capa en la nube que ya está en el flujo de la transacción puede añadir la comunicación de datos sin reconstruir nada.
Qué aporta fiskaly
fiskaly crea infraestructura en la nube para el cumplimiento del IVA pensada justo para esta situación. Nuestra API de facturación electrónica fiskaly E-INVOICE funciona en la misma plataforma que nuestros productos de fiscalización, así que ambas obligaciones comparten una autenticación, una estructura organizativa y una pista de auditoría. Los formatos EN 16931, el acceso a Peppol y el archivo conforme quedan cubiertos con una sola integración.
