Un solo stack de facturación para Polonia, Alemania y España
Si vende en Varsovia, Múnich y Valencia, ya tiene tres máquinas de factura electrónica. El registro compartido, los validadores por mercado, los plazos de archivo y los transportes que no deben mezclarse.
Un solo stack de facturación para Polonia, Alemania y España
Un comercio que factura a un mayorista alemán, a un grupo hotelero español y a un distribuidor polaco no "hace facturación electrónica". Opera tres máquinas legales que comparten un hecho comercial: quién compró qué, por cuánto, en qué divisa, pagadero cómo.
Ponga ese hecho en tres herramientas sin relación y acabará montando una cuarta para conciliarlas. Póngalo en un registro con tres adaptadores.
El registro compartido
Todo mercado necesita el mismo núcleo:
- Identidad legal de vendedor y comprador (nombre, ID fiscal, dirección; en España también la identidad SIF del software)
- Tipo de documento (factura, abono, anticipo, rectificativa)
- Líneas: cantidad, neto, tipo de IVA, exenciones, inversión del sujeto pasivo
- Totales que cuadran aritméticamente con las líneas
- Divisa, fuente y fecha de tipo de cambio si no es la divisa fiscal local
- Medios de pago (IBAN, plazos; en Polonia, más adelante, el número KSeF en el concepto de la transferencia)
- Referencias del comprador (pedido, BT-10, Leitweg-ID, referencias administrativas españolas)
- Fecha de emisión, devengo, vencimiento
Este registro no es un archivo EN 16931. EN 16931 es una proyección. FA(3) es una proyección. Facturae es una proyección. Si solo guarda el XML que envió a KSeF, no puede emitir una XRechnung sin un mapeo inverso con pérdida.
Los validadores son por mercado, no opcionales
| Mercado | Validador | Fallos que parecen "la factura se envió" |
|---|---|---|
| Polonia | Esquema KSeF + reglas de negocio, luego el nodo en vivo | Códigos de error en sesión; sin número KSeF, no hay factura |
| Alemania | Esquema más reglas de negocio KoSIT / EN 16931 | BT-10 vacío, descuadre aritmético, perfil ZUGFeRD equivocado. El receptor rechaza o la aparca. |
| España | Facturae / UBL / CII, firma, hash y QR Verifactu si aplica SIF | PDF sin firmar, QR ausente, rechazo de plataforma, estado de 4 días incumplido |
Ejecute el validador antes del transporte. Un envío alemán de ZUGFeRD Minimum (no EN 16931) es un correo exitoso de algo que no es una factura. Un envío español sin firma es un PDF con ambición.
Los transportes no deben mezclarse
Los modos offline de KSeF son un diseño legal polaco. No son una forma de "encolar facturas alemanas cuando falla SMTP". Un fallo de correo alemán es un reintento de canal, no una liquidación offline. El modo de incidencia Verifactu es una regla del SIF con una puesta al día posterior. TicketBAI sigue asumiendo conectividad y no ofrece un modo offline presentable.
La configuración vive en el comprador: Polonia, siempre KSeF para las facturas de IVA en el ámbito; Alemania, correo o Peppol según el ID Peppol; España, la plataforma acreditada en la que está la contraparte, con interconexión. El operador no debería elegir un canal desde un desplegable global.
Archivar no es "guardar el PDF"
| Mercado | Qué debe permanecer sin cambios | Plazo de conservación actual |
|---|---|---|
| Polonia | FA(3) y el UPO, firma intacta | 10 años (el historial de sesiones de KSeF no es su única copia) |
| Alemania | El registro estructurado (XML, o PDF/A-3 con XML incrustado). Aplanar un ZUGFeRD a un PDF simple destruye el cumplimiento GoBD. | 10 años. El plan de acción del BMF de 16 de julio de 2026 propone 15 años (medida 19) y almacenamiento espejo para algunos casos de terceros países (medida 20). Diseñe para 15. |
| España | Factura electrónica firmada, cadena Verifactu, archivo TicketBAI donde aplique | Siga las reglas de la AEAT / provinciales; no conserve solo el PDF del ticket |
Un almacén de objetos con etiquetas legales por documento sale más barato que tres "productos de archivo". La exportación debe producir los bytes originales, no una visualización regenerada.
Estado y caja son específicos de cada mercado
Polonia: recepción presumida en la asignación de KSeF, UPO como prueba de entrega, número KSeF en el concepto de la transferencia desde el 1 de enero de 2027 para casar.
Alemania: sin flujo estatal de pagos. La antigüedad de saldos sale de sus libros y del banco. El recobro es civil (Mahnung, BGB § 286 / § 288).
España: aceptación, rechazo, fecha efectiva de pago, 4 días naturales. La antigüedad de saldos debería mostrar el estado legal junto a los días de retraso.
Un único DSO para PL, DE y ES es una métrica de vanidad de dirección, salvo que también lo parta por mercado. Las esperas de 80 días de las pymes españolas y los retrasos medios de 53 días en Polonia (Coface Payment Survey 2026) son enfermedades distintas. Necesitan expedientes de evidencias distintos.
Orden de construcción para un operador de varios mercados
- Factura canónica y datos maestros del comprador (IDs fiscales, IDs Peppol, buzones de factura, pertenencia a plataforma, Leitweg-ID).
- Adaptador polaco si ya emite en KSeF. Le enseña que el artefacto legal no es el PDF.
- Validador alemán y doble sintaxis antes del 1 de enero de 2027 si su Gesamtumsatz va a superar 800.000 EUR en 2026.
- SIF / Verifactu español si cobra en caja o emite tickets en España; conector Crea y Crece según el calendario de la orden ministerial.
- Casación de cobros: remesa SEPA hoy, números KSeF en 2027, el estado de fecha de pago español como campo de pleno derecho.
Plandesk es ese stack para comercios y restaurantes que ya operan TPV y B2B sobre una sola base de datos. La factura es una fila. Los adaptadores no son un complemento de PDF.
Este material es información de carácter general y no constituye asesoramiento legal ni fiscal. Para una situación concreta, verifique la normativa vigente o consulte a un asesor cualificado.