R&D LAB Método En uso Construido para nuestra propia contabilidad
Belegt
Facturación electrónica ZUGFeRD, autoalojada
Desde 2025 una factura alemana es un archivo que una máquina debe leer. Belegt la genera internamente: primero el XML, luego el PDF, en hardware propio.
- PDF/A-3bsalida con un factur-x.xml incrustado
- 20códigos de regla comprobados sin conexión, en casa
- 4pasos del asistente antes del archivo
- 0datos de factura que salen de casa
Todos los datos de este artículo son datos de demostración inventados. La base de datos de trabajo no se abrió para las capturas.
Por qué se publica
Vendemos software y automatización. Belegt es la prueba de ello en un ejemplo incómodo: una tarea regulada, un formato fijo, plazos reales, datos propios. La herramienta funciona en nuestra propia operación, no en una demostración. Si quiere saber cómo recortamos una aplicación de negocio, dónde fijamos las reglas en el código y dónde dejamos la decisión a una persona, aquí lo ve sobre nuestra propia contabilidad.
Desde el 1 de enero de 2025, las empresas en Alemania deben poder recibir facturas electrónicas en el ámbito B2B; la obligación de emitirlas llega de forma escalonada hasta 2028. Un PDF adjunto a un correo ya no basta. Lo que se exige es un conjunto de datos estructurado según EN 16931, en la práctica ZUGFeRD o Factur-X. Belegt es nuestra propia respuesta, construida porque la necesitábamos.
La decisión
El XML es el documento, el PDF es la vista
Quien construye una factura electrónica por primera vez empieza por el PDF. Ese es el error que sale caro más tarde. Un documento ZUGFeRD es un PDF/A-3 con un archivo llamado factur-x.xml adjunto, y cuando ambos no coinciden, un sistema contable se atiene al adjunto. Así que invertimos el orden: Belegt construye primero el conjunto de datos, genera el XML a partir de él y representa el PDF como su vista.
Esta única decisión arrastra todo lo demás. Como el XML es el documento, la comprobación debe ocurrir antes de generar nada, no después. Como es el documento, es lo que se guarda y se resume con un hash al cerrar la factura, con el PDF al lado. Y como es el documento, el diseño termina donde tocaría la legibilidad para la máquina.
La segunda razón para construirlo nosotros fue menos elegante. Los datos de facturación son la colección más densa de datos maestros ajenos que guarda una empresa pequeña: direcciones, números fiscales, datos bancarios, nombres de proyectos. Una suscripción facturada por documento se lleva esa colección consigo. Belegt la deja en un archivo en hardware propio; los campos sensibles están ahí cifrados con AES-256-GCM y la clave queda fuera del código fuente.
Lo que deliberadamente no salió de aquí es asesoramiento jurídico. La aplicación comprueba las reglas de negocio de la norma, en la medida en que pueden comprobarse sin red. La certificación jurídica de un documento la hace el validador oficial KoSIT, y aquí nada lo sustituye.
Si el PDF y el XML no coinciden, gana el XML. Por eso se empieza por ahí.
El recorrido de una factura
Cuatro pasos, y solo después un archivo
- 01 Borrador Emisor, cliente, número y periodo, luego las líneas. Los datos maestros y el catálogo de servicios ya están guardados. El número propuesto es aquí solo una vista previa: lee el contador sin moverlo.
- 02 Comprobación Antes de generar nada, un conjunto de reglas recorre los datos: veinte reglas con nombre de EN 16931, del anexo de inversión del sujeto pasivo y de la extensión alemana XRechnung. Lo bloqueante aparece como error con su código de regla, lo consultivo aparte.
- 03 Generar el XML El conjunto de datos comprobado se convierte en una CrossIndustryInvoice con el identificador urn:cen.eu:en16931:2017. En modo XRechnung se añade el identificador KoSIT y el Leitweg-ID pasa de aviso a obligación.
- 04 PDF/A-3b con adjunto El PDF se compone con tipografías incrustadas, se marca como PDF/A-3b y recibe factur-x.xml como adjunto con la relación Alternative. Al cerrar la factura se guardan el conjunto de datos, el XML, el PDF y un SHA-256 del XML.
La comprobación va antes del archivo
La comprobación se ejecuta por completo en la máquina local. Conoce veinte códigos de regla, recalcula los totales a partir de las líneas y separa con rigor lo bloqueante de lo consultivo: un IBAN ausente no detiene un documento B2B, una dirección de comprador incompleta sí.
Lo que no es se indica en la misma vista: una comprobación previa sin Java, no un sustituto del validador oficial KoSIT o Mustang. La certificación jurídica de un documento sigue siendo tarea de esa ejecución externa.
Estructura
Un conjunto de datos, dos lectores
- Datos maestrosCliente, plazo de pago, caso fiscal
- Catálogo de serviciosLíneas con unidad y tarifa
- Serie de numeraciónPrefijo, año, mes, número corriente
- La factura visiblePDF/A-3b, ligado a la marca
- XML incrustadofactur-x.xml según EN 16931
- Exportación contableDATEV y CSV, SKR03 o SKR04
Un solo conjunto de datos produce tanto la página que lee una persona como el registro que lee una máquina. Ambos se guardan juntos al cerrar; el XML además se resume con un hash.
Lo que ocurre tras el envío
La segunda mitad del trabajo sobre una factura empieza cuando ya ha salido. Belegt lleva los pendientes de cobro en una vista propia: días hasta el vencimiento, nivel de reclamación y el importe que añadirían los intereses de demora si saliera un recordatorio.
El nivel de reclamación no sube solo. Es un campo del documento que alguien fija, y el recordatorio es un botón que alguien pulsa. Una herramienta que reclama a los clientes sin intervención es un riesgo y no un alivio en una operación con un puñado de clientes.
Los borradores con fecha están en la misma vista, totalmente preparados. Tampoco salen solos en su fecha: esperan a que alguien los abra y los envíe.
Lo que cambió en 2025
PDF por correo, hasta 2024
- Una imagen de factura. Las cifras son texto dentro de una maquetación.
- La contabilidad las reteclea o deja que un reconocedor adivine.
- Un número cambiado aparece, como pronto, en la conciliación.
- Cada receptor se construye su propia regla para su maquetación.
Factura electrónica EN 16931, desde 2025
- Un conjunto de datos estructurado. Cada campo lleva un código de la norma.
- La contabilidad lo importa; el PDF que va al lado es para personas.
- Las infracciones de las reglas de negocio aparecen antes del envío.
- Un formato para todos los receptores, con una extensión para el sector público.
Lo que está fijado en el código
La aplicación, con datos inventados
Para qué está construido
- Pequeñas empresas de servicios que deben poder recibir desde 2025 y emitir antes de 2028, sin pagar por documento.
- Operaciones con pocos clientes pero recurrentes: cuotas de mantenimiento y peticiones de proyecto pasan por el mismo catálogo.
- Servicios transfronterizos dentro de la UE, donde el caso fiscal depende de la ficha del cliente y no de la memoria de alguien.
- Quien no quiera que sus datos de clientes y bancarios estén en la base de datos de un tercero.
- Como plantilla: la misma construcción para otro trámite regulado dentro de su propia operación.
“¡Qué ventajas ofrece al comerciante la contabilidad por partida doble! Es uno de los inventos más bellos del espíritu humano.”
Por qué se publica
Lo que esto significa para su proyecto
Más del laboratorio
Método Event Scout Un modelo de lenguaje lee las páginas de eventos; todo lo demás es código fijo. Queda una lista breve de dónde merece la pena un día presencial. 
Investigación aplicada Vellum Bordes, perspectiva, luz y texto se calculan en el teléfono. Un documento solo sale del dispositivo cuando alguien lo envía. 
Diseño computacional Atlas EV1 Doce capítulos desmontan un coche eléctrico, hasta una sola celda. Sin archivos de modelo ni texturas: 327 piezas de una tabla de medidas. ¿Tiene un trámite regulado que alguien mantiene a mano? Para eso existe un piloto.
Contactar