Software de facturación para agricultura compatible con Verifactu: cómo elegir

Última revisión normativa: 13 de junio de 2026. El calendario de Verifactu es el vigente tras el RD-ley 15/2025 (BOE 3/12/2025). Los plazos de la factura electrónica B2B dependen de la Orden Ministerial de la solución pública, pendiente de publicación en el BOE; las fechas de 2027-2028 que se citan son las del proyecto en audiencia y no son definitivas hasta ese BOE. Verifica siempre contra la sede de la AEAT y el BOE antes de tomar decisiones.

---

TL;DR — Lo que necesitas saber antes de contratar

• Verifactu es obligatorio desde el 1/1/2027 (personas jurídicas con Impuesto sobre Sociedades) y desde el 1/7/2027 (resto, incluidos autónomos agrarios en estimación directa). Los productores de software debían tener sus productos adaptados desde el 29/7/2025.
• Un software agrario tiene que cumplir los mismos requisitos técnicos que cualquier otro sistema informático de facturación (SIF): hash SHA-256 encadenado con el orden exacto de campos, registros XML de alta y anulación, QR ISO/IEC 18004 de 30-40 mm en nivel M y remisión SOAP a la AEAT.
• Además, tiene que cubrir las particularidades del sector: recibo de compensación REAGP, encaje con el IRPF (modelos 131/130) y, si el software incluye cuaderno de explotación, alimentación al SIEX.
• La AEAT no homologa software: es el productor quien firma la declaración responsable por cada versión. Tú, como usuario, también puedes ser sancionado si usas un sistema no conforme (hasta 50.000 € por ejercicio, artículo 201 bis de la LGT).

---

Índice

1. Por qué Verifactu afecta al agricultor de forma diferente
2. El checklist técnico obligatorio: lo que debe cumplir cualquier SIF
3. El checklist agro: lo que un ERP genérico probablemente no tiene
4. Encaje fiscal: IRPF (modelos 131 y 130) y SIEX
5. Tabla comparativa de criterios para elegir
6. Qué ofrece Campodato en este ámbito
7. Preguntas frecuentes (FAQ)
8. Fuentes oficiales

---

1. Por qué Verifactu afecta al agricultor de forma diferente {#1-por-que-verifactu-afecta-al-agricultor}

La obligación de Verifactu nace del artículo 29.2.j de la Ley General Tributaria (añadido por la Ley 11/2021) y se desarrolla en el RD 1007/2023 (RRSIF) y la Orden HAC/1177/2024. Afecta a todo obligado tributario que lleve contabilidad con actividad económica: personas físicas en IRPF con actividad económica, personas jurídicas con Impuesto sobre Sociedades, y sujetos con Impuesto sobre la Renta de No Residentes con establecimiento permanente.

El agricultor tiene dos situaciones bien distintas según su régimen:

Agricultor en régimen general o estimación directa. Emite facturas con IVA, es obligado tributario y necesita un SIF conforme. A partir del 1/7/2027, su programa de facturación tiene que ser Verifactu o estar preparado para serlo.

Agricultor en REAGP (Régimen Especial de la Agricultura, Ganadería y Pesca). Conforme al RD 1007/2023 y su referencia al artículo 134 bis de la LIVA, el agricultor en REAGP no repercute IVA en su actividad agraria y está exento de Verifactu en esa actividad. Sin embargo, cuando el comprador en régimen general le extiende un recibo de compensación (autofactura), ese recibo sí genera un registro de alta en la cadena del comprador. Un software agrario tiene que modelar esta diferencia correctamente: no basta con activar Verifactu para todos; hay que detectar el régimen y enrutar cada operación al tratamiento que le corresponde.

Cooperativas y gestorías que facturan por sus socios. Son el caso más exigente: un mismo sistema gestiona varios NIF. El RD 1007/2023 exige que la cadena de hash sea independiente por cada NIF emisor. Un SIF que encadene por centro de facturación en lugar de por NIF genera un error de cumplimiento silencioso que solo aflora en una inspección.

---

2. El checklist técnico obligatorio: lo que debe cumplir cualquier SIF {#2-checklist-tecnico}

Los requisitos que siguen son los establecidos por el RD 1007/2023 (artículos 8 a 16) y la Orden HAC/1177/2024 (artículos 7 a 21, más los documentos técnicos AEAT de huella v0.1.2, servicios web v1.0.3 y QR v0.4.7). Antes de firmar con un proveedor, pide que te confirme punto por punto.

2.1. Encadenamiento SHA-256 con el orden oficial de campos

El SIF debe calcular la huella (hash) de cada registro usando el algoritmo SHA-256, con el resultado en hexadecimal de 64 caracteres en mayúsculas. El orden de concatenación no es libre: el artículo 12 del RD 1007/2023 y el documento técnico AEAT "huella" v0.1.2 fijan exactamente qué campos se encadenan y en qué posición.

Para el registro de alta, el orden es: IDEmisorFactura & NumSerieFactura & FechaExpedicionFactura & TipoFactura & CuotaTotal & ImporteTotal & Huella(anterior) & FechaHoraHusoGenRegistro

Para el registro de anulación: IDEmisorFacturaAnulada & NumSerieFacturaAnulada & FechaExpedicionFacturaAnulada & Huella(anterior) & FechaHoraHusoGenRegistro

La cadena se forma con pares campo=valor unidos por &, codificada en UTF-8 antes de aplicar SHA-256. El primer registro de cada NIF lleva Huella= vacía. La huella no se incluye en el QR (a diferencia del sistema TicketBAI de los territorios forales).

Pregunta al proveedor: «¿Puedo ver el código o una demostración del orden de concatenación SHA-256?». Si no puede mostrarlo, hay un riesgo real.

2.2. Registros XML de alta y anulación conforme al artículo 10

Cada factura genera un registro de alta en XML UTF-8 con el contenido mínimo del artículo 10 del RD 1007/2023:

• NIF y nombre del obligado tributario.
• NIF y nombre del destinatario (cuando sea obligatorio).
• Número y serie de la factura.
• Fecha de expedición.
• Tipo de factura: F1 (completa), F2 (simplificada), F3 (sustitución de simplificadas), R1-R4 (rectificativas de errores, concurso, créditos incobrables, otras) y R5 (rectificativa de simplificada).
• Descripción de la operación.
• Desglose: base imponible, tipo, cuota; recargo de equivalencia; exentos y no sujetos con su causa.
• Importe total en euros.
• Datos de encadenamiento (serie y número del registro anterior y parte de su huella).
• Código del sistema y datos del productor.
• Fecha y hora de generación (hasta el segundo).

Cuando se anula o corrige una factura, el alta nunca se modifica: se genera un nuevo registro de anulación encadenado. El sistema es append-only; el artículo 8 del RD 1007/2023 prohíbe cualquier alteración retrospectiva.

2.3. Código QR ISO/IEC 18004 (30-40 mm, nivel M)

El QR es obligatorio en todas las facturas (completas y simplificadas) emitidas por un SIF, sea en modalidad Verifactu o no. Las especificaciones las fija la Orden HAC/1177/2024 (arts. 20-21) y el documento técnico AEAT "QR" v0.4.7:

• Estándar: ISO/IEC 18004.
• Tamaño: entre 30×30 mm y 40×40 mm.
• Nivel de corrección de errores: M.
• Ubicación: primera página, visible.
• Contenido: URL del servicio de cotejo AEAT + NIF del obligado + serie y número de factura + fecha de expedición + importe total.

Un QR más pequeño, con nivel L o H, o ubicado en otra página, es incumplimiento. Verifica que el proveedor lo genera según estas dimensiones y no simplemente un código QR genérico.

2.4. Remisión SOAP a la AEAT en modalidad Verifactu

La modalidad Verifactu (artículos 15 y 16 del RD 1007/2023) consiste en remitir todos los registros a la AEAT de forma continua, segura, automática e instantánea. A cambio, el sistema no necesita firmar electrónicamente cada registro ni mantener un registro de eventos completo, lo que simplifica la operativa.

La remisión usa el servicio web SOAP de la AEAT: servicio SistemaFacturacion, binding VerifactuSOAP, operación RegFactuSistemaFacturacion. Los lotes pueden contener hasta 1.000 registros del mismo obligado. El tiempo de espera inicial es de 60 segundos. La respuesta de la AEAT incluye un CSV y tres estados posibles: Correcto, AceptadoConErrores e Incorrecto.

La AEAT recalcula la huella en recepción; si no coincide, marca el registro como Incorrecto. El software debe gestionar los reintentos sin duplicar registros y sin romper la cadena.

Los endpoints exactos de preentorno y producción, así como los XSD y el WSDL, deben verificarse contra la sede electrónica de la AEAT antes de implementar (los documentos técnicos indicados en el RRSIF son: servicios web v1.0.3, verificar versión vigente).

2.5. Declaración responsable del productor (la AEAT no homologa)

Este punto es uno de los más malentendidos del mercado. La AEAT no certifica ni homologa ningún software. Lo que el artículo 13 del RD 1007/2023 exige es que el productor del software emita una declaración responsable —por versión del sistema— en la que certifica que cumple con todos los requisitos del RRSIF: nombre y código del sistema, versión, componentes, si es solo Verifactu o también admite el modo no verificable, si gestiona múltiples obligados, y datos identificativos del productor.

Esta declaración tiene que ser visible en el propio sistema. El productor asume responsabilidad penal y tributaria. La sanción por fabricar o comercializar software de doble uso (que permita alterar o no registrar facturas) es de hasta 150.000 € por ejercicio (artículo 201 bis LGT). El usuario que usa ese software puede ser sancionado con hasta 50.000 € por ejercicio. Antes de contratar, pide ver la declaración responsable y la versión a la que corresponde.

2.6. Numeración consecutiva sin huecos

El RD 1007/2023 exige que la numeración sea consecutiva dentro de cada serie, sin huecos. No puede haber saltos entre números, ni facturas eliminadas del ledger. Si el sistema permite borrar una factura «pendiente» que ya ha generado un registro de alta, ese borrado debe reflejarse como un registro de anulación encadenado, nunca como un DELETE de base de datos.

Si migras desde otro software, la continuidad de la numeración heredada es crítica: interrumpir la serie o reiniciar el encadenamiento puede crear inconsistencias que la AEAT detecta al recalcular las huellas.

---

3. El checklist agro: lo que un ERP genérico probablemente no tiene {#3-checklist-agro}

Un programa de facturación de uso general puede cumplir perfectamente el checklist técnico anterior y aun así fallar en los casos que afectan al agricultor. Estos son los puntos que debes verificar de forma específica.

3.1. Recibo de compensación REAGP con registro de alta en la cadena del comprador

El REAGP (Régimen Especial de la Agricultura, Ganadería y Pesca, artículos 124-134 bis LIVA y RD 1624/1992) establece que el agricultor no repercute IVA. Cuando vende su producción a una empresa en régimen general, esa empresa expide un recibo de compensación (autofactura) en nombre propio, con el consentimiento del agricultor.

Las tasas de compensación son del 12 % para productos agrícolas, forestales y servicios accesorios y del 10,5 % para productos ganaderos y pesqueros (artículo 130 LIVA; estas tasas son las vigentes a la fecha de redacción, verificar con la norma vigente en cada campaña).

Ese recibo de compensación es, desde el punto de vista del RRSIF, una factura expedida por el comprador. Si el comprador usa un SIF, el recibo genera un registro de alta en la cadena de hash del comprador, no del agricultor. El software tiene que modelar este flujo: el agricultoras no encadena; quien encadena es el comprador.

Verifica que el software gestione:

• Detección automática del régimen REAGP del proveedor.
• Generación del recibo de compensación con serie propia diferenciada.
• Cálculo correcto del porcentaje (12 % o 10,5 %).
• Registro de alta en la cadena del comprador (no del agricultor).
• Vinculación al albarán de entrega de cosecha.
• Libro registro de recibos de compensación.
• Bloqueo de la emisión de facturas ordinarias por el agricultor REAGP salvo en las excepciones legales (inmuebles, bienes de inversión, importaciones, adquisiciones intracomunitarias).

3.2. Motor de exclusión mutua: Verifactu, SII y regímenes forales

No todos los obligados tributarios aplican Verifactu. El sistema debe detectar y gestionar correctamente tres situaciones de exclusión:

• Obligados en SII (Suministro Inmediato de Información, RD 596/2016): quienes presentan sus libros de IVA en la sede de la AEAT en tiempo real quedan exentos de Verifactu. El software no debe aplicarles el encadenamiento Verifactu.
• Territorios forales: el País Vasco usa TicketBAI/Batuz y Navarra tiene su propio sistema NaTicket (sin calendario oficial publicado a la fecha de redacción). Un SIF que aplique Verifactu en estos territorios incumple la normativa foral.
• REAGP y régimen simplificado: exentos de Verifactu en sus términos.

Un ERP genérico suele ignorar estas excepciones porque no las necesita su público general. Para el agricultor que trabaja en distintos territorios o que tiene socios en el País Vasco, es un riesgo real.

3.3. Encadenamiento correcto por NIF, no por centro de facturación

En una cooperativa que factura por sus socios, una gestoría que gestiona varias explotaciones o una sociedad agraria con varias empresas, un mismo SIF gestiona múltiples NIF. El RD 1007/2023 exige que cada NIF tenga su cadena de hash independiente: los registros de un NIF no pueden aparecer en la cadena de otro.

Un error habitual en los ERP de uso general es encadenar por «empresa» o por «centro de facturación» en lugar de por NIF. Este error no produce un fallo visible en el día a día, pero la AEAT, al recalcular las huellas, detecta que las cadenas están cruzadas.

Pregunta al proveedor cómo gestiona el encadenamiento cuando hay varios NIF emisores en el mismo sistema.

---

4. Encaje fiscal: IRPF (modelos 131 y 130) y SIEX {#4-encaje-fiscal-irpf-siex}

La facturación no vive sola. Para el agricultor, el flujo ideal es que los datos de producción y las facturas alimenten directamente los modelos fiscales y el cuaderno de explotación sin que haya que introducir la información dos veces.

4.1. Modelo 131 (estimación objetiva por módulos)

El modelo 131 es el pago fraccionado trimestral del IRPF para agricultores en estimación objetiva. El cálculo se basa en los índices de rendimiento agrario aplicables a los ingresos del trimestre, con una reducción del 25 % (disposición adicional 6.ª de la LIRPF, aunque los importes y condiciones exactos de cada ejercicio los fija la Orden anual de módulos; verificar la Orden vigente antes de cada campaña).

Para calcularlo correctamente, el software necesita los ingresos por ventas del trimestre, incluidas subvenciones corrientes, y debe distinguirlas de las subvenciones de capital, que tienen tratamiento distinto. También tiene que vigilar el umbral de exclusión de 250.000 € de ingresos anuales a partir del cual el agricultor no puede seguir en estimación objetiva.

Si el software tiene cuaderno de explotación, los kilogramos cosechados por parcela son la base natural para calcular los ingresos estimados antes de cerrar el trimestre. Un sistema que no conecta ambos módulos obliga al agricultor o a su gestoría a hacer la conciliación manualmente.

4.2. Modelo 130 (estimación directa simplificada)

El modelo 130 aplica a agricultores en estimación directa simplificada: el cálculo es el 20 % del rendimiento neto (ingresos menos gastos deducibles del trimestre), y el software tiene que precuadrar las casillas a partir de las facturas emitidas y recibidas del periodo.

4.3. Alimentación al cuaderno SIEX

El SIEX (Sistema de Información de Explotaciones Agrarias, creado por el RD 1054/2022) es el registro nacional de explotaciones agrarias. El cuaderno de explotación (CUE) del agricultor alimenta al SIEX a través del IUWS (Interfaz Único de los Servicios Web del FEGA), gestionado autonómicamente.

La conexión entre facturación y cuaderno importa porque los datos de producción y comercialización del CUE deben ser coherentes con las facturas emitidas. Un software que tiene ambos módulos puede cruzar los datos automáticamente. Uno que no los tiene integrados genera una carga de trabajo doble para el agricultor o su asesor.

El CUE completo es voluntario de forma general hasta 2028 para la mayoría de explotaciones (RD 34/2025), pero el registro de fertilización es ya obligatorio desde el 1/1/2026 para las explotaciones no exceptuadas (RD 1051/2022, modificado por RD 840/2024 y RD 934/2025), y el de tratamientos fitosanitarios será obligatorio en formato electrónico desde el 1/1/2027 (RD 1039/2025).

---

5. Tabla comparativa de criterios para elegir {#5-tabla-comparativa}

---

6. Qué ofrece Campodato en este ámbito {#6-campodato}

Campodato es un agro-ERP diseñado específicamente para explotaciones agrarias, gestorías del sector y cooperativas en España. El módulo de facturación está construido desde el diseño como Verifactu nativo, lo que significa que el encadenamiento SHA-256, los registros XML y la remisión SOAP son parte del núcleo de la aplicación, no un complemento externo añadido sobre un sistema genérico.

Las capacidades actuales del módulo, correspondientes a las Olas 1-9 del desarrollo, incluyen:

• Registros de alta, anulación y subsanación encadenados por SHA-256 con el orden exacto de campos del RD 1007/2023.
• Cadena independiente por NIF del obligado tributario, con aislamiento verificable entre NIFs en un mismo sistema.
• QR ISO/IEC 18004 conforme a los requisitos de la Orden HAC/1177/2024, generado en todas las facturas.
• Conector SOAP a la AEAT, con gestión de lotes, reintentos y circuit breaker ante caída de los servicios.
• Motor de exclusión mutua Verifactu / SII / forales por territorio fiscal y régimen.
• Recibo de compensación REAGP con serie propia, cálculo del porcentaje correcto según tipo de producto, registro de alta en la cadena del comprador y vinculación al albarán de cosecha.
• Facturas offline: se crean como borradores no encadenados y se sellan al recuperar conexión, en orden de llegada al servidor, sin huecos ni colisiones de huella.
• Declaración responsable del productor visible en el sistema, con histórico por versión y bloqueo de versiones no conformes.
• Encaje con el módulo de cuaderno SIEX/IUWS para cruzar datos de producción con facturación sin doble captura.

Lo que está previsto pero no está cerrado a la fecha de redacción (no se afirma como disponible):

• Módulo contable completo (diario, mayor, balance): en desarrollo; describir con el proveedor el alcance exacto antes de contratar.
• Conectores forales TicketBAI/Batuz y NaTicket: en roadmap, sin fecha confirmada.
• Conector a la Solución Pública de Facturación Electrónica (SPFE) para B2B: depende de la publicación de la Orden Ministerial en el BOE.

Si tu explotación, gestoría o cooperativa quiere evaluar si Campodato cubre tu caso concreto, solicita una demostración guiada del módulo de facturación.

---

7. Preguntas frecuentes (FAQ) {#7-faq}

¿Cuándo es obligatorio Verifactu para los agricultores?

Para las personas jurídicas (sociedades agrarias, cooperativas con Impuesto sobre Sociedades) la fecha es el 1 de enero de 2027. Para los autónomos agrarios en estimación directa, el 1 de julio de 2027. Estos plazos son los vigentes tras el RD-ley 15/2025 (BOE 3/12/2025). Los agricultores en REAGP están exentos de Verifactu en su actividad agraria ordinaria.

¿La AEAT certifica u homologa los programas de facturación?

No. La AEAT no homologa ningún software. El productor del software emite una declaración responsable por versión en la que certifica que cumple con el RD 1007/2023 y la Orden HAC/1177/2024. Como usuario, si el software que utilizas no es conforme, puedes ser sancionado con hasta 50.000 € por ejercicio (artículo 201 bis LGT). Antes de contratar, pide ver esa declaración responsable.

¿El agricultor en REAGP tiene que usar Verifactu?

No en su actividad agraria ordinaria: el agricultor en REAGP está exento de Verifactu porque no repercute IVA y no emite facturas en su actividad típica. Sin embargo, cuando el agricultor REAGP sí emite factura por excepción legal (venta de inmuebles, bienes de inversión, importaciones o adquisiciones intracomunitarias), esas operaciones sí entran en el ámbito del RRSIF. Por su parte, el comprador en régimen general que expide el recibo de compensación sí debe incluirlo en su propia cadena de hash.

¿Qué diferencia hay entre el QR de Verifactu y el de TicketBAI?

Ambos usan el estándar ISO/IEC 18004, pero el contenido es diferente. El QR de Verifactu no incluye la huella SHA-256 del registro; apunta a la URL del servicio de cotejo de la AEAT con los datos básicos de la factura. El QR de TicketBAI sí incorpora la huella. Un software que afirme ser compatible con ambos sistemas tiene que gestionar los dos formatos según el territorio fiscal del obligado.

¿Un programa de facturación genérico puede usarse en agricultura?

Puede cumplir los requisitos técnicos de Verifactu (hash, QR, SOAP), pero es probable que no cubra las particularidades del sector: recibo de compensación REAGP, encaje con el cuaderno SIEX, modelos 131 y 130 precuadrados o facturación offline desde el campo. La pregunta relevante no es solo «¿es Verifactu?», sino «¿gestiona el REAGP correctamente?» y «¿alimenta el cuaderno de explotación?».

¿Qué pasa si migro de un software a otro antes de 2027?

La migración tiene que preservar la continuidad de la numeración heredada para no romper el encadenamiento desde el primer registro en el nuevo sistema. Si el nuevo software reinicia la serie o cambia el NIF de la cadena, las huellas recalculadas por la AEAT no coincidirán con las del historial. Antes de migrar, comprueba que el nuevo proveedor tiene un proceso documentado de importación que respeta la cadena preexistente.

---

Conclusión: el software correcto ahorra problemas desde el primer día

El calendario de Verifactu no es una amenaza lejana: los proveedores de software debían tener sus productos adaptados desde julio de 2025. Si contratas hoy, tienes tiempo para implantar, formar al equipo y hacer pruebas en el preentorno de la AEAT antes de que la obligatoriedad entre en vigor.

En el sector agrario, el riesgo es doble: por un lado, el cumplimiento técnico del RRSIF (hash, QR, SOAP, declaración responsable); por otro, el encaje con la realidad del campo (REAGP, cuaderno SIEX, modelos fiscales, offline). Un ERP genérico puede resolver el primero y dejar al descubierto el segundo.

Antes de decidir, pide al proveedor que te muestre la declaración responsable por versión, que te explique cómo encadena cuando hay varios NIF y que te enseñe el flujo del recibo de compensación REAGP. Esas tres preguntas filtran la mayoría de los sistemas que no están preparados para el agro.

Si quieres ver cómo Campodato resuelve estos flujos en la práctica, solicita una demostración o consulta el resto de nuestros recursos sobre facturación y Verifactu para explotaciones agrarias.

---

8. Fuentes oficiales {#8-fuentes}

• RD 1007/2023, de 5 de diciembre, por el que se regula el Reglamento de los Sistemas Informáticos de Facturación (RRSIF). BOE-A-2023-24563.
• Orden HAC/1177/2024, de 17 de octubre, por la que se desarrollan las especificaciones técnicas del RRSIF. BOE-A-2024-22125.
• RD-ley 15/2025, de 3 de diciembre, de aplazamiento del calendario Verifactu. BOE-A-2025-25268.
• Ley 11/2021, de 9 de julio, de medidas de prevención y lucha contra el fraude fiscal (añade art. 29.2.j y art. 201 bis LGT).
• Ley 18/2022, de 28 de septiembre, de creación y crecimiento de empresas (Crea y Crece), artículo 12.
• RD 238/2026, de 25 de marzo, por el que se desarrolla la factura electrónica B2B. BOE-A-2026-5962.
• RD 1054/2022, de 27 de diciembre, que crea el SIEX, el REA y el CUE.
• Sede electrónica AEAT — Documentos técnicos Verifactu: huella v0.1.2, servicios web v1.0.3, QR v0.4.7 (verificar versión vigente en sede.agenciatributaria.gob.es).
• Artículo 201 bis LGT (RDLeg 3/2004, texto vigente): régimen sancionador por uso o fabricación de software no conforme.

---

Publicado el 2 de julio de 2026 · Equipo Campodato (Summum Marketing) · Última revisión normativa: 13 de junio de 2026.

---