Libros de IVA y anexos: qué tiene que generar tu sistema

Equipo Divergentes Media

·

·

3 minutos de lectura
Portada del artículo: Libros de IVA y anexos: qué tiene que generar tu sistema

Emitir el documento fiscal es la mitad visible del trabajo. La otra mitad —los libros y los anexos que hay que presentar— es la que se queda fuera de casi todos los presupuestos y la que acaba haciendo alguien a mano todos los meses.

Si eso pasa, el ahorro del proyecto se evapora. Este artículo explica qué tiene que salir del sistema y cómo comprobarlo antes de firmar.

Por qué no salen solos

Un libro de IVA no es una lista de facturas. Es la misma información agrupada de otra manera, con reglas propias: qué operaciones entran, cómo se clasifican, qué se suma y qué se excluye.

Esas reglas las pone la administración tributaria de cada país y cambian. Por eso ningún ERP internacional los trae de fábrica: forman parte de la localización, igual que la facturación electrónica.

Qué debe generar el sistema

Sin entrar en la normativa de cada país, que conviene confirmar con tu contador, todo sistema que emita documentos fiscales debería poder sacar:

  • Libro de ventas, separando los tipos de documento y de operación que tu país distingue.
  • Libro de compras, con el crédito fiscal correctamente identificado.
  • Resumen por periodo que cuadre con lo que vas a declarar.
  • Anexos en el formato exacto que pide la administración, no en un Excel que alguien reformatea.
  • Retenciones y percepciones, si eres agente.
  • Operaciones excluidas o exentas, clasificadas donde toque.

Ese «en el formato exacto» es la parte que más se subestima. Un informe que contiene los datos correctos pero en otra estructura obliga igualmente a trabajo manual, y el trabajo manual introduce errores justo donde más caros salen.

La prueba que hay que exigir

Es la misma que recomendamos para la contabilidad entera y vale el doble aquí:

Coge un periodo que ya hayas presentado, cárgalo en el sistema y genera los libros y anexos. Compara línea por línea con lo que entregaste.

Si cuadran, tienes la certeza que ninguna demostración da. Si no cuadran, has encontrado el problema con un periodo cerrado y sin plazo encima, que es exactamente cuando quieres encontrarlo.

Haz esta prueba antes del pago final del proyecto. Es el momento en que tienes la atención de todo el mundo.

Lo que descuadra casi siempre

Cuando no cuadra, el motivo suele ser uno de estos cuatro, y ninguno es un fallo del programa:

  • Impuestos mal configurados en algunos artículos. Un artículo con el impuesto equivocado arrastra el error a todos sus documentos.
  • Documentos anulados que siguen contando, o al revés. La anulación tiene su propio tratamiento y hay que comprobarlo.
  • Operaciones con tratamiento especial —exportaciones, exentos, sujetos excluidos— clasificadas como ventas normales.
  • Fechas. La fecha del documento, la de la operación y la del asiento pueden ser distintas, y el libro usa una concreta.

Los cuatro se arreglan configurando, no programando. Pero hay que encontrarlos, y solo se encuentran comparando contra un periodo real.

Quién hace esta comprobación

Tu contador, no el consultor informático. Es el único que sabe qué debería salir.

Y conviene que participe desde el principio, cuando se configura el plan de cuentas y los impuestos, no al final cuando ya hay que rehacer cosas. Esa reunión de una hora al arrancar el proyecto es la más rentable de todas.

Si estás evaluando proveedores, la capacidad de generar estos informes es una de las doce preguntas que hay que hacer antes de firmar.

Quién escribe esto

El equipo de Divergentes Media, consultora salvadoreña de software libre. Implantamos ERP, facturación electrónica y sistemas de gestión para empresas de Centroamérica, y escribimos aquí lo que aprendemos haciéndolo. Cómo evaluamos el software y qué intereses declaramos.

Seguir leyendo