Los vendedores online generan cada mes una gran cantidad de datos financieros. Amazon, Shopify, eBay y otros canales de venta aportan pedidos, abonos, comisiones y liquidaciones. PayPal, Stripe, Klarna, Mollie o Shopify Payments ofrecen además datos de pagos y de liquidaciones. Los programas de facturación generan las facturas emitidas, mientras que las facturas recibidas, los justificantes de comisiones y los movimientos bancarios suelen estar en otros sistemas.

Si vendes en Alemania o trabajas con una asesoría alemana, estos datos suelen acabar en DATEV, el software de referencia de los asesores fiscales alemanes. Para una asesoría en España, KudTax exporta según el PGC para a3, Sage, Holded o Contasol; este artículo se centra en DATEV.

A primera vista, la tarea parece sencilla: se exportan todos los datos, se escriben en un archivo CSV y después se importan en DATEV. En la práctica, sin embargo, no es la extensión del archivo lo que decide si una exportación DATEV para el comercio online funciona. Lo decisivo es que el archivo cumpla técnicamente el formato DATEV, que la lógica contable sea correcta en cuanto al fondo y que ventas, pagos, facturas y justificantes sigan vinculados entre sí sin ambigüedad.

Una importación puede salir bien técnicamente y, aun así, producir una contabilidad inservible. Las ventas pueden aparecer duplicadas, las liquidaciones agrupadas pueden figurar por error como ingresos, las partidas abiertas pueden quedar sin cobrar, los justificantes pueden no abrirse o las operaciones de IVA extranjero pueden contabilizarse en cuentas equivocadas. A la inversa, una lógica contable correcta puede fallar en la importación si falta un campo obligatorio, si hay un carácter especial no admitido o si la cabecera no coincide con el periodo contable.

Este artículo explica qué debe contener una exportación DATEV para e-commerce conforme a las GoBD (las normas alemanas de contabilidad digital), cómo funcionan los lotes de asientos, los enlaces a justificantes y las partidas abiertas (OPOS) y cómo los vendedores online y las asesorías evitan los errores de importación típicos.

¿Qué es un archivo de exportación DATEV (formato EXTF)?

DATEV no procesa cualquier archivo CSV. El sistema exige una estructura de archivo definida con precisión, el llamado formato DATEV (formato EXTF). Este formato lo especifica DATEV eG y plantea requisitos estrictos sobre las cabeceras, el número de columnas, la longitud de los campos, los formatos numéricos y las estructuras de fecha.

Un archivo DATEV EXTF válido consta de tres partes principales:

Cabecera (header): contiene metadatos como el número de asesor y de cliente, el inicio del ejercicio, el plan de cuentas (SKR03 / SKR04), la divisa (EUR) y el periodo contable.
Encabezados de columna: fijan el orden exacto de los campos estándar de DATEV (importe, indicador debe/haber, cuenta, contrapartida, código BU, fecha del justificante, Belegfeld 1, Belegfeld 2, concepto, etc.).
Líneas de asiento: los asientos propiamente dichos, preparados según las reglas de validación de DATEV.

Si falta la cabecera, si una columna está desplazada o si una fecha se transmite como 2026-07-29 en lugar de 2907, DATEV interrumpe la importación con un mensaje de error.

Requisitos básicos de una exportación DATEV para e-commerce

Una exportación DATEV de calidad para el comercio online tiene que cumplir criterios tanto técnicos como contables:

1. Plan de cuentas correcto y códigos de IVA de DATEV (códigos BU)

El archivo debe usar el plan de cuentas activo del cliente (SKR03, SKR04 o registro multiuso de la asesoría). A cada asiento de ventas hay que asignarle el código de IVA de DATEV adecuado (código BU). Los ejemplos siguientes se refieren a los tipos alemanes:

Tipo general del 19 % en ventas nacionales (BU 3 / SKR03 8400)
Tipo reducido del 7 % en ventas nacionales (BU 2 / SKR03 8300)
Entregas intracomunitarias exentas (BU 11)
Tipos OSS para los países de destino B2C de la UE
Inversión del sujeto pasivo en servicios extranjeros (BU 19 / § 13b UStG, ley alemana del IVA)

2. Belegfeld 1 para la conciliación automática de partidas abiertas

En el e-commerce, Belegfeld 1 (campo de justificante 1) es la clave central para la asignación. Debería contener el identificador único de la transacción, por ejemplo:

Amazon Order-ID (p. ej., 302-1234567-8901234)
Número de pedido de Shopify (p. ej., #10542)
ID de transacción del proveedor de pagos (p. ej., ID de PayPal / Stripe)

El uso sistemático de Belegfeld 1 permite a la automatización OPOS de DATEV conciliar directamente los créditos con clientes con las liquidaciones de los proveedores de pago.

3. Enlaces a justificantes para cumplir las GoBD (justificante digital)

Según las GoBD, cada asiento tiene que poder remitirse a su justificante original. Las exportaciones DATEV modernas contienen enlaces a justificantes (Digitaler Beleg) con el formato de DATEV Unternehmen Online o DATEV Belegtransfer. Cuando el asesor fiscal hace clic en la línea del asiento en DATEV Kanzlei-Rechnungswesen, se abre directamente el PDF de la factura o el informe de liquidación correspondiente.

Contabilidad de partidas abiertas o asiento directo en e-commerce

Hay dos métodos básicos para exportar datos de e-commerce a DATEV:

Método A: asiento directo (sin cuenta de cliente)

Los pedidos se contabilizan directamente de ingresos contra la cuenta puente del proveedor de pagos.

Asiento: cuenta puente (debe) ➔ cuenta de ingresos (haber)
Ventaja: más sencillo, menos líneas de asiento.
Inconveniente: no hay desglose por cliente; los créditos pendientes o las reclamaciones son difíciles de seguir.

Método B: contabilidad de partidas abiertas (OPOS)

Los pedidos se contabilizan contra cuentas de clientes individuales o colectivas y se cancelan al recibir la liquidación.

Asiento 1 (venta): cliente (debe) ➔ cuenta de ingresos (haber)
Asiento 2 (pago): cuenta puente (debe) ➔ cliente (haber)
Ventaja: plenamente conforme a las GoBD; seguimiento completo de las partidas abiertas; identificación sencilla de los pedidos no pagados.
Inconveniente: exige una conciliación precisa mediante Belegfeld 1 para evitar partidas pendientes acumuladas.

Para los vendedores online en crecimiento y para las asesorías, la contabilidad OPOS con conciliación automática mediante Belegfeld 1 es la referencia.

Errores típicos de importación en DATEV y cómo resolverlos

Al importar archivos de e-commerce en DATEV aparecen a menudo mensajes de error. Estas son las causas y soluciones más frecuentes:

Error de importación	Causa	Solución
«Cabecera errónea»	Faltan metadatos, el número de asesor es incorrecto o el formato no está admitido.	Volver a generar el archivo según la especificación oficial de la cabecera DATEV EXTF.
«Fecha del justificante no válida»	La fecha tiene el formato `YYYY-MM-DD` o `DD.MM.YYYY`.	En el lote mensual, DATEV exige el formato `DDMM` (p. ej., `2907` para el 29 de julio).
«Belegfeld 1 demasiado largo»	Belegfeld 1 supera los 36 caracteres (p. ej., identificadores largos de marketplaces).	Acortar correctamente los números de pedido a un máximo de 36 caracteres.
«Código BU no admitido»	El código de IVA no corresponde al tipo de cuenta o al plan de cuentas.	Comparar los códigos BU con los datos maestros del SKR03/SKR04.
«Lote no cuadrado»	La suma del debe no coincide con la suma del haber del lote.	Comprobar que los asientos de la cuenta puente y de comisiones están completos.
«Carácter no admitido en el concepto»	Caracteres especiales, emojis o caracteres de control en el campo de texto.	Limpiar automáticamente los conceptos antes de exportar.

Paso a paso: importar un lote de e-commerce en DATEV

Así importas un lote de asientos de e-commerce en DATEV Kanzlei-Rechnungswesen:

Paso 1: abre DATEV Kanzlei-Rechnungswesen y selecciona el cliente y el ejercicio.
Paso 2: ve a Stapelverarbeitung (procesamiento por lotes) ➔ Importieren ➔ DATEV-Format.
Paso 3: selecciona el archivo EXTF generado por tu interfaz de e-commerce (p. ej., KudTax).
Paso 4: revisa el registro de importación por si hay avisos o advertencias de campos.
Paso 5: haz clic en Importieren e incorpora el lote a la contabilidad financiera.
Paso 6: ejecuta la conciliación OPOS automática para cuadrar los créditos con clientes y las cuentas puente.

Ajustar la exportación DATEV con KudTax durante un mes de prueba

KudTax concilia tus datos de e-commerce con ayuda de la IA, genera a partir de ellos asientos según el SKR03 o el SKR04 y los entrega en formato DATEV EXTF. Para una asesoría en España, KudTax exporta según el PGC para a3, Sage, Holded o Contasol. Lo decisivo es qué datos aportan tus fuentes y qué ajustes se han acordado para el sistema de destino.

En eBay, los pedidos, las comisiones, los reembolsos y las liquidaciones forman parte del alcance confirmado de los datos. En WooCommerce, la importación se hace mediante archivo CSV o XLSX. Entre los proveedores de pago, PayPal y Stripe son ejemplos confirmados. Comprueba las demás fuentes según el alcance que tengan actualmente en el resumen de integraciones.

Fija un mes de prueba con la asesoría. Comparad los datos de origen, las operaciones ya contabilizadas, las referencias de los justificantes y el resultado de la importación. Que haya una referencia en el registro no significa automáticamente que el archivo del justificante esté disponible en el sistema de destino. Aclarad las dudas antes de pasar a la exportación habitual.

Hasta 25 pedidos al mes usas KudTax gratis, y las tarifas superiores puedes probarlas gratis durante un mes: crea tu cuenta. Si prefieres hablar primero de tus fuentes de datos, reserva una demo.

Fuentes oficiales y enlaces complementarios

Nota: este artículo tiene carácter informativo general para asesores fiscales y vendedores online y no constituye asesoramiento jurídico ni fiscal formal.

Exportación DATEV para vendedores online: lotes y errores