SILICIE VapeTax: el software que presenta la contabilidad de un depósito fiscal a la AEAT

¿Qué pasa cuando un depósito fiscal lleva la contabilidad de existencias a mano?

El punto de partida fue el depósito fiscal de BalMY Spain, distribuidor e importador de líquidos para cigarrillos electrónicos. La contabilidad de existencias se llevaba en hojas de cálculo y se subía a la sede electrónica a mano, asiento por asiento.

Eso funciona hasta que deja de funcionar. Cada albarán es un asiento. Cada asiento lleva su código de operación, su epígrafe, su régimen y sus unidades. Multiplica por el movimiento de un mes y son cientos de líneas que alguien teclea a las once de la noche.

Luego llegó un requerimiento de la Agencia Tributaria. Ahí es donde duele: no te piden un mes, te piden reconstruir el ejercicio. Las diferencias que llevaban meses acumulándose salen todas de golpe, con riesgo de sanción por asiento no suministrado o suministrado con errores.

El problema no era la voluntad de cumplir. Era que cumplir a mano, a ese volumen, no se sostiene.

Qué hace SILICIE VapeTax: del albarán al asiento presentado

Entra el documento comercial y sale el asiento contable con su código de operación, su epígrafe y su régimen, listo para presentar. Sin teclear un asiento a mano entre tener el albarán y tenerlo presentado en la AEAT.

El ciclo está cubierto entero: alta del asiento, consulta de lo que consta declarado, anulación cuando hay que rectificar y cierre del ejercicio contable.

Encima de la contabilidad va el cálculo del impuesto. El mismo dato que alimenta SILICIE alimenta la autoliquidación. Si son dos sistemas separados acaban diciendo cosas distintas, y la versión que gana siempre es la de Hacienda.

Todo esto suena a fontanería, y lo es. Pero en un sector regulado la fontanería es exactamente donde se pierde el dinero.

• Importación de albaranes y facturas con generación automática del asiento
• Envío a la AEAT por servicio web: alta, consulta, anulación y ejercicio contable
• Motor FIFO fiscal que separa régimen suspensivo de impuesto devengado
• Autoliquidación calculada con los mismos datos que la contabilidad
• Reconciliación contra lo que consta declarado en la Agencia Tributaria

¿Se pueden enviar los asientos a la AEAT sin entrar en la sede electrónica?

Sí. La Agencia Tributaria publica servicios web para SILICIE. El cliente SOAP habla directamente con ellos y se autentica con certificado digital en TLS mutuo: no basta con que yo confíe en el servidor de la Agencia, el servidor tiene que confiar en mí.

Dos decisiones que parecen menores y no lo son.

La primera: el certificado y su contraseña se leen siempre de variable de entorno, nunca de la petición. Ningún endpoint acepta un certificado que venga de fuera. Un certificado digital es la identidad fiscal de la empresa; si viaja por dentro de la aplicación, cualquier fallo de validación se convierte en alguien presentando declaraciones en tu nombre.

La segunda: el XML se construye con los espacios de nombres exactos de los esquemas oficiales, no con los que parecen razonables. La AEAT valida contra el esquema y rechaza sin explicarse. Un prefijo mal puesto no da un error legible, da un rechazo genérico que te cuesta dos días de depuración a ciegas.

Por qué el FIFO por capa impositiva evita pagar dos veces el mismo impuesto

Aquí es donde se pierde dinero de verdad.

En un depósito fiscal conviven dos clases de producto que físicamente son el mismo litro: el que sigue en régimen suspensivo, sin impuesto devengado, y el que ya lo devengó. Si tu stock es un número, no puedes distinguirlos.

Por eso el motor de existencias no lleva un total, lleva capas. Cada entrada crea una capa con su epígrafe, su régimen y su fecha. Cada salida consume capas en orden FIFO respetando esa separación: cuando sale producto ya devengado se consume de la capa que ya pagó, y cuando sale en suspensivo no se devenga nada.

Sin esa separación pasa una de dos cosas, y las dos son caras. O tributas dos veces por el mismo producto, y esa te la comes tú sin enterarte. O declaras de menos, y esa acaba apareciendo en cuanto alguien cruza tus libros con lo que consta en la Agencia Tributaria.

Por qué el importe se calcula con aritmética decimal y no con la del lenguaje

La base imponible va en las mismas unidades en las que trabaja el almacén: mililitros para los líquidos y gramos de peso total para las bolsas y demás productos de nicotina. Ahí no hay conversión que hacer, y menos mal, porque cada conversión es una oportunidad de descuadrar.

Lo que sí hay es una multiplicación por un tipo con dos decimales, repetida miles de veces. Y hacer eso con la aritmética que trae el lenguaje por defecto es una bomba de relojería: los números con coma flotante no representan exactamente valores como 0,15, así que el clásico céntimo que sobra aparece solo, y multiplicado por el volumen de un mes deja de ser un céntimo.

Por eso todo el cálculo del impuesto usa aritmética decimal exacta, la misma que se usa para dinero en cualquier sistema contable serio. Y el redondeo se aplica en el punto y con la regla que marca la norma, no donde le venga bien al código: redondear por línea o redondear sobre el total da resultados distintos, y solo uno de los dos es el que cuadra con lo que espera la Agencia Tributaria.

¿Cómo compruebo que lo que consta en la AEAT es lo mismo que tengo yo?

Enviar no es lo mismo que estar presentado. Un envío puede aceptarse a medias, quedar duplicado tras un reintento o haberse anulado desde otro sitio. Y tú no te enteras hasta que alguien pregunta.

Por eso hay reconciliación bidireccional. El sistema descarga lo que consta declarado en la AEAT, paginado, porque un ejercicio entero no cabe en una sola respuesta, y lo cruza contra los asientos locales en los dos sentidos: qué tengo yo que allí no está, y qué hay allí que yo no tengo.

Cualquier descuadre sale en una lista, con el asiento concreto señalado, antes de que salga en un requerimiento.

Esa es toda la diferencia. Una discrepancia que encuentras tú es una corrección de diez minutos. La misma discrepancia encontrada por la Inspección es un expediente.

Un ejercicio contable cerrado no se toca, y eso lo impide la base de datos

Cuando se cierra un ejercicio, deja de ser modificable. Esa regla no vive en el formulario ni en una comprobación del navegador: vive en la base de datos. Si alguien intenta tocar un asiento de un ejercicio cerrado, la operación falla, venga de donde venga: de la interfaz, de un script de mantenimiento o de mí mismo un martes a las tres de la mañana.

Lo mismo con el aislamiento entre empresas. VapeTax es multiempresa, y la separación de datos la imponen las políticas de la propia base de datos, no un filtro por empresa escrito en cada consulta. Un filtro se olvida una vez y ya le has enseñado la contabilidad de un cliente a otro.

Es la regla que sigo en todo lo que está regulado: si una garantía solo se cumple porque el código se acuerda de cumplirla, no es una garantía. Es una costumbre.

Qué quedó funcionando y por qué hay una bateria de pruebas automáticas debajo

Quedó un producto en producción. El día a día es importar los documentos, generar los asientos, enviarlos y comprobar que están. La autoliquidación sale calculada de esos mismos datos, no de una hoja aparte. El histórico está cerrado y es consultable, que es justo lo que te piden cuando llega una comprobación.

Debajo hay una bateria de pruebas automáticas, casi todas sobre lo aburrido: FIFO por capas, conversiones de unidad, redondeos, límites de ejercicio, construcción del XML.

Escribimos pruebas en todo, pero en fiscalidad no son opcionales. Un fallo de cálculo aquí no se ve: no rompe la pantalla, no muestra un error, simplemente declara mal durante meses hasta que alguien lo reclama con intereses.

Con esa red, un cambio en el motor de existencias que rompa un caso límite salta en segundos, en mi máquina, mucho antes de acercarse a un envío real.

Preguntas frecuentes